Quidli Connect

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

Annotations already carry idempotentHint=true, destructiveHint=true, and readOnlyHint=false, yet the description contributes far beyond them: sender pays ATA rent (~2039280 lamports), the 890880-lamport rent-exempt minimum, ~5000-lamport fees per tx, CreateIdempotent for new ATAs, the 20 SOL/10 SPL pack limits, and 201-vs-202 semantics with same-idempotencyKey retry. It even decrypts a common error (400 on SPL = missing SOL, not missing USDC). No contradiction with annotations; the behavior described matches the idempotent/destructive hints.

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 most load-bearing content is front-loaded in the first sentence, and the description remains dense rather than padded — the chain split, fee tables, and error interpretations are genuinely needed for safe invocation. It is long, but for a two-chain payment tool with ATA mechanics, the length is justified. A few small repetitions ('below that the tx fails', the zero-address warning already in the schema, re-stating decimal rules) keep it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity (EVM + Solana, native + ERC-20 + SPL, ATA rent, social lookups, idempotency), the description is nearly complete and covers prerequisites, per-chain behavior, fee schedules, failure diagnostics, and response codes. The only conceivable gap is the response body shape, but 201/202 illustrated and no output schema exists to document it, so the description carries the needed outcome semantics.

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?

With 83% schema description coverage the schema already carries decimal rules, smallest-unit expectations, the zero-address prohibition, and the recipients/social-detail. The description's incremental value appears in the per-parameter par score: the 20 SOL / 10 SPL recipients-per-tx cap is absent from the schema's recipients description, the native-token null behavior is emphasized, and amountInWei rules tie amountInWei — there is no schema description for idempotencyKey, and the description connects it to retry semantics. It adds value, but part of it duplicates the schema, so 4 rather than 5.

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 opening sentence, "Execute a Smart Send from the API key owner Connect embedded wallet," states a specific verb, resource, and actor that clearly identifies this as the disbursement/transfer tool. The chain and token-type scoping further distinguishes it from siblings like connect_drop_balance and connect_lookup. An agent can tell exactly what this tool does without inspecting 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 explicitly instructs "Always call connect_drop_balance first," directly routing the agent to the prerequisite sibling tool. It then gives concrete decision rules: native vs tokenContract guidance on when to omit/use the contract, social recipients always pay solWalletAddress, and specific failure meanings (400 on SPL often means missing SOL for rent). This is explicit when/when-not guidance rather than implied context.

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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses key behaviors: 'Zero balances are omitted, so a missing token means balance 0' and explains that SOL in this response is spendable lamports excluding rent-locked amounts. It also details Solana ATA rent and fee requirements, which are materially important for interpreting the balance data.

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 long but every sentence carries operational value, covering purpose, prerequisite, zero-balance semantics, EVM checks, Solana nuances, and fee calculations. It is front-loaded with the core purpose and prerequisite, then organizes chain-specific details in a logical progression.

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 compensates by explaining the return semantics (zero balances omitted, SOL as spendable lamports) and providing concrete thresholds for native drops and ATA rent. It gives an agent everything needed to correctly invoke the tool and interpret its results in the context of the sibling connect_drop operation.

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?

Although schema description coverage is 100%, the description adds essential meaning to the chainId parameter by explaining that 1399811149 means Solana mainnet and that EVM chains use their chain ID. It then connects chainId choice to different balance semantics (EVM gas vs Solana lamports and ATA considerations), going well beyond the schema's one-line description.

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: 'Get native and token balances for the API key owner Smart Send embedded wallet on a chain.' It also differentiates itself from the sibling tool by explicitly saying 'Always call before connect_drop.' This makes the tool's role unmistakable.

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 explicit usage guidance: 'Always call before connect_drop' establishes a prerequisite relationship. It also provides chain-specific rules for EVM and Solana, including what conditions must be checked before a drop, such as gas, token balances, and ATA rent.

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 readOnly and idempotent behavior. The description adds useful context by defining the semantic meaning of the two compatibility flags and calling out a specific chainId relevant to the drop feature, going beyond what hints alone convey.

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, information-dense sentence that front-loads the core purpose and then provides necessary clarification. There is no filler or redundancy; every clause 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?

The description explains what the tool returns (product chains with lookups and drop flags) and gives a concrete chain-id example for Solana, which is enough to understand typical usage. It does not mention pagination, but for a list of chains, that's likely nonessential.

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 accepts zero parameters, so the input schema carries no burden. The description correctly focuses on output semantics rather than parameter details, matching the baseline expectation for a no-parameter tool.

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 opening clause 'List product chains with per-feature compatibility' immediately identifies the action and object. It clearly distinguishes this tool from sibling operations by focusing on chain-level feature support rather than individual entity manipulation.

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 'lookup' and 'drop' flags mean)Skip which helps interpret results, but it does not explicitly state when to use this tool over alternatives or mention exclusion conditions. The reference to connect_drop / connect_drop_balance provides some navigational context, but it is incidental rather than prescriptive.

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 mark it read-only/idempotent/open-world; the description adds 'public' and 'reference only', clarifying that returned prices may not be live paywall values. This enriches the annotations with behavioral context, though it still omits output shape.

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?

Single sentence, front-loaded with the operation, then scoped with 'reference only' and the 402 caveat. 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?

Given the zero-parameter signature and rich annotations, the description covers the tool's purpose and its key limitation. It could specify the exact return shape, but for a public reference-price lookup the essentials are present.

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?

With zero parameters and an empty input schema, there are no parameter semantic gaps for the description to fill. The baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States precise verb 'Get' and resource 'public x402 list prices for lookup and scores', immediately distinguishing this reference-price tool from sibling query tools like connect_lookup and connect_scores_batch. The phrase 'reference only' adds scope clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly warns that live paywall amounts are not returned here ('live paywall amounts are in 402 responses'), telling the agent when not to rely on this tool. It does not explicitly name alternative tools, but the 402-response pointer gives clear routing context.

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?

It adds crucial behavioral context beyond annotations: 'Resolving a recipient who has no wallet provisions one for them, so this is read-only for the caller but not for the recipient' and the retry instruction. This enriches the idempotentHint/readOnlyHint annotations without contradicting them.

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 compact: it leads with the purpose, then the side-effect caveat, then the retry condition. Each sentence adds distinct practical value 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 mentions a `status` field and mentions 'processing', but it does not describe the shape of the response (e.g., how the resolved wallet addresses are returned). Given the real side-effect and open-world behavior, a slightly richer description of the expected result would make the tool more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully covers the `recipients` parameter and its nested fields per the 100% schema description coverage. The description does not add anything about the parameters themselves, so a 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?

The description clearly identifies the action ('Resolve social identities to EVM and Solana wallet addresses') and names the resource and output. However, it does not differentiate this from the close sibling `connect_lookup_exposed` or explain difference between 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?

The description gives practical advice ('If status is processing, retry the same payload') and implies a side effect (provisions a wallet for recipients), which informs when it is appropriate to call. But it does not explicitly mention when to use this tool versus alternatives like `connect_lookup_exposed`.

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

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

Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds the important behavior that lookups may require x402 payment when the profile owner charges, which is not expressed in the annotations. This is meaningful extra transparency.

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 concise, information-dense sentences. The core action is front-loaded, the accepted recipients are summarized, and the payment caveat is placed logically. No filler or redundant restatement.

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?

Despite lacking an output schema, the description indicates the returned information: platforms, profile, scores, and wallet addresses. For a read-only lookup with one parameter, this is mostly complete; it doesn't cover payment failure behavior, but that 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?

Schema description coverage is 100%, so the recipient parameter is already well documented. The description mainly reiterates acceptable recipient forms and explains the lookup purpose, but it doesn't add deeper semantics about how to specify IDs versus other identifier fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists the platforms a recipient has exposed on Connect, and specifies the enriched output (profile, scores, wallet addresses). It is specific about the verb and resource, but it doesn't explicitly distinguish itself from the sibling connect_lookup, which is a closely named alternative.

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 useful context about acceptable recipient types and the potential x402 payment requirement, but it doesn't say when to choose this tool over connect_lookup or other siblings. There is no when-not-to-use guidance, leaving the choice between similarly named lookup tools ambiguous.

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 read-only, idempotent, non-destructive behavior, and the description adds value beyond them by disclosing the exact scope (the key owner) and that all linked accounts are returned. It doesn't contradict the annotations and contributes useful 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?

Two short sentences place the main action ('Get the Connect profile, scores, and all linked accounts') first, then give the intended use case. There is no filler or information that belongs only in annotations or schema.

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 available, the description still tells the agent what data will be returned ('profile, scores, and all linked accounts') and for whom. A more detailed shape of the response would be helpful, but the purpose and invocation scope are complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and has a schema coverage of 100%, so the baseline is 4 and there are no parameters for the description to explain. The description appropriately adds no redundant parameter details.

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 ('Get'), the resources ('Connect profile, scores, and all linked accounts'), and the scope ('for the API key owner'). This makes it easy to distinguish from siblings like connect_scores_by_account or connect_lookup, which are not scoped to the current key owner.

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 a concrete use case ('Use to identify which user the key belongs to'), which builds on the clear scope. It does not explicitly name alternatives or say when not to use the tool, so it stops short of full when/when-not 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail about the optional filter excluding users below minScore, but it does not disclose behavior for invalid users, missing scores, batch size limits, or the response shape.

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 one concise, front-loaded sentence. It states the primary purpose first and then provides the optional filter behavior with concrete score ranges. No filler or redundant restatement of the schema is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a nested users array and no output schema, so the description should clarify how to specify linked accounts versus usernames and what the caller can expect in return. It covers the filter well, but the user-identification ambiguity and lack of any response/error context leave meaningful 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?

Schema description coverage is 50%, so the description partially compensates by adding the minScore ranges and clarifying that the filter excludes low-scoring users. However, it does not explain the users parameter semantics—specifically how to distinguish linked accounts by id versus Connect usernames via the type and username fields—which is important given the nested schema.

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 uses a specific verb ('Batch scores') and identifies the resource ('linked accounts or Connect usernames'), making the core purpose clear. It does not explicitly contrast with the sibling tools connect_scores_by_account and connect_scores_by_username, but the word 'batch' plus the combined scope helps differentiate it.

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 explicit when-to-use or when-not-to-use guidance is provided. The word 'Batch' implies use for multiple users, but the description never mentions alternatives like connect_scores_by_account or connect_scores_by_username or states when a single lookup would be more 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?

Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds almost nothing beyond restating the resource scope ('linked account or wallet'). No disclosure about return shape, lookup failure behavior, or account-linking requirements is provided, so the behavioral burden falls unfilled on the description.

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 brief sentence with zero redundant words. It is front-loaded with the core noun phrase. However, its brevity is not false economy; it is genuinely under-specified in other dimensions.

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?

Despite being a simple 2-parameter tool with strong safety annotations, the description is too terse. It fails to explain what 'scores' are, the output/return, or how this differs from the sibling score tools. An agent would need to inspect types or examples to use it effectively.

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 0%, so the description is the only source of parameter meaning beyond the raw schema. It only roughly maps to 'platform' via 'social account or wallet' and gives no meaning for 'identifier'. It does not compensate for the missing schema descriptions.

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 is a noun phrase, not an action statement. It says 'Scores for a linked social account or wallet,' which implies a retrieval but lacks an explicit verb. It names the resource (linked account/wallet) but gives no basis for distinguishing from sibling `connect_scores_by_username` 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?

No guidance is given about when to use this tool vs. alternatives like `connect_scores_by_username` or `connect_scores_batch`. The description does not mention constraints, prerequisites (e.g., whether the account must already be linked), or scenarios where this tool is preferred.

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

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

The description adds no behavioral context beyond what the annotations already declare (readOnly, openWorld, idempotent, not destructive). It does not mention potential errors, rate limits, authentication requirements, or whether the lookup is exact or partial. With annotations present, the bar is lower, but the description still contributes nothing.

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 extremely concise, consisting of a short phrase with no fluff. It is front-loaded with the key information. However, it is a noun phrase rather than a complete sentence, which could be structurally improved by adding an explicit verb.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, no output schema), the description is not complete enough. It does not describe the return format or what 'scores' means, nor does it differentiate from connect_scores_by_account or connect_scores_batch. An agent might wonder if this returns a single score or a list, and whether it requires authentication.

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 0%, so the description must compensate. It adds the qualifier 'public' to 'username,' clarifying that the parameter refers to a Connect public username. However, it does not specify format, case sensitivity, or any constraints beyond what the schema's minLength:1 provides. For a single parameter, this is adequate but not thorough.

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 clear resource ('Scores') and identifier ('Connect public username'), which aligns with the tool name. It does not explicitly use a verb like 'get' or 'retrieve,' but the intent is unambiguous. It does not contrast with siblings like connect_scores_by_account or connect_scores_batch, but the 'public username' qualifier provides some distinction.

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 provides no guidance on when to use this tool versus alternatives. It does not mention connect_scores_by_account or connect_scores_batch, nor does it explain scenarios where a public username is appropriate versus other identifiers. An agent is left to infer usage from the name alone.

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