Tool reference
Every tool the Omnipresence MCP exposes, grouped by job, with its parameters and whether it needs a two-way connection.
Updated October 20, 2026
Thirty-one tools, fourteen of which are writes. Every project-scoped tool takes an optional project parameter, a project id or slug, which overrides the session's selection for that one call. Tools marked write need a two-way connection.
You never name a tool in a prompt; the agent chooses. This page is for telling whether it chose well. For the prompts themselves, see what to ask your agent.
Choosing a project
| Tool | Parameters | Notes |
|---|---|---|
list_projects | none | Every project on the account, with its status. |
use_project | project | Selects it for the rest of the connection. |
create_project | name, domain, switch_to | write. Duplicate and daily limits apply, same as the app. |
Reading presence
| Tool | Parameters |
|---|---|
presence_overview | from, to, mode |
presence_query | entity, from, to, search, prompt_id, fanout_id, only_optimizing, include_sources, only_ours, only_unclaimed, mode, tag, order, model, searched, external_id, kind, batch_id, citation_kind, cursor, limit |
presence_timeseries | metric, from, to, fanout_ids, prompt_id, mode |
presence_answers | prompt_id |
presence_get_run | run_id |
presence_export | from, to, format, include, model, prompt_id, external_id, searched, kind, batch_id, delivery, page_size, cursor |
presence_batch_status | batch_id |
presence_query is the general one. entity selects one of seven record types:
| Entity | One row per |
|---|---|
prompts | Tracked or research prompt, with its rate in the window |
fanouts | Search the model ran, with your average position |
sources | Page across the runs in the window, cited and retrieved counts by engine |
runs | Probe |
citations | Page per run: which engine cited which page for which prompt |
optimizations | Piece of work logged as live |
opportunities | Deduped placement target |
Two combinations worth knowing. The current work queue is entity: "fanouts" with only_optimizing: true and include_sources: true, which returns each worked query with its cited sources split yours against third-party and its last logged change. What to work on next is entity: "fanouts" with order: "opportunity", which ranks by where the gap is worth closing rather than by raw frequency: frequency alone puts the queries you already win at the top.
Pages are matched on a normalised url key, so tracking and session parameters are ignored and one page counts once.
Changing the project
| Tool | Parameters | What it does |
|---|---|---|
presence_manage_prompt | action, prompt_id, prompt, model, frequency, samples, search_mode, is_control, external_id, topic | write. Create, edit, pause, resume or delete a tracked prompt. |
presence_manage_asset | name, is_owned, aliases | write. Register a brand or competitor and map its spellings. One owned brand per project. |
presence_set_config | brand_name, domain, city, service, vertical, owned_page_types | write. The presence configuration. |
presence_tag | action, entity_type, entity_id, tag | write. Tag a prompt, fanout or source. |
presence_run_now | prompt_id, idempotency_key | write. Run one prompt immediately. |
presence_research_batch | prompts, samples, idempotency_key | write. A one-off study. Costed up front; refused whole if it will not fit. |
presence_set_optimizing | fanout_id, optimizing | write. Flags a fanout as being worked, and dates the before-and-after. |
presence_source_update | source_id, url, claimed, claimed_url, notes | write. Notes, and the claim when a placement lands. |
presence_log_optimization | fanout_id, source_id, title, detail, optimized_on, page_url, page_status | write. Records work that has already gone live. Safe to retry. |
Context, memory and files
| Tool | Parameters |
|---|---|
project_context | project |
project_context_update | brand_name, domain, positioning, tone, audience, proof, brand_voice, keyword_targets, replace_keyword_targets, notes (write) |
memory_store | facet, content, ref_url, fanout_id, prompt_id (write) |
memory_retrieve | query, facet, limit |
memory_list | facet, limit |
memory_delete | id (write) |
project_files_list | kind, offset, limit |
project_files_get | key, version, max_chars, offset |
project_files_put | key, content, kind, content_type, name, reason (write) |
Three places to put information, and they are not interchangeable: context is what the brand is, memory is what was decided or done, files hold whole documents. See brand and voice context, project memory and project files.
The methodology
| Tool | Parameters |
|---|---|
lookup | query, type, limit |
fetch | ids, include_dependencies |
chunkscore | query, passages, strip_markup |
lookup finds processes, methodologies and skills and returns a ranked list with no file content; fetch reads them by id in one bundle. chunkscore scores passages against a query, which is the same scorer behind retrieval readiness, so an agent can test a draft before it is published:
Score this rewrite against the fan-out query it should answer, and tell me
whether it clears the thresholds before I publish it.Questions about tool reference
- Do I need to configure any of this?
- No. Your client discovers the tools on connecting. This page is for deciding what is possible, not for setting anything up.
- What does the project parameter do?
- It overrides the session's selected project for one call. Omit it and the call uses the project the agent is working in.
- Why is there no delete-project tool?
- Because a project is paused or cancelled, never destroyed. The rule holds on every surface.