Quidli Connect

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

The annotations only declare destructive/idempotent/openWorld, but the description adds concrete operational behavior an agent could not infer: the 890880-lamport rent-exempt minimum for Solana native sends, the ~2039280-lamport ATA rent paid by the sender, the ~5000-lamport fee, the CreateIdempotent prepend so recipients need not hold the token, the misleading 'Insufficient funds' 400 diagnosis, and the EIP-7702 / Privy policy preconditions. This is exactly the failure-mode context mutations need.

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 length is earned by genuine complexity (8 params, nested recipients, two chains, three token standards), and the critical constraints are front-loaded before the edge cases. It reads as one dense block with no headings, and the EIP-7702 / Privy-policy caveats are duplicated verbatim in the tokenStandard schema description, which is 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, multi-chain, multi-standard transfer tool with no output schema, the description covers everything an agent needs before calling: asset-type branching, rent and fee costs, per-recipient tokenId/tokenAmount requirements, and what the 201/202 statuses mean. Nothing material is left 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 coverage is already 88%, so the baseline is 3; the description still adds meaning beyond it by fixing decimal conventions per asset (ETH 18, SOL 9, USDC usually 6), specifying that tokenContract must be omitted or null for native and must never be the zero address, and stating that Solana native sends create no ATA. It stops short of documenting idempotencyKey and trustFilter beyond what the schema says.

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 and resource: 'Execute a Smart Send from the API key owner Connect embedded wallet.' It immediately scopes the tool by chain (EVM vs Solana chainId 1399811149) and by asset type (native, ERC-20, SPL, ERC-721, ERC-1155), which is far more than a restatement of the name.

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 prerequisite ('Always call connect_drop_balance first'), an explicit routing rule away from this tool ('linkedin and slack are not on /drop — use connect_lookup first, then type wallet'), and retry guidance tied to the 201/202 response codes. The when-to-use and when-not-to-use conditions are both 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?

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?

Goes well beyond the annotations by disclosing idempotent short-circuiting ('identical active attestations are returned without a new transaction'), partial-success semantics ('recipients still provisioning are reported as processing while the others are attested'), and the full auth/gas requirements. These are exactly the edge-case behaviors an agent needs before calling a write tool with destructiveHint=true.

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?

Four sentences, front-loaded with the action and target, then behavior, then prerequisites. Dense but every sentence carries information; the only slight cost is the run-on feel of the prerequisite sentence.

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 4-parameter mutation with no output schema, the description covers what it does, what it needs, what it costs (gas), and how it reports the three possible outcomes (created, reused, processing). Nothing essential to a 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 100%, so the baseline is 3, but the description adds non-obvious semantics: level, context, and expiresIn apply uniformly to every entry in the `to` array, which is a cross-parameter rule the schema does not express. It also frames `to` as accepting wallets, socials, or Connect usernames, reinforcing the enum intent.

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 unidirectional trust attestations on Base (EAS)' — plus the origin (API key owner embedded wallet) and target (wallets or social identities) and the single-transaction batching. This is immediately distinguishable from siblings like connect_trust_revoke and connect_trust_check.

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 concrete preconditions (CONNECT_API_KEY, enrolled Smart Send attestation signer, ETH on Base for gas) and clarifies what happens in the reuse and partial-provisioning cases. It stops short of explicitly naming alternatives such as connect_trust_revoke for removal or connect_trust_check for verification, so routing is implied rather than 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?

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.