Prompt Optimizer MCP

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful boundary that scope is not expanded, but says nothing about what the tool actually rewrites or how the original prompt is preserved.

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 short, front-loaded sentences with zero filler; the core action leads and the exclusion follows. Nothing to trim.

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?

An output schema exists, so return values need not be explained, but the tool transforms a user-supplied prompt using two enum parameters that are undocumented in both the schema and the description. That leaves an agent unable to judge how to pick targetAgent or audience.

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% and the description mentions none of the three parameters (prompt, targetAgent, audience). With two enum-constrained params and no schema prose, the description needed to compensate for choosing a target agent/audience and does not.

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 (add) and object (documented host guidance to an existing instruction), which is more than a tautology, but 'host guidance' is undefined jargon and no sibling is named. It only partially differentiates from the cluster of prompt tools (optimize_prompt, build_agent_instruction, etc.).

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 an explicit trigger ('use when changing agent environments') and an explicit exclusion ('not for expanding task scope'). No alternative sibling is named, but the when/when-not framing is unusually clear for this set.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description's 'does not execute them' adds a modest clarification of the boundary but is largely implied by readOnlyHint and gives no detail on determinism, targetAgent behavior, or output shape.

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 tightly written sentences: the purpose leads and the usage note follows. No filler, no repetition, and the key scope constraint is front-loaded.

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?

An output schema exists, so return values need no explanation. However, with 5 parameters, a 0%-covered schema, a nested context array with a kind enum, and the targetAgent enum, the description omits enough (especially targetAgent and the constraints-vs-requirements distinction) to be only adequate.

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 carry parameter meaning. It names goal, requirements, and constraints (3 of 5), which is meaningful partial compensation, but leaves context and the significant targetAgent enum (8 target formats, default 'auto') entirely unexplained.

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 (assemble) and resource (execution instruction) and names the three input sources (goal, requirements, constraints). This clearly differentiates it from prompt-manipulation siblings like optimize_prompt or inspect_prompt, though it doesn't explicitly name any sibling.

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?

Gives a clear usage cue ('Use for multi-part tasks') and a boundary ('does not execute them'). It does not name alternatives among the sibling prompt tools or state when NOT to use it versus them, but the context is unambiguous.

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 readOnly, idempotent, non-destructive, closed-world. The description adds a meaningful behavioral trait beyond them: output is descriptive trade-off analysis rather than a ranked winner. With annotations carrying the safety profile, this extra contextual disclosure earns a 4.

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 terse sentences, front-loaded with the verb+resource and immediately followed by the differentiator. Zero waste.

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?

Output schema exists, so return values need not be explained. Annotations cover safety. The remaining gap is that, with 0% parameter descriptions, the agent must guess parameter semantics; the description's phrase 'task context' helps but does not fully close it. Still complete enough for a comparison tool.

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 schema names promptA/promptB/taskContext but explains nothing. The description compensates partially by implying the two prompts and 'task context' are what get compared, but it never states syntax, limits, or whether taskContext is optional-in-practice. Baseline 3 given partial compensation for a 0%-coverage gap.

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?

Specific verb 'compare' plus resource 'two instructions' and the mechanism 'by heuristic dimensions and task context'. The negation 'does not declare an arbitrary winner' distinguishes it from sibling evaluate_prompt, which presumably ranks or scores.

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?

Contains one useful boundary marker: it produces comparisons, not verdicts. However, it never says when to reach for this versus evaluate_prompt, optimize_prompt, or inspect_prompt, so the agent must infer the selection context.

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 (readOnly, idempotent, non-destructive, closed-world), so the description's real contribution is the algorithmic boundary — it clarifies this is mechanical ranking/budgeting, not summarization or instruction rewriting. That is meaningful added context, though it says nothing about failure modes, truncation behavior, or how the budget interacts with critical items.

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. The positive capability is front-loaded and the negative expectation is second, which is exactly the right ordering for an agent scanning for fit.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, trigger, and limits. The gap is parameter-level detail for a 0%-coverage schema, especially the undocumented query parameter that determines ranking relevance.

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 three parameters, but the description maps loosely onto them: 'rank' implies the relevance-driving query, 'budget' implies maxTokens, and 'retaining critical items' implies the critical flag. It adds no format, default, or constraint detail, so the compensation is partial at best.

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 three specific verbs (rank, deduplicate, budget) on a named resource (supplied context) and states the retention goal ('while retaining critical items'). This is far more precise than the prompt-oriented siblings, though it never explicitly names an alternative to differentiate itself from them.

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?

'Use for noisy context' gives an explicit triggering condition, and 'do not expect semantic summarization or instruction promotion' is a clear negative scoping statement that prevents misuse. It lacks routing guidance naming a sibling alternative, so it falls 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.

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the tool is heuristic and 'transparent', and its output is explicitly not a correctness proof, which is meaningful expectation-setting for an evaluation tool.

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 compact sentences, front-loaded with the core purpose and followed by the limitation. Every sentence carries weight, though the opening could be more concrete about operating on the input prompt.

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?

An output schema exists, so return values need not be described. The gap is the undocumented optional 'originalPrompt' input and the absence of any link to the other prompt tools, which for a nine-sibling family is a notable omission.

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% and the description mentions no parameters at all. In particular the optional 'originalPrompt' is left entirely unexplained, so an agent cannot tell whether supplying it changes behavior (e.g. diffing a revised prompt).

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 it explains instruction quality via heuristic diagnostics, which separates it somewhat from optimize_prompt or compare_prompts. However, it never plainly says it evaluates the supplied prompt, and the verb 'Explain' is weaker than the tool name's 'evaluate', leaving the core action slightly vague.

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?

'Use for review, not as a scientific benchmark or proof of correctness' gives a directional use case and a caveat, which is real guidance. It offers no explicit when-not conditions tied to sibling tools like compare_prompts or optimize_prompt, so the agent must infer which of the nine siblings to pick.

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 (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral context: the server persists no history and does not authenticate caller-supplied results, which tells the agent the input is untrusted and non-persistent. It does not describe the output payload, but that is largely covered by the output schema.

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 front-loaded and the caveats second. Every clause carries information.

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 output schema exists, so return values need no explanation, and the description adequately covers the trust/persistence model. However, for a tool whose only input is a huge nested result object, the description gives no orientation about what must be supplied beyond 'optimization result,' leaving a real gap.

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 a single required parameter whose shape is a very large, deeply nested required IR object. 'Supplied optimization result' usefully implies the input is the payload returned by optimize_prompt, but the description adds nothing about the required members, so an agent still depends entirely on 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?

States a specific verb and resource: 'Explain a supplied optimization result and its pass decisions.' The scope (result plus pass decisions) is concrete enough to distinguish it from optimize_prompt or evaluate_prompt, though it never names a sibling explicitly.

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?

'Use for audit' gives a clear use context, and the clause about no stored history implies the result must be produced and handed over in the same session. It stops short of naming alternatives (e.g., vs. evaluate_prompt), so it is context without exclusions.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description's 'without rewriting' adds a small amount of behavioral context (input is not mutated) but is essentially a restatement of readOnlyHint, with no detail on depth of analysis or output shape beyond the separate output schema.

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 compact sentences, with the core capability front-loaded before the routing guidance. There is no filler and nothing that 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?

The output schema and annotations relieve the description of explaining return values and safety, and the usage sentence is crisp. However, for a tool whose only real surface is its two parameters, the complete absence of parameter guidance leaves an agent guessing how to populate 'context' and what mark the 'critical' flag has.

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 both parameters, so the description carries the full burden of explaining them and it never mentions 'prompt' or 'context' at all. It leaves the context array's kind enum, the 'critical' flag, and the 128-item/64000-char limits entirely undocumented in 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 specific verb (inspect) and enumerates exactly what is inspected: intent, ambiguity, conflicts, and context. The phrase 'without rewriting' implicitly separates it from the optimize/adapt siblings, though no sibling is named outright.

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 both a positive trigger ('use to diagnose instructions') and an exclusion ('skip simple factual questions'), which is more than most definitions offer. It stops short of naming alternative tools such as evaluate_prompt or optimize_prompt when the diagnosis turns into scoring or rewriting.

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, openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the request is preserved, guidance is bounded, and non-local mode may send redacted data to a configured provider — an important privacy 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?

Three tight sentences, front-loaded with the primary action, then the preservation guarantee, then the skip condition and the privacy caveat. 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?

An output schema exists so return values need not be explained, but a 10-parameter tool with nested objects and four enums needs far more than this description provides. Key controls (profile, audience, targetAgent, previousOptimization for re-optimization) are unaddressed, leaving an agent unable to use the tool's main levers correctly.

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 10 parameters, including nested context objects and enums like profile, audience, and targetAgent. The description only gestures at 'local vs non-local mode' and 'bounded guidance', leaving the semantics of mode, profile, audience, targetAgent, disabledPasses, and previousOptimization entirely undocumented. It does not compensate for the coverage gap.

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 (improve) and resource (a vague or substantial task/prompt) before execution, which is distinguishable from siblings like evaluate_prompt and inspect_prompt. It stops short of explicitly naming which sibling to use when the request is already clear.

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?

Gives an explicit when-not rule ('Skip trivial or exact-wording requests') and a default posture ('Local by default'), which is more than most definitions provide. It does not name alternative siblings (e.g., evaluate_prompt, adapt_prompt) for adjacent cases, so it falls 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.

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds one meaningful boundary — it does not select a paid model — but says nothing about how a profile is chosen, what it contains, or how to use the result downstream.

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 short sentences, with the action front-loaded and the constraint second. No wasted words, though the terseness contributes to the underspecification elsewhere.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The gaps are the undefined notion of a 'profile' and the undocumented prompt parameter for a tool whose whole purpose is profile selection.

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 single 'prompt' parameter is undocumented anywhere. The description only implies via 'for a task' that the prompt is the task text, but gives no format, length, or content expectations to compensate for the coverage gap.

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 (Choose/suggest) and resource (a proportional local optimization profile) for a task. The qualifiers 'proportional' and 'local' plus the boundary 'does not select a paid model' partially distinguish it from optimize_prompt, though what a 'profile' concretely is remains undefined.

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?

Gives one explicit triggering condition, 'Use when complexity is unclear,' which is real guidance. However it names no sibling alternative (e.g., optimize_prompt, evaluate_prompt) and gives no when-not condition beyond the paid-model exclusion.

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