Traffic Parrot

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds value beyond that by naming exactly what is destroyed (the personal data submitted with the request) and the ownership guard requiring the matching email, which is behavioral context annotations cannot express. It does not say whether erasure is reversible or how failures are surfaced, keeping it short of a 5.

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 sentences, front-loaded with the action and its destructive side effect, then the trigger, then the permission constraint. Every sentence earns its place, though the email-matching clause is repeated almost verbatim from the schema parameter description.

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 carry the destructiveness/idempotency profile. What remains is what the description provides: the destructive scope and the ownership precondition. Only the irreversibility of the erasure is left unstated, which is a minor gap for a two-parameter 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 100%, so both email and requestId are already documented, including the matching constraint and the pointer back to request_trial. The description restates the email-matching rule but adds no format, sourcing, or edge-case detail beyond the schema, so the baseline of 3 applies.

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 (withdraw) plus a second concrete effect (erase the personal data submitted with it), naming the resource explicitly. An agent can distinguish it from request_trial, get_trial_status, and submit_feature_request without opening any 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?

Gives a clear trigger condition: 'Use this if your user changes their mind, or asks you to remove their details.' That is real when-to-use guidance, but it names no alternative or exclusion (e.g., what to do instead if the request should merely be cancelled rather than erased).

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 and openWorldHint=false, so the description needn't restate safety. It adds real context beyond them: the running-instance precondition and the handoff to get_trial_onboarding, which an agent cannot infer from the empty 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?

Three tight sentences: what it reads, why to call it, and the precondition plus fallback. Front-loaded and free of 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?

For a zero-param, read-only tool with no output schema and annotations covering safety, the description supplies everything needed: the target resource, the decision it supports, and the setup prerequisite.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond what the empty schema already shows.

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 ('Read Traffic Parrot's product overview and documentation index (llms.txt)') and clarifies the artifact is agent-oriented. The scope is distinct from every sibling, which are all trial/feature-request tools.

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 when to use it ('judge whether Traffic Parrot fits your user's problem', 'find the reference page for a protocol or feature') and gives a precondition ('assumes Traffic Parrot is already running') plus a redirect ('call get_trial_onboarding' to start it).

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing the exact subject matter the returned content spans, which is the behaviorally relevant fact for a static content tool; it omits only the return format (text vs. structured), which is a minor gap.

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, front-loaded with the content inventory and ending with the when-to-call cue. The parenthetical protocol list is long but each item is informative, so it earns its space; structure is efficient without being padded.

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?

With no input parameters and no output schema, the description must convey what the agent receives, and it does so by enumerating the covered topics. The only missing piece is the response format/verbosity, which is a small omission for a read-only documentation 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?

The tool takes zero parameters, which is the baseline-4 case per the rubric. Nothing in the description is needed to disambiguate arguments because there are none.

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 resource (trial onboarding content for Traffic Parrot) and enumerates exactly what it covers: ports, start/stop per OS, licence location, and first mock per protocol. It is clearly a content-retrieval tool, though it never explicitly distinguishes itself from the sibling get_documentation, so an agent must infer the boundary.

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?

"Call this once your user has the download, or earlier to tell them what to expect" gives a concrete trigger condition plus a legitimate earlier-use case. It does not name get_documentation as the alternative for general reference material, so the routing guidance is clear but not exhaustive.

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 (readOnlyHint=true, openWorldHint=false), but the description adds genuinely new behavioral context: the reply is state-only and never a link, and the link is delivered solely to the request's email. That last point is operationally important for the agent's follow-up behavior.

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 sentences, front-loaded with purpose and state enumeration, then the parameter, then the follow-up instruction. No filler; every sentence carries actionable 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?

With an output schema present, return values need not be re-explained, and the description still supplies the crucial caveat that the response never contains the link. An agent has everything needed to call the tool and act on the result.

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% and there is a single required parameter, so the schema already documents requestId fully. The description's phrase 'the request id that request_trial returned' largely restates the schema text, adding only provenance framing. Baseline 3 applies.

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 ('Check the state') and resource ('a trial request'), and enumerates the four possible states, which makes the tool's purpose unambiguous. It is clearly separable from the sibling request_trial, which creates rather than inspects a request.

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 ties usage to the sibling: 'Pass the request id that request_trial returned,' establishing the ordering dependency, and tells the agent what to do once the state is ready. It stops short of stating when NOT to use it (e.g., versus delete_trial_request), so it is strong but not exhaustive.

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 only declare it is a non-idempotent, non-read-only, open-world write. The description goes far beyond that: it discloses data destinations (Mailchimp, US-based), the confirmation-email flow, manual UK-hours approval latency, build time, that no download link is returned, and duplicate-address behavior. This is exactly the extra context annotations cannot carry.

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 purpose is front-loaded and the critical "IMPORTANT" warning is elevated before the legal boilerplate. It is long, but for a tool that transmits personal data under GDPR and triggers irreversible emails, most paragraphs earn their place; the privacy/retention block is the densest section but is defensible.

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?

With an output schema present, return values need not be enumerated, yet the description still clarifies that only a reference id comes back and no link does. Combined with the data-flow, timing, and consent guidance, an agent has everything needed to decide and act 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 coverage is 100%, so the baseline is 3; the description earns an increment by adding constraints not in the schema, notably that the email is a real person's data that must not be invented, and that the trial link only ever goes to that email. It does not, however, walk through the other optional fields (problem, protocols, agentClient).

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 first sentence states a specific verb and resource ("Request a Traffic Parrot trial on behalf of the human you are working for") and immediately grounds it by describing what Traffic Parrot is and which protocols it covers. It is unmistakably distinct from the sibling read/delete tools like delete_trial_request and get_trial_status.

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?

Explicit when-to-use ("Use this when your user wants to evaluate it"), explicit preconditions (user must have asked and agreed to be contacted, agreement must be shown and approved), and an explicit alternative for undoing the action (delete_trial_request). It even names a misuse case ("Do not invent an email address").

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 this is a non-read-only, non-idempotent, non-destructive, closed-world write. The description adds genuinely useful context beyond them: the privacy implication that a contact email is a real person's personal data and should only be shared with consent. It does not mention submission confirmation or rate limits, but the added privacy guidance is real value.

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 sentences, front-loaded with purpose, then the usage trigger, then the privacy caveat. Every sentence earns its place and nothing is padded.

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 annotations cover the mutation safety profile. The description covers purpose, trigger and the one non-obvious behavioral risk (personal data), leaving only minor details like submission acknowledgement unaddressed.

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%, so all four parameters are already documented (including email being optional and consent-dependent). The description reinforces the email consent condition but adds no syntax or format detail beyond the schema, so the baseline 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?

States a specific verb and resource ('Send a feature request or product feedback to the Traffic Parrot team') and is trivially distinguishable from siblings like request_trial, get_trial_status and delete_trial_request. An agent can identify the tool's function 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?

Gives an explicit trigger condition: 'Use this when your user wants something Traffic Parrot does not currently do.' That clearly bounds when to invoke it, though it does not name an alternative tool or state when not to use it.

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