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

Adds substantial context beyond the annotations: per-chain gas/rent economics (890880 lamports rent-exempt minimum, ~2039280 lamports ATA rent paid by sender), ATA creation via CreateIdempotent, the cryptic 400 'Insufficient funds' meaning, and the 201/202 return-and-retry-with-same-idempotencyKey behavior. This is exactly the destructive/irreversible detail an agent needs.

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?

It is front-loaded with the action, but the body is a dense run-on that repeats schema content ('Omit tokenContract or set it to null', 'do not use the zero address') and cycles back through rent/fee details. Much of it earns its place, but structure and trimming are lacking.

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 complex, destructive, multi-chain, 7-parameter tool with nested recipients, the description covers recipient types, mixed-wallet constraints, amounts, rent/fee edge cases, error interpretation, and return codes. Nothing essential to correct invocation is 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 coverage is high (86%), so the baseline is 3, but the description adds real meaning: omit/null tokenContract for native, smallest-unit amounts per chain (ETH 18, SOL 9, USDC 6), and the ethWalletAddress vs solWalletAddress routing rule after connect_lookup. It clarifies semantics the schema alone 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?

Opens with a specific verb+resource+scope: 'Execute a Smart Send from the API key owner Connect embedded wallet.' It further disambiguates from siblings by naming connect_lookup and connect_drop_balance and describing chain/recipient handling, so an agent can distinguish it immediately.

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 explicit routing rules ('Always call connect_drop_balance first', and for linkedin/slack 'use connect_lookup first, then type wallet'), which is clear context for use. It lacks a general when-not-to-use statement or comparison against other transfer tools, so it falls short of the 5 bar.

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, and the description still layers on substantial behavior: zero balances are omitted, per-chain data sources (Blockscout for 4663, Moralis for 143), Solana lamport/rent semantics, and pre-failure conditions for ATA rent. 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?

Purpose and the connect_drop prerequisite are front-loaded, and each subsequent sentence carries chain-specific operational detail rather than filler. It is dense and long for a one-parameter tool, but the Solana rent/fee figures are decision-relevant rather than padding.

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 output schema, the description correctly explains the return semantics (omitted zero balances, per-chain token sourcing) as well as the preconditions for a successful downstream drop. An agent has enough to both interpret the result and decide whether a send can proceed.

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% for the single chainId param, so baseline is 3, but the description adds real meaning beyond the schema: it documents special behavior for chainId 4663, 143, and 1399811149 that the schema's one-line description does not convey.

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 ('Get native and token balances for the API key owner embedded wallet') and scopes it further by naming which chains are accepted. It also explicitly positions itself relative to the connect_drop sibling via 'Always call before connect_drop', so an agent can distinguish intent 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 a clear when-to-use directive ('Always call before connect_drop') and states the accepted chain classes. It does not name any when-not condition or an alternative tool for balances outside Smart Send/delegation chains, so it stops short of full routing 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 already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description earns credit by explaining the meaning of the returned compatibility flags and the special Solana identifier. It still says nothing about return shape or ordering, which a no-output-schema tool would benefit from.

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 dense sentences, front-loaded with what the tool lists before the flag semantics, with no filler. The parenthetical chainId detail is compact, though the second sentence is information-packed enough to border on terse.

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 carries the burden of explaining the return values and does so for the two named flags (lookup, drop). 'Per-feature compatibility' implies additional feature flags that are never enumerated, leaving a small 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 document and the baseline is 4. No parameter-related gaps exist.

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 ('List product chains') plus the distinguishing attribute ('with per-feature compatibility'). An agent can tell this apart from the connect_lookup/connect_drop siblings by topic, though the description never explicitly contrasts itself with 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?

Usage is implied rather than stated: describing which flags are true for which chain types and noting the Solana chainId for connect_drop/connect_drop_balance hints this is a pre-flight capability check. There is no explicit 'use this when…' or 'do not use for…' guidance, so the agent must infer the workflow.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds non-obvious context that these are reference prices that may diverge from live paywall amounts, which is exactly the kind of semantic caveat annotations cannot express. It does not describe the return shape, but annotations carry most of the burden.

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 that front-loads the core action and folds the caveat into a compact parenthetical. Every clause earns its place with no padding.

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, non-destructive read with no output schema, the description covers purpose and the key semantic caveat about reference vs live prices. It could add a note on whether the list is global or scoped, but nothing essential to invoking it correctly is 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify or omit. No parameter-level confusion is possible.

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+resource: 'Get public x402 list prices for lookup and scores.' That is clearly distinct from data-oriented siblings like connect_lookup, connect_scores_batch, and connect_trust_graph. It stops short of a 5 because 'x402' is domain jargon an agent may not resolve, and no sibling is named for contrast.

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 parenthetical 'reference only; live paywall amounts are in 402 responses' gives real routing guidance: use this for list/reference pricing, not for live paywall amounts. It stops short of a 5 because it does not name the alternative tool or endpoint that supplies live amounts.

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?

Explicitly discloses a hidden side effect: resolving a recipient without a wallet provisions one, so the operation is read-only for the caller but not the recipient. This directly pre-empts the readOnlyHint=true annotation and tells the agent about state mutation on the other party, which annotations alone conceal. Retry-on-processing semantics add further behavioral 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 tight sentences with zero filler, front-loaded with the core purpose followed by the critical side-effect caveat and the retry rule. Every sentence earns its place.

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 no output schema, the description should explain what comes back. It hints at a status field ('processing') but never describes the returned wallet/status shape, leaving a small gap. The mutation caveat and retry rule cover the highest-risk unknowns for this one-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 the schema already documents the recipients array and its fields. The description adds only a conceptual gloss ('social identities') without syntax or format detail, 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 (resolve) and resource (social identities → EVM/Solana wallet addresses), so the agent immediately knows what it does. It is clearly distinguishable from generic lookup siblings, though it never names connect_lookup_exposed, which is the closest relative.

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 concrete operational rule — 'if status is processing, retry the same payload' — which is useful invocation guidance. However, it never states when to choose this over connect_lookup_exposed or any other sibling, and no exclusions are given, so usage is only partially addressed.

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, openWorld, non-destructive), so the bar is lower. The description adds real behavioral context beyond that: it discloses the return payload shape (enriched profile, scores, wallet addresses) and an unusual runtime condition — a possible x402 charge when the profile owner monetizes lookups.

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 compact sentences with the resource and return contents front-loaded, then the recipient variants, then the payment caveat. No filler, though the recipient-type sentence partially duplicates the schema 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?

No output schema exists, so the description does the work of naming the returned data (platforms, profile, scores, wallet addresses), and it flags the payment condition. It is adequate for an idempotent read tool; the missing piece is how the payment requirement surfaces or how to satisfy it.

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 the nested recipient object is already documented with its enum of types, including wallets and usernames. The description mirrors that ('social account, an exposed wallet (EVM/Solana/smart wallet), or a Connect username') without adding id format, required-vs-optional rules for id/username, or examples, so it clears the baseline but no more.

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 ('List platforms a recipient has exposed on Connect') and enumerates what's returned (profile, scores, wallet addresses), which separates it from a plain lookup. It never names the sibling connect_lookup, so the boundary between this and the non-exposed lookup is left to inference.

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 explains what kinds of recipients are accepted (social account, exposed wallet, Connect username) and warns that x402 payment may be required, which is genuinely useful context. However, it never says when to prefer this over connect_lookup or connect_scores_by_account, nor what to do if payment is required.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds value beyond them by disclosing the return payload (profile, scores, linked accounts), which matters because there is no output schema. It says nothing about rate limits or auth prerequisites, keeping it under 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?

Two short sentences, the payload statement front-loaded and the routing hint second. Every clause earns its place with 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?

With no output schema, the description carries the burden of describing returns, and it does so at a summary level (profile, scores, linked accounts). Annotations cover the behavioral profile. The only gap is that it does not sketch the shape of 'linked accounts' or 'scores', so it is complete enough to select and call but not to anticipate the response.

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. The description reinforces this implicitly by scoping the result to 'the API key owner' rather than accepting identifiers, so the parameterless contract is unambiguous.

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 ('Get the Connect profile') plus exactly what is included (scores, linked accounts) and whose data it is (the API key owner). This scope — key-owner's own identity, zero parameters — cleanly separates it from siblings like connect_scores_by_account, connect_scores_by_username, and connect_trust_graph.

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 to identify which user the key belongs to' gives a clear trigger condition for calling the tool. It does not name alternatives or state when NOT to use it (e.g., when you already have a username and should use connect_scores_by_username instead), so it stops short of the top tier.

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/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: result cardinality ('one result per request user') and what the optional filter actually accomplishes ('sets passedFilter'), which is not derivable from the annotations. It stops short of describing failure behavior for unresolvable users.

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, no filler, and the core capability is front-loaded ahead of the optional filter detail. The parenthetical score ranges are the only element that arguably duplicates the schema and could be dropped.

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 output schema and a nested two-param input, the description carries more burden than it meets. It hints at output shape via 'one result per request user' and explains the filter's effect, but omits what a score result contains, batch-size limits, and how partial failures or unknown identifiers are handled.

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 50% and the enum/range details for minScore are already in the schema, so the description's restatement of the 0–100 / 0–1 / 0–2800 bands is largely redundant. Its one genuine addition is explaining that the filter produces a passedFilter flag, but it says nothing about the users array's id/type/username shape or how 'linked accounts vs Connect usernames' maps onto the type enum.

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 (batch scores) plus the scope ('linked accounts or Connect usernames') and cardinality ('one result per request user'). The word 'Batch' in the name and 'one result per request user' imply it handles multiple identities, but the description never names the singular siblings connect_scores_by_account / connect_scores_by_username to make the routing decision explicit.

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 only implied: the batching semantics suggest this is the multi-user path, but there is no explicit 'use this when you have many users, use connect_scores_by_username for one' guidance. No prerequisites, no limits on batch size, no 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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that: no indication of what a score represents, its range, rate limits, or what happens when an account is not found.

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?

It is short, but it is a verbless sentence fragment rather than a front-loaded action statement, so its brevity reflects under-specification rather than efficiency. No sentence here explains what the tool actually returns or does.

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 two-parameter, enum-driven lookup with no output schema and an open-world annotation, the description leaves the agent guessing at identifier format, score semantics, and how to choose between this and the sibling score tools. The annotations carry the safety story, but the functional context is essentially absent.

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 only loosely hints that 'identifier' is an account or wallet. It does not explain the ten-value platform enum, nor the expected identifier format (e.g., handle without '@', bare address, E.164 phone), which the schema leaves entirely undocumented.

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 fragment 'Scores for a linked social account or wallet' names the resource (account/wallet) but never states the action or what 'scores' means — a reputation score, a numeric rating, a risk score? It only faintly distinguishes from connect_scores_by_username (account vs username) and says nothing about how it differs from connect_scores_batch.

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, no mention of the alternative siblings (connect_scores_by_username, connect_scores_batch), and no prerequisites such as whether the account must already be linked. The agent must infer everything from the tool name.

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, openWorldHint, and destructiveHint=false, so the safety profile is fully structured. The description adds nothing beyond this — no disclosure of lookup failure behavior, rate limits, or whether the username must be an existing public handle. For a tool whose annotations carry the safety story, it contributes no extra 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?

A single short sentence fragment with no wasted words, so it is concise and front-loaded. However, the terseness tips into under-specification for a sibling set this large, so brevity here is not fully earned.

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 is simple (one required parameter) and annotations cover its safety profile, which lowers the bar. Still, the description offers no information on the return value, error/not-found behavior, or how it relates to the batch and by-account variants, leaving real gaps for correct 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%, and the schema only specifies a string with minLength 1. The description does add some meaning by clarifying the parameter is a 'Connect public username' rather than an account ID, hinting at the expected identifier domain. But it leaves format and validity requirements undocumented.

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 pairs a verb ('Scores') with a resource ('Connect public username'), which loosely signals a scoring lookup. However, 'Scores' is ambiguous about what is being scored or returned, and the phrasing largely restates the tool name connect_scores_by_username. It only weakly differentiates from siblings like connect_scores_by_account or connect_scores_batch.

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 guidance on when to use this tool versus connect_scores_by_account, connect_scores_batch, or connect_lookup. The agent must infer the choice purely from the tool name and the single parameter. No prerequisites or exclusions are stated.

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 annotations already declare this as a read-only, idempotent, open-world, non-destructive operation. The description adds the important constraint that results are limited to depth 1 and explains context matching behavior, but it does not describe return values or failure 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?

Two short sentences with no wasted words. The core purpose is front-loaded and the context-omission rule follows immediately.

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 tool with nested objects and no output schema, the description is adequate but incomplete. It does not explain the return shape or result format, though the annotations and fully described schema cover most invocation needs.

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 most parameter meaning comes from structured fields. The description adds meaningful semantics for the optional context parameter by clarifying that omitting it matches any context, which resolves a likely ambiguity beyond the schema text.

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 and resource: checking whether identities are in a trust graph at depth 1. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as connect_trust_graph or connect_lookup.

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 only guidance is 'Omit context to match any context,' which explains a parameter default rather than when to choose this tool over alternatives. There is no explicit when-to-use or when-not-to-use 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 already declare readOnly=false, destructive=true, idempotent=true, openWorld=true. The description adds real value beyond these: it explains the no-op dedup path, the auth/enrollment prerequisites, and that gas is required on Base. It does not clarify what 'destructive' means for this tool (on-chain spend, non-reversible attestation), leaving a small 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?

Three tight sentences: what it does, the dedup edge case, then prerequisites last. No filler, and the core action 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?

For a no-output-schema, nested-object mutation tool, it covers auth, gas, and idempotent behavior well. It omits what a successful response contains and the effect of expiresIn timing, which an agent might want, but nothing critical is 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 100% and all four parameters are documented there (to/level/context/expiresIn with ranges). The description only reinforces that the target may be a wallet or social identity, which the nested schema already says, so it adds little beyond the baseline.

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 (Create), resource (unidirectional trust attestation), chain/standard (Base, EAS), and the source/target of the attestation. This clearly separates it from siblings like connect_trust_revoke, connect_trust_check, and connect_trust_graph.

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 the operational preconditions explicitly (CONNECT_API_KEY, Smart Send attestation signer enrolled, ETH on Base for gas) and states dedup behavior when an identical attestation exists. It does not explicitly contrast when to prefer this over connect_trust_revoke or connect_trust_check, 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 readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds the important 'depth 1' traversal limit and clarifies outgoing vs incoming semantics, but omits return format, pagination, authentication needs, 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?

The description is a single front-loaded sentence with no wasted words. The scope constraint is stated immediately.

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 is simple and annotations cover safety, but there is no output schema and the description does not explain what a trust edge result looks like, whether results are paginated, or any limits. It is minimally adequate but leaves return-value semantics to inference.

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 50%: platform and direction have schema descriptions, while context and identifier do not. The description's 'outgoing or incoming' maps to direction and 'identity' loosely covers platform/identifier, but it adds little beyond the schema and does not compensate for the undocumented context parameter.

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 (List), resource (trust edges), and scope (outgoing or incoming for an identity at depth 1). It is clear what the tool does, though it does not distinguish itself from siblings like connect_trust_check or connect_lookup.

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 gives no guidance on when to use this tool versus alternatives such as connect_trust_check or connect_trust_create. Usage is only implied from the verb and resource.

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, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds real context beyond that: the auth requirement (CONNECT_API_KEY) and the on-chain gas requirement (ETH on Base), which signals this is a real transaction with cost, plus the scoping semantics of the context parameter. It stops short of saying whether revocation is reversible or what happens to the underlying attestation.

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 the core action, then scoping, then prerequisites. Every sentence carries information, though the context-scoping sentence duplicates what the schema already states, which is the only minor 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?

For a destructive, on-chain mutation tool with no output schema, the description covers action, direction, scoping, and both auth/gas prerequisites. Missing only edge behavior (no-op when nothing to revoke, reversibility), which the idempotentHint partially covers. Adequate for correct invocation.

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 the schema already documents both the `to` identity object and the `context` parameter verbatim ('Revoke only this context. Omit to revoke all contexts for the pair.'). The description largely restates that context scoping, adding only the phrase 'for the pair' framing. Baseline 3 applies when the schema carries the load.

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 (revoke), resource (active trust attestations), direction (from the API key owner to a target), and the optional scoping parameter. An agent can immediately distinguish this from connect_trust_create, connect_trust_check, and connect_trust_graph 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?

The description implies the when (undo an existing trust relationship) and gives prerequisites (CONNECT_API_KEY, ETH on Base), but never explicitly names an alternative or a when-not condition. No guidance on what happens if no matching attestation exists, or how it relates to connect_trust_check for verification first.

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