Compare original and revised prose to detect fact drift and omissions, returning structured editorial feedback while Codex remains the factual authority.
Compare original and revised prose for fact drift and omissions. Structured editorial feedback; Codex remains the factual authority.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | natural-professional | |
| revised | Yes | ||
| language | No | zh-CN | |
| original | Yes | ||
| instruction | No | ||
| max_attempts | No |
Changes observed during successful MCP inspections.
v2.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint=false annotations already establish that this is a safe review operation. The description adds useful context that the output is structured editorial feedback and not the factual authority, but it does not explain the return shape, variability, or why idempotentHint=false.
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, front-loaded with the core comparison purpose and then the authority caveat. There is no wasted text.
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 tool has six parameters, no parameter descriptions, no output schema, and no sibling routing guidance. The description states the high-level purpose and return type in prose, but it is not complete enough to guide parameter use or selection versus adjacent gemini_* tools.
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 description mentions original and revised prose, which maps loosely to the two required parameters. But with 0% schema description coverage across six parameters, it provides no meaning for style, language, instruction, or max_attempts, so it does not compensate for the schema 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?
The description states a specific action and resource: compare original and revised prose for fact drift and omissions. It is clearly distinct from rewrite/polish siblings, but it does not explicitly name an alternative or state sibling boundaries.
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 comparison-for-fact-drift purpose implies when to use the tool, and 'Codex remains the factual authority' hints at a boundary on reliance. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative such as gemini_polish or gemini_rewrite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.