RPCS-1 Agent Tuner & Translator

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that the tool is deterministic and stateless with no server-side storage, which provides useful behavioral context beyond annotations. Could mention error handling or response format.

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?

Description is concise and well-structured, covering purpose, usage, determinism, and sibling integration in a few sentences. Could be slightly tighter, but overall efficient.

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?

Given the complexity (two-step, multiple primitives, no output schema), the description covers most aspects: how to invoke, what the result is for, and stateless nature. Lacks explicit details on the output JSON structure, but the schema URL provides a reference. Mostly complete.

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% (the schema already explains that omitting answers returns questions). The description adds meaning by explaining the two-step process, the meaning of each primitive, and the continuous scale. This goes well beyond the schema alone.

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?

Clearly states the verb 'Build a ReceiverProfile' and specifies the five primitives (TI, SG, FT, UE, AR) with their continuous 0-100 scale. Distinguishes from sibling tools by mentioning the profile should be passed to render_reply and prepare_prompt.

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?

Provides explicit two-step usage: call with no answers to get questions, call with answers to get profile. Also instructs to store the profile and use it on every turn. Lacks explicit exclusions or alternatives to sibling tools, but the context is clear.

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 indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context by stating it uses the RPCS-1 framework and returns interpretations and clarifying questions, enhancing understanding beyond annotations.

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 two sentences: the first states purpose and methodology, the second lists outputs and usage. It is front-loaded, concise, and contains no unnecessary words.

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 key outputs (AR level, confidence, interpretations, clarifying questions, suggested next step) and usage context. Despite no output schema, it provides comprehensive information. Minor lack of error handling details, but overall complete.

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 100%, with both 'text' and 'risk' well-described in the schema. The description does not add further parameter meaning, meeting the baseline of 3.

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 clearly states the tool detects ambiguity in user messages using a specific framework and lists specific outputs (AR level, confidence, etc.). It distinguishes itself from sibling tools like normalize, recommend_agent_configuration, and rewrite.

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 explicitly says 'Use when a user says something vague, passive-aggressive, or underspecified,' providing clear context. It does not mention when not to use or alternative tools, but the guidance is helpful.

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, and destructiveHint=false, covering safety and idempotency. The description adds no additional behavioral traits beyond what annotations provide, so it does not exceed the baseline.

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 two sentences, front-loaded with the main action and immediate usage guidance. Every sentence adds value, with no wasted words.

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 tool with one parameter and clear annotations, the description sufficiently covers purpose and usage. It could optionally hint at the output style, but it is adequate as is.

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 100% with the parameter 'text' described as 'Fragmented text to normalize.' The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

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 clearly states the verb ('clean up') and the resource ('fragmented text'), and explicitly mentions the use case ('stream-of-consciousness or fragmented input'), distinguishing it from siblings like 'rewrite' or 'interpret'.

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 explicitly says when to use the tool ('when a user types stream-of-consciousness or fragmented input'), providing clear context. It does not mention when not to use it, but the sibling tools provide implicit alternatives.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explaining the tool returns recovered intent, canonical translation, ambiguity level, and a clarify/commit decision, which goes beyond the annotations and helps the agent understand behavioral outcomes.

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 four sentences long, each serving a clear purpose: role, inputs/outputs, usage instruction. No unnecessary words, well-structured and 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?

Given the tool has 3 parameters with a nested object and no output schema, the description adequately covers the high-level behavior and outputs. It lacks detailed return format but provides conceptual understanding sufficient for an agent to call the tool appropriately.

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 100%, so the description does not need to add much parameter info. It mentions 'raw message' and 'ReceiverProfile' but the schema already describes them fully. The profile's role in clarify-vs-commit is hinted but not elaborated, so minimal additional value.

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 clearly states the tool's role as the inbound half of the Translation Bridge loop, taking raw messages and profiles to produce intent, translation, and ambiguity. It distinguishes itself by specifying the inputs and outputs, which differentiates it from sibling tools like 'interpret' or 'render_reply'.

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 explicitly states to 'Call this before acting on any ambiguous user request,' providing clear context for use. It does not explicitly mention when not to use it or compare to alternatives, but the instruction is direct and actionable.

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?

The description adds 'Deterministic, stateless, read-only — does not store past recommendations' beyond annotations (readOnlyHint, destructiveHint). This confirms and extends annotation hints, providing valuable behavioral context.

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 two sentences, front-loaded with the main action and followed by behavioral traits. Every sentence adds value with no redundancy or unnecessary detail.

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?

Given the tool's complexity (nested objects, multiple output fields), the description sufficiently covers purpose, inputs, outputs, and behavioral traits. The existence of an output schema reduces the burden. Minor gaps: no mention of prerequisites or edge cases, but overall 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?

The description explains the overall structure of inputs and outputs, mentioning specific receiver profile values and platform parameters. While schema coverage is 33%, the description compensates by summarizing the key dimensions and return fields.

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 clearly states the tool's purpose: 'Diagnose why a deployed AI agent may fail' and lists the inputs and outputs. It distinguishes from siblings (interpret, normalize, rewrite) by focusing on configuration recommendation.

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 implies usage via its purpose, and the behavioral traits (deterministic, stateless, read-only) guide when to use. However, it does not explicitly state when not to use or provide direct alternatives among 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?

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description aligns by stating it returns instructions without side effects. The description adds context about the loop and deterministic nature, but annotations already cover the core behavioral traits.

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 two sentences, front-loaded with the core purpose, and every sentence adds value. No wasted words or redundancy.

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?

Given two parameters, full schema coverage, and annotations, the description explains the tool's role in the loop and what to do with the output. It is complete enough for the agent, though lacking explicit return value details (no output schema).

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 100% with clear descriptions for text and profile fields. The description reiterates the parameters and notes the profile comes from calibrate_profile, adding minimal extra meaning. Baseline 3 is appropriate as the schema already documents parameters well.

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 clearly states the tool's purpose: it is the outbound half of the Translation Bridge loop, taking a draft reply and a user's ReceiverProfile to return deterministic rendering instructions. The verb 'render' and resource 'reply' are specific, and it distinguishes from siblings like calibrate_profile (which produces the profile) and interpret (inbound).

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 explicitly advises to call this tool on every reply to a calibrated user, and to apply the instructions before answering. It implies the context of use after calibration, but does not list explicit when-not-to-use or alternatives, though sibling tools provide some implicit guidance.

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 indicate read-only and idempotent behavior, but the description's phrasing 'Get rewrite instructions' is misleading—it implies returning instructions rather than the actual rewritten text. This could confuse an agent about what the tool returns.

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 wasted words. The key information (action, styles, usage) is front-loaded. Minor wording imprecision ('instructions') doesn't detract significantly from conciseness.

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 only 2 parameters and annotations. The description lacks details about the return value format or constraints (e.g., maxLength). It is minimally adequate but could be more complete for an AI agent.

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 100% with clear parameter descriptions. The tool description lists the enum values again, which is redundant. No additional meaning beyond the schema is provided.

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 clearly states the tool adapts text to a specific style and lists the available styles. However, it says 'Get rewrite instructions' which could be misinterpreted as returning instructions rather than the rewritten text, slightly reducing clarity.

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?

Explicitly says 'Use when communication needs tone adjustment.' This provides a clear usage context. It does not mention when not to use or alternatives, but the sibling tools are distinct enough.

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