Skip to content

MCP tools

All three require an API key; the key decides the namespace (on /mcp/docs, any key reads jitprompt’s own docs instead). Ids are accepted as the 8-character prefixes shown in output or as full ids.

get_toc(document_id?: string, query?: string) -> text

Without arguments: one entry per ready document — title, short id, one-line summary, and its sections (id, title, summary) when it has at most 8. Larger documents show — N sections; get_toc(document_id="…") lists them.

With document_id: that document with every section listed.

With query (what the agent is about to do): only the documents that best match it, best first, as many as fit the map’s budget (at most 15), headed Documents most relevant to "…" (12 of 698, best first …).

The map without arguments is kept to about 8,000 tokens. In a large namespace it is condensed — document lines, then titles, then an overview with the namespace’s description and counts — and says so; the agent then uses query. A namespace’s description, when set, is the first line of the map.

Returns No instruction documents are available yet. for an empty namespace.

search_instructions(plan: string) -> text

plan describes what the agent is about to do and the guidance it needs — “writing a refund email to an enterprise customer”, not the user’s question verbatim. Returns whole sections grouped by document, best document first, within about 4,000 tokens and at most 6 documents; a document of up to about 800 tokens comes back whole (every section, in order), a larger one its best two matched sections (more when few documents matched and budget is left). Each section as:

# Section title [id: 8c1d02aa]
From: Document title [doc 3f2a9c1e]
full section text …

After the sections, up to 5 lines name documents that matched but weren’t returned (- Title [doc 3f2a9c1e]): if the section you needed isn’t there, get_toc(document_id=…) on one of them, or a search naming it, is the next step. With no match: a message suggesting get_toc.

get_section(section_id: string) -> text

The full text of one section, in the same format as a search result (title, id, From: document line, content), or No such section.

If the namespace has pinned documents, the agent gets them without calling anything, under a fixed header:

# Core procedures (always apply)
These procedures apply to every conversation. For anything else, use search_instructions and get_toc.
---
# Looking up accounts [id: 55f4f6bd]
From: Retrieving Customer Account Information [doc 154404aa]
full section text …

Each pinned document comes whole, in pin order, in the search format, so its ids work with get_section. The block is delivered two ways:

  1. In the server’s instructions. A client that puts them into the model’s context gets the block once per conversation: on initialize, or on server/discover under the 2026-07-28 protocol.
  2. At the top of the first answer. For clients that ignore instructions, the first get_toc or search_instructions answer of an MCP session starts with the block, followed by --- and the usual output. It is never repeated in that session. The search in that answer leaves out sections the block already holds. A client that keeps no session gets the block from every get_toc() called without arguments, and never from a search, so it isn’t repeated on every call.

Clients known to honour the instructions don’t get the block a second time in an answer:

Client Instructions The block arrives
Claude Code (claude-code) used (verified with 2.1.251) once, in the instructions
Any other client not assumed in the instructions, and once in an answer

The block is at most the namespace’s cap (2,000 estimated tokens by default). It doesn’t count toward a search’s ~4,000 tokens. A namespace without pins gets none of this: no instructions, and its answers are unchanged.

  1. get_toc at the start of a conversation and when the topic changes — with query in a large namespace.
  2. search_instructions before each new task, system or data source.
  3. get_section when the map points at a specific section.

Every call is recorded in the namespace’s Diagnostics (kept 30 days), including the plan text of searches.