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

With no annotations, the description carries the full burden. It does valuable work by disclosing the return payload (rendered context, provenance, omissions, reproducible optimization report) and a real caveat that token counts are estimates unless a server-side estimator is configured. It does not say whether stored records are modified, whether the call is side-effect free, or what happens when the budget cannot be met.

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?

Two sentences, front-loaded with the purpose and then the output contract. No filler, though the second sentence packs provenance, omissions, report, and the estimation caveat into one dense clause.

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 four-parameter, schema-rich tool with no output schema, the description does explain what comes back, which is the main gap it needed to fill. It is still incomplete on routing versus siblings and on failure behavior when the budget is exceeded.

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 100%, so all four parameters are already documented, and the baseline is 3. The description adds framing for tokenBudget ('under a token budget') and clarifies that records merge with stored records, but adds no syntax, defaults, or interaction detail beyond the schema.

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 uses a specific verb+resource ('Construct a compact, task-specific context') and states the mechanism ('combines stored records with any inline records'). It implicitly separates itself from ingest_records and search_context by being the composition/rendering step, though it never names those siblings directly.

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?

There is no explicit when-to-use guidance: nothing says to call build_context before search_context or instead of it, and no preconditions or exclusions are stated. The agent must infer from the name and from 'task-specific' that this is the final assembly step.

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?

No annotations are supplied, so the description carries the full disclosure burden. It does convey read-only retrieval and the four status categories in scope, but says nothing about result volume, ordering, scoping, or auth. Since the tool takes zero parameters, it presumably returns everything unfiltered, which the description never states.

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 sentence, front-loaded with the verb and resource, with the status list attached compactly. Nothing is redundant and nothing needs to be moved earlier.

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 simple zero-parameter read tool this is close to sufficient, but with no output schema the description should hint at what a decision record looks like (id, status, rationale) or whether all statuses come back together. As written, an agent knows the topic but not the shape or size of 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 has zero parameters, so there is no parameter semantics to add and the baseline of 4 applies. The parenthetical about statuses describes returned data rather than inputs, which is still useful orientation.

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?

"Retrieve previously recorded technical decisions and constraints" gives a specific verb (retrieve) and resource (decisions/constraints), and the parenthetical enumerates the status values returned. It does not name or contrast with any sibling such as search_context or get_file_history, so an agent must infer the boundary itself.

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 only implied by "previously recorded" — the agent gathers this is for looking up already-captured decisions rather than creating new ones. There is no explicit when-to-use, no exclusion, and no pointer to alternatives like search_context when a keyword lookup is wanted.

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?

With no annotations, the description carries the full behavioral burden. It implies a read-only retrieval and lists the kinds of context returned, but it does not disclose scope limits such as time range, pagination, permissions, or whether results are 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 description is a single, front-loaded sentence with no redundant wording. It states the action and the main categories of returned context efficiently.

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 one-parameter retrieval tool with no output schema, the description gives a useful list of returned content categories but does not clarify result scope, ordering, or limits. It is adequate but leaves meaningful behavioral details unspecified.

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 schema already fully documents the single 'path' parameter, including that it may be absolute, relative, or a basename. The description adds only that context is associated with the file path, so baseline 3 is appropriate given 100% schema coverage.

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 uses a specific verb ('Retrieve') and resource ('context associated with a particular file') and enumerates the content types returned: snapshots, diffs, errors, and test failures. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as search_context or get_relevant_errors.

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 'particular file' implies file-scoped usage, but there is no explicit guidance on when to choose this tool over search_context or get_relevant_errors. No exclusions or alternative-routing instructions 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?

With no annotations, the description carries the full behavioral burden. It never states that this is a read-only operation, what permissions are needed, whether results are paginated or bounded (the limit cap of 100 is only in the schema), or what ordering applies when no query is given. The enumeration of returned content types is the only behavioral 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?

Two tight sentences with the retrieval scope front-loaded and the query behavior second. No filler, though the parenthetical list is slightly redundant with the first clause.

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 simple two-parameter read tool with no output schema, the description covers what is returned and how query affects ordering, but leaves the meaning of 'related' (relative to what context?) and default ordering unspecified — a gap an agent would notice when calling without a query.

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 50% and the description adds meaning the schema does not: that supplying a query changes the result into a relevance ranking, rather than merely filtering. It says nothing about the limit parameter or its cap, leaving that to the schema.

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?

Names a specific verb ('Retrieve') and concrete resources ('related errors, failed attempts and diagnostic information'), further clarified by the parenthetical list of error records, failed tool calls, and failing tests. It does not distinguish itself from siblings like get_decisions or search_context, and 'related' is left undefined, so it stops 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?

The phrase 'Optionally ranked by a query' implies the two modes (unranked fetch vs. ranked search) but never says when to prefer this tool over search_context or the other siblings, nor any exclusions. Usage must be inferred.

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?

With no annotations, the description carries the full burden and does add real behavioral content: the store is "local" and "in-memory" (so writes are ephemeral), records are validated, and malformed entries are reported and skipped rather than aborting the call. It stops short of stating idempotency, duplicate handling, or size limits.

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?

Two sentences, no filler, and the payload kinds and validation behavior are front-loaded so an agent can decide and call after one read.

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?

The description covers the most important unknowns for a mutation tool (ephemeral store, partial-failure semantics), but with no output schema it never says what a successful call returns or what the malformed-entry report looks like. For a one-parameter tool this is adequate but leaves a real gap around 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?

Schema description coverage is 100% and there is a single parameter, so the schema already explains the array and the required "kind" field. The description's kind list restates the enum rather than adding syntax or per-kind field requirements.

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?

"Add structured records ... to the local in-memory context store" gives a specific verb plus resource and enumerates the eight record kinds, which maps directly onto the schema enum. It never names the retrieval siblings (build_context, search_context), but the write-vs-read split is obvious enough from the wording.

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?

There is no explicit when-to-use statement, no mention of ordering relative to build_context, and no guidance on batching versus repeated calls. Usage is only implied by the fact that it is the sole write-side tool among read/retrieval siblings.

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?

With no annotations supplied, the description carries the full burden and does meaningful work: it explicitly guarantees the operation never modifies sources (a read-only safety claim) and discloses that results carry score breakdowns and provenance. It stops short of describing the scope of stored records searched, freshness, or result-count behavior beyond what the schema's limit field already states.

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?

Two sentences, no filler, with the core action and the strongest behavioral guarantee ("never modifies sources") front-loaded. Every clause adds information an agent can act on.

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 three-parameter read tool with no output schema, the definition covers action, ranking model, return contents, and safety. The remaining gap is routing: an agent given five retrieval-oriented siblings lacks the sentence that would tell it when this is the right choice.

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 100%, so query, limit, and the inline `records` array are already documented in structured form. The description adds nothing about parameter interaction — notably that `records` supplements rather than replaces stored records, which the schema only hints at — so it stays at the baseline.

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?

Names a specific verb and resource ("Retrieve fragments relevant to a query") and adds the distinguishing trait that results are ranked by an explainable relevance model. It does not, however, contrast itself with the retrieval siblings (get_decisions, get_relevant_errors, build_context), so an agent must infer that this is the generic cross-kind search.

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 only implied: the phrasing suggests a free-form relevance search over stored context, in contrast to the more targeted sibling lookups. There is no explicit when-to-use statement, no condition favoring this over build_context, and no guidance on when the inline `records` mode is appropriate.

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