Reduce supplied context and check caller-declared, source-specific exact evidence retention.
Scored across 1 tool
With only one tool there is no cross-tool confusion, and the name plus description clearly target context retention review. However, the tool bundles two distinct operations (budgeted passage selection and evidence-excerpt verification), so its own boundary is somewhat blurred.
review_context_retention is a clear snake_case verb_noun-style name that reads predictably. With a single tool there is no pattern to violate, but also no convention demonstrated across the set.
A single tool for a server whose description implies separate selection and verification workflows feels thin and borderline. The tool is non-trivial, but the scope likely warrants splitting into at least two operations.
The surface covers only passage selection under a token budget plus evidence-excerpt checking; there is no tool for token counting, document/source listing, summarization, or inspecting selection results. Agents will hit dead ends for the surrounding review workflow.
Select passages from explicitly supplied sanitized documents under an estimated token budget, and check whether user-declared exact evidence excerpts remain in selected passages from their specified source. No web access, storage, payments, semantic correctness guarantee, or downstream prompt capture. Do not send credentials, government IDs, payment card data, protected health information, or confidential personal records.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| documents | Yes | ||
| sanitized | Yes | Confirm these are authorized, sanitized or synthetic task-specific excerpts, not restricted data. | |
| tokenBudget | Yes | ||
| expectedEvidence | No | Caller-declared exact excerpts required for this task. An empty list means completeness was not tested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive behavior. The description goes further by disclosing the absence of web access, storage, payments, semantic correctness guarantees, and downstream prompt capture, plus an explicit data-handling prohibition. That is real added behavioral context beyond 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?
Two dense sentences that front-load the core behavior before the constraint list; the negation list is slightly enumerative but each item carries a distinct safety or scope signal. Little waste overall.
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, annotated, no-output-schema tool, the scope and safety envelope are well covered, and the return semantics are implied (selected passages plus evidence-retention status). The unexplained 'task' parameter and the 40% schema coverage leave a noticeable gap an agent must fill by inference.
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 only 40%, so the description must compensate. It implies the roles of documents, tokenBudget, sanitized, and expectedEvidence (including that an empty list means completeness was not tested), but the required 'task' parameter is never explained or referenced.
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 two concrete operations against a named resource: passage selection under a token budget, and verification that declared excerpts survive selection. It is specific and non-tautological, though bundling two distinct behaviors into one description slightly blurs the primary purpose.
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 description sets preconditions ('explicitly supplied sanitized documents', 'user-declared exact evidence excerpts') and lists exclusions (no web access, storage, payments, semantic correctness guarantee, prompt capture), which implies the appropriate context. However, there is no explicit when-to-use statement or framing of the intended task, and no siblings exist to route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
review_context_retentionEvidence-bound second-opinion audit of an agent conclusion against caller-supplied evidence.
Dated, signed compliance-evidence packs: gov-fact-grounded claims + exclusion screens + trap-facts.
Verify stock signals, replay evidence, provenance, freshness, and caveats.
Physical-world evidence and operability checks with provenance and explicit data gaps.
Add one secure layer between your agents and this server.