mazarbul

Overview Schema Source Related Servers Discussions Admin

getContext

Builds a token-budgeted markdown brief of the user's working set—pinned and recently updated documents, key entities, and query-relevant hits—for loading at session start instead of many small reads.

Instructions

Assemble a token-budgeted markdown brief of the user's working set — pinned documents, recently-updated documents, key entities, and (when you pass a query) the most relevant hits — for loading at the start of a session. Deterministic and fast (no LLM). The brief never exceeds budgetTokens; lower-priority content is dropped behind a visible marker. Prefer this over many small reads when you need to warm up context about the user.

Input Schema

Name	Required	Description
`query`	No	Optional focus. When set, the brief adds a section of the most query-relevant hits (documents + episodes), co-ranked by the same recall used by recall/ask.
`scopes`	No	Scopes to read from: project, personal, team. Defaults to project+personal. Unknown values are rejected.
`budgetTokens`	No	Token budget for the brief (default 4000). The brief never exceeds it; the lowest-priority tail is dropped behind a marker.

Output Schema

Name	Required	Description
`budget`	Yes	The token budget that was applied.
`tokens`	Yes	Estimated token count of the brief (always <= budget).
`dropped`	No	How many lower-priority items were omitted to fit the budget.
`markdown`	Yes	The assembled context brief as markdown: pinned documents, recently-updated documents, key entities, and (when a query is given) relevant hits. Load this verbatim at session start.
`sections`	No	Per-section counts of what made it into the brief.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does disclose key traits: deterministic, no LLM call, hard budget cap, and visible truncation markers. It doesn't explicitly state that it is a read-only operation with no side effects, which is the main remaining safety question for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences; the purpose is front-loaded, then behavior, then the routing hint. Every sentence carries distinct information with no restatement of the name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and the return format (markdown brief) is already characterized, so the description needn't explain return values. For a zero-required-parameter tool with full schema coverage, the description covers purpose, budget behavior, and session-start usage — nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description reinforces the effect of `query` (adds a co-ranked relevance section) and `budgetTokens` (never exceeded, tail dropped behind a marker), but adds little beyond what the schema descriptions already say, and `scopes` semantics are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Assemble a token-budgeted markdown brief of the user's working set') and enumerates exactly what goes into the brief: pinned docs, recently-updated docs, key entities, and query-relevant hits. An agent can distinguish this from recall/readDocument/listDocuments siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a clear usage context ('for loading at the start of a session') and an explicit preference rule ('Prefer this over many small reads when you need to warm up context about the user'). It doesn't name specific sibling tools (recall, readDocument, query) or state when not to use it, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.