Build deterministic prompts by inspecting input first, then applying lexical selection and safe optimization only when recommended. Never summarizes or paraphrases; runs offline.
Inspect-first deterministic prompt preparation: runs inspection, then lexical selection + safe optimization only when recommended. Never summarizes or paraphrases. Offline.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| question | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose real traits: deterministic, offline (no network), and it never summarizes or paraphrases, which is a meaningful negative constraint. It does not say whether anything is mutated, whether output is persisted, or what the response contains, so significant gaps remain.
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?
Three short clauses, front-loaded with the inspect-first concept and the key constraint ('never summarizes or paraphrases'). No padding or repetition, though the dense jargon costs 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?
No output schema, no annotations, and 0% parameter coverage, so the description must do more work than it does. It omits what the tool returns, what `question` is for, and how an agent knows whether optimization was 'recommended' — an agent could not call this correctly and predict the result from the definition alone.
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% for two parameters. The description's mention of prompt preparation loosely implies `text` is the prompt, but it says nothing at all about `text` format or the `question` parameter, leaving half the interface completely undocumented in both schema and prose.
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 recognizable activity (prompt preparation) and gives a rough pipeline: inspection, then lexical selection plus 'safe optimization' only when recommended. However, 'lexical selection' and 'safe optimization' are undefined jargon, and the name 'prepare' is generic enough that an agent cannot confidently distinguish this from sibling tools like compact or intake without opening the schema.
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?
'only when recommended' gestures at a precondition but never says who recommends it or how an agent learns the recommendation. There is no explicit when-to-use or when-not-to-use guidance, and none of the siblings (compact, compact_transcript, inspect, intake, recall, explain) are named as alternatives, even though 'runs inspection' overlaps with the sibling `inspect`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.