Anwani

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

With no annotations, the description carries the full behavioral burden, and it does add real context: a user-quota limit on creation and a strong anti-hallucination guardrail against sample/demo data. It still omits permissions/auth requirements, duplicate handling, what success returns, and — notably — any explanation of the required idempotency_key's effect on retries.

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, then the hard requirement, then the fallback behavior; there is no filler. The anti-invention warning is emphasized twice (coordinates/city/display name, then sample/demo data), which is mild redundancy but defensible for a safety rule.

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 18-parameter mutation with no annotations and no output schema, the description covers the highest-risk failure mode (fabricating location data) well but leaves most fields and all post-call behavior unexplained. An agent can call it safely, but not confidently about what happens on success or how idempotency behaves.

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 only 22% across 18 parameters, so the description must compensate, but it only speaks to latitude/longitude (and obliquely to city/display name via the "never invent" rule). Fourteen other fields, including the required idempotency_key, get no explanation anywhere, leaving an agent to guess at their semantics.

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 ("Create one address") plus a scope constraint ("within the user quota"), which is enough to distinguish it from list_addresses/patch_address/delete_address. It never names those siblings explicitly, so the differentiation is inferred from the verb rather than stated.

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 precondition (user must supply a real map pin with latitude/longitude) and an explicit when-not path: if the user gave no coords, Maps link, or clear place, ask first instead of calling the tool. It stops short of comparing against siblings — e.g. nothing says to use patch_address when editing an existing one.

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 destructiveHint=true, so the safety profile is partly covered. The description adds genuinely useful context by stating the deletion is permanent and limited to addresses owned by the connected account, but it says nothing about reversibility guarantees, confirmations, or failure modes.

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?

One sentence, front-loaded with the destructive verb, zero filler. Nothing could be trimmed 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?

For a destructive single-parameter mutation with no output schema, the description covers irreversibility and ownership scope but leaves the parameter unexplained. Adequate but with a clear gap on how to supply 'code'.

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 single parameter 'code' is never mentioned in the description. An agent gets only the name and the regex pattern from the schema, so the description does not compensate for the missing semantic explanation of what 'code' identifies.

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 gives a specific verb ('Permanently delete') and resource ('an address'), plus a scope qualifier ('owned by the connected account'). It is unambiguously distinct from siblings like patch_address or list_addresses, though it never names an alternative 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?

There is no when-to-use guidance and no mention of alternatives such as patch_address for modification or share_address for delegation. The only implied condition is ownership by the connected account, which is a constraint, not usage 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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add non-obvious context — it does contribute that results are bounded by the same quota as app/Telegram. It says nothing about pagination, ordering, or whether the list can be empty, so the added value is modest.

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?

A single sentence with no filler, front-loading the verb and resource and appending only the one piece of non-obvious context. Nothing could be removed without losing 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?

For a zero-parameter, read-only list operation with no output schema, the description covers scope (owned by the connected account) and the quota constraint. Only the shape of the returned list is left implicit, which is a minor 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the schema already declares additionalProperties=false.

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 (List) and resource (addresses) scoped to the connected Anwani account, which cleanly separates it from the create/delete/patch/share siblings. It does not explicitly name or contrast with a sibling, but the operation is unambiguous.

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?

No statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The 'same quota as app/Telegram' note hints at a shared limit but does not tell an agent when this call is appropriate.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses partial-update semantics ('only provided fields', 'does not clear omitted fields') and a hard restriction ('coordinates cannot be changed'), which is real added value for a mutation tool. However it says nothing about permissions/auth, reversibility, or error behavior when the code is invalid.

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, front-loaded sentences with no filler; the most important constraint (partial update, omissions preserved) leads. Slightly terse given the scope, but nothing is wasted.

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?

A nested 15-field mutation object with no annotations and no output schema warrants more disclosure than provided. Update semantics are covered, but the identifier parameter, authentication expectations, and what a successful patch returns are all missing.

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 compensate. It gives one example field ('instructions') and the crucial semantics of omitted keys in the changes object, which is genuinely helpful. But the required 'code' parameter is never explained and the remaining ~14 updatable fields are left to schema names 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?

States a specific verb (patch) and its defining behavior: only provided fields are updated. Combined with the tool name, an agent can tell this apart from create_address/delete_address/list_addresses, but it never names those siblings or explicitly says it modifies an existing address record.

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?

No when-to-use guidance and no explicit routing to alternatives. The reader must infer from the word 'patch' that this is the partial-update path versus create_address or delete_address; nothing in the text establishes that.

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 readOnlyHint annotation already covers the safe-read nature. The description adds a useful behavioral detail—'Does not return internal IDs'—but does not describe other traits such as what is returned, authentication requirements, or rate limits.

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 primary action front-loaded. The second sentence adds relevant output context, though it could be slightly more specific.

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, zero-parameter check with a readOnly annotation, the description is adequate but incomplete: it does not state what the tool returns (e.g., a boolean or status object), which would help an agent interpret the result in the absence of an 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?

There are zero parameters, so the schema carries no burden and the description has nothing to clarify. This meets the baseline of 4 for tools with no parameters.

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 verb (Check) and resource (Anwani connected for this user), making the purpose clear. It implicitly distinguishes from the address-manipulation siblings, though it doesn't explicitly name them or the tool's name is generic.

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?

No when-to-use guidance or alternatives are provided. The description only states what the tool does, leaving the agent to infer when this check should be performed relative to address operations.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the description need not restate that. It adds mild value by noting the requirement that the address be 'owned' and that the return is a public deep link, but says nothing about error behavior for invalid or unowned codes.

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?

A single tight sentence with the verb and outcome front-loaded; nothing extraneous and 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?

For a one-parameter read tool with no output schema, the description covers the essential input (an owned code) and output (public deep link). It omits failure cases (invalid format, unowned code) and how the link is produced, leaving minor gaps.

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?

Only one parameter, and the schema conveys its format via the ^[1-9]{9}$ pattern even though schema description coverage is 0%. The description matches the parameter to an 'owned address code', adding a little semantics about ownership scope, but no format or sourcing guidance.

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 ('Return') and a specific resource ('public deep link for an owned address code'), which is distinct from the create/delete/list/patch siblings. It stops short of explicitly contrasting itself with those siblings, but the fetched-artifact framing is unambiguous.

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?

Usage is implied by the phrase 'owned address code' (the caller must own the address), but there is no explicit when-to-use, when-not-to-use, or naming of an alternative tool. An agent can infer the scenario, but nothing routes it definitively.

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