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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two real behavioral facts beyond them — output is bounded and carries provenance — but never explains what the bound is, how fresh the data is, or what provenance looks like. Useful added context, well short of full disclosure.

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

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

A single front-loaded sentence with zero filler: verb, resource, distinguishing property, and contrast all in under a dozen words. Nothing repeats the name or the annotations, and nothing could be cut without losing meaning.

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

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

With no parameters, no output schema, and annotations covering the safety and openness profile, the description carries only the burden of explaining what comes back — and it does so vaguely. "Bounded" and "provenance" are the right concepts but are undefined, so an agent knows the shape of the answer without knowing its contents or limits.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The one thing an agent might want — whether the briefing can be scoped or filtered — is implicitly answered by "bounded" and the empty schema together.

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

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

"Read a bounded context briefing with provenance" names a specific verb and resource, and the trailing clause explicitly contrasts it with a different thing (an inferred user profile). However, "context briefing" is left abstract — the agent must guess what the briefing actually contains, and no sibling (get_facts, get_evidence_bundle, search_memory) is named, so sibling differentiation is conceptual rather than explicit.

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

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

The phrase "not an inferred user profile" implies when this tool is appropriate (when sourced, bounded context is wanted rather than interpretation), but there is no explicit when-to-use/when-not against the six sibling retrieval tools. The agent can infer intent but receives no routing rule for choosing between this and get_facts or get_evidence_bundle.

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

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

Annotations already establish read-only, non-destructive, closed-world behavior, and the description adds genuinely new behavioral context: character-bounded output, no paid inference, a token budget, date-fallback ordering with undated sources excluded, and an explicit prompt-injection warning that source text is untrusted data. It stops short of describing the response envelope or ranking detail, so it is strong but not exhaustive.

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

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

The core purpose is front-loaded in the first clause and each subsequent sentence adds a distinct constraint rather than restating. The telegraphic style ('Uses BM25/cards and optionally enabled local embeddings, no paid inference') is dense but every clause carries information; minor trimming could improve readability.

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

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

For an eight-parameter retrieval tool with no output schema and no annotation detail beyond the safety hints, the description covers the important dimensions: what is returned, how citations work, how filters and dates are applied, budget limits, and the trust boundary. The remaining gaps are source_id and mode value semantics.

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

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

Schema coverage is 0%, so the description carries the full burden, and it meaningfully explains project, date_from, date_to, record_id, and budget_chars ('bounded JSON characters'). However, source_id is never mentioned and mode is only obliquely referenced via 'Uses BM25/cards and optionally enabled local embeddings' with no value semantics, so two of eight parameters remain semantically dark.

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

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

The description names a specific verb and resource ('Read exact current source quotes with stable citation IDs') and adds the distinguishing property that makes it different from its siblings: verbatim quotable evidence rather than memory summaries or records. It never names an alternative tool explicitly, which keeps it just short of a 5.

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

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

It gives conditional guidance for its own parameters ('record_id selects only that current permitted record without ranking or embedding') and states a downstream usage rule ('Write the answer yourself and cite citation_id'), which implies this tool does not synthesize answers. It never says when to prefer it over search_memory or get_record, so the when/when-not comparison is left to inference.

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

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

Annotations already establish that this is a safe read-only operation, but the description adds useful behavioral context: pagination via next_cursor, stable event_id semantics, and the meaning of active=false for historical evidence. It also warns that source text remains untrusted data. It stops short of covering ordering, permissions, or edge cases such as missing facts.

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

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

The description is compact and front-loads the core purpose before pagination and trust details. Each sentence carries relevant information, though the jargon 'exact revision proofs' reduces immediate clarity. It is appropriately sized for a read-only history tool.

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

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

With no output schema and 0% schema description coverage, the description should carry more of the return and parameter burden. It does explain key output-like concepts such as event_id, next_cursor, and active, but it leaves input parameters undocumented and does not route the agent away from nearby siblings. It is only partially complete for the tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate, but it never explains fact_id, limit, or before. It mentions next_cursor, which is not an input parameter and may confuse the agent about how to pass the before cursor. It adds some pagination meaning but does not map it to the actual parameter.

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

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

The description states a specific verb and resource: reading paginated exact revision proofs for a fact history, scoped to since feature enable. It also excludes inferred past timelines, which clarifies purpose. It does not distinguish this tool from the sibling get_facts or get_evidence_bundle, so it falls short of a 5.

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

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

Usage is implied by the name and by the phrase 'no inferred past timeline,' which acts as a scope exclusion. However, there is no explicit guidance on when to use this tool rather than get_facts, get_record, or search_memory, and no alternatives are named.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's contribution is the extra semantics: 'This read never projects cached cards or starts model work' discloses side-effect scope, and 'source_supported means an exact source quote, not established truth' warns that returned facts are not verified truth. It adds a citation discipline ('Cite evidence citation_id') that the annotations cannot express. It does not disclose result shape or pagination behavior.

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

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

The lead sentence is front-loaded and does the routing work immediately, and later sentences are short and purposeful. The second and third sentences are fragmentary ('candidate and possible_conflict remain uncertain') and lean on undefined vocabulary, costing some readability.

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

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

With no output schema, the description usefully defines three result-state labels (source_supported, candidate, possible_conflict) and the citation_id convention, which is real value. But a four-parameter filtered-list tool with zero schema coverage leaves the agent guessing about filtering, paging, and the include_history parameter, so it is only minimally complete.

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

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

Schema description coverage is 0% across four parameters (limit, query, source_id, include_history), so the description must carry the burden and largely does not — it never explains filtering, what source_id scopes to, or what limit applies to. Worse, the description directs agents to get_fact_history for past observations while the schema itself exposes an include_history flag, leaving that tension unresolved.

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

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

The description names a specific verb and resource: 'Read grouped exact card facts/decisions with permitted evidence', and explicitly excludes generation ('no generation'), which separates it from model-inference siblings. It also names get_fact_history as the alternative for past observations. It falls short of 5 only because terms like 'grouped' and 'card' are undefined jargon an agent may not resolve without prior schema knowledge.

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

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

It gives one explicit routing rule: 'use get_fact_history for past observations', plus the negative condition 'no generation'. However it gives no guidance on when to prefer this over search_memory or get_record, both of which likely return overlapping memory content.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context about 'source-backed' content and 'bounded text pagination', but it does not mention error behavior, return format, or pagination boundaries.

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

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

The description is a single front-loaded sentence with no filler. It is efficient, though it is so terse that it omits details the schema does not cover.

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

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

For a tool with three parameters at 0% schema coverage and no output schema, the description is under-specified. It does not explain the pagination parameters or what an agent should expect from the returned record, leaving gaps that annotations alone do not fill.

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

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

Schema description coverage is 0%, so the description must fully explain the three parameters. It only gestures at 'search ID' and 'bounded text pagination' without naming offset or max_chars, explaining their defaults, or clarifying how pagination interacts with record size.

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

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

The description states a specific verb ('Read') and resource ('source-backed memory record') and clarifies the lookup key ('by search ID'). It distinguishes the tool from retrieval siblings like get_facts or get_context_brief, though it does not explicitly name an alternative.

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

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

'By search ID' implies the tool is used after a search operation, giving some contextual usage guidance. However, there is no explicit statement of when to use this versus get_facts, get_evidence_bundle, or search_memory, and no exclusions are provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the description's assurance that it 'never starts import or paid inference' mostly reinforces known safety properties with useful specificity about cost and side effects. However, it does not disclose the return shape, freshness, or what 'sync status' means beyond counts.

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

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

The definition is a single compact sentence with the core action front-loaded and no wasted clauses. The semicolon-separated caveat is concise, though the phrase 'this MCP tool' adds little.

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

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

With zero parameters, no output schema, and rich annotations, the description is nearly sufficient but omits what the returned counts represent and what the sync status conveys. For a status-reading tool, that leaves a meaningful gap in understanding the response.

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

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

The tool takes zero parameters, so there is no parameter semantics burden and the baseline is 4. The description adds nothing needed beyond the schema, which is appropriate here.

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

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

The description states a verb and resource ('Read memory counts'), which is clearer than a tautology, but 'memory counts' is vague for a tool named get_sync_status and does not clarify what counts or status are returned. It also does not differentiate its role from siblings such as get_facts or search_memory.

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

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

The negative clause 'never starts import or paid inference' implicitly signals a safe status-check use case, but no explicit when-to-use guidance or alternatives (e.g., get_context_brief, search_memory) are named. The agent must infer selection from the name and the exclusion alone.

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

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

Annotations already declare it read-only and non-destructive, and the description goes further by disclosing the BM25 fallback path, diagnostic mode fields, and that scores are ranks rather than truth probabilities. The note that source text remains untrusted is genuinely useful behavioral context an agent would not get from structured fields.

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

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

Four short sentences, each doing distinct work, with the core action front-loaded. The telegraphic phrasing ("bounded source snippets") is slightly opaque and costs a bit of clarity, but there is no filler.

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

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

For a read-only search with no output schema, the description covers the safety profile and result-scoring caveats but omits any sense of the returned hit structure, pagination via limit, or source_id scoping. An agent could call it, but would be guessing at scoping and result shape.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full burden. It only indirectly gestures at the mode parameter (semantic/hybrid vs BM25) and says nothing about query, limit, or source_id, leaving most parameters defined by bare type and default alone.

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

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

States a specific verb and resource ("Search bounded source snippets"), which tells an agent this is a retrieval operation over stored text. It does not, however, distinguish itself from nearby tools like get_facts or get_evidence_bundle, so an agent still has to infer why it would pick this one.

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

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

The only conditional guidance is around modes: semantic/hybrid requires explicitly enabled local embeddings, otherwise it falls back to BM25. There is no statement of when to use this tool versus its siblings, and no exclusions or prerequisites for the required query parameter.

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