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

With no annotations provided, the description carries the full burden. It discloses the authentication requirement (agent key floe_...), the conditional enforcement behavior (only after set_allowlist_mode), and the nature of the entry (allowed-AND-capped). This is sufficient for a straightforward add operation, though it does not mention side effects like overwriting or duplicate handling.

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 three sentences with zero filler. Each sentence carries essential information: purpose, kind usage, enforcement condition, and auth requirement. It is well-structured and front-loaded with the primary action.

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 creation tool with no output schema and moderate complexity, the description covers purpose, parameter semantics, prerequisite mode, and auth. It omits the optional match_kind parameter, but the schema fully documents it, so the description remains largely complete 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 coverage is 100% and the schema already documents each parameter. The description adds value by connecting kind to match_key semantics (host vs recipient wallet) and clarifying that limit_raw is in raw USDC with 6 decimals, reinforcing the cap concept. It does not mention optional match_kind, but the schema covers that.

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 starts with a specific verb ('Add') and resource ('merchant-allowlist entry'), and clarifies it as an 'allowed-AND-capped' policy row. It explicitly differentiates the two kinds (api vs vendor), distinguishing it from sibling tools like remove_allowlist_entry or set_allowlist_mode.

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 clearly explains when to use kind='api' (hostname) vs kind='vendor' (payee wallet) and notes that enforcement only occurs after set_allowlist_mode is set, implying the need to use that tool in conjunction. However, it stops short of explicitly naming alternative tools or stating when not to use this one.

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

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

With no annotations, the description discloses a key behavioral trait: it builds an unsigned tx, meaning no on-chain effect occurs. It also mentions authentication requirements. However, it does not describe the return format, error behavior, or that the unsigned tx would need to be signed and broadcast separately.

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, well-structured sentence that front-loads the core purpose and includes the key authentication requirement. It is concise with no redundant phrases.

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 no output schema and no annotations, so the description should explain the return value and next steps. It does not mention what the tool returns (e.g., the unsigned transaction) or how to use it with broadcast_transaction. The role of optional market_id is also unclear, leaving gaps for an agent selecting and invoking the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds minimal extra meaning beyond the context of adding collateral to a loan. It does not clarify the optional market_id usage or provide additional parameter-level 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 uses a specific verb 'Build' and specifies the resource 'unsigned tx to add collateral to a loan', clearly distinguishing it from sibling tools like withdraw_collateral or broadcast_transaction. The intent is unambiguous.

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

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

The description states a clear prerequisite (requires any Floe API key) and notes that it builds an unsigned transaction, implying it is not for broadcasting. However, it does not explicitly mention alternative tools or when to use this over others, and there are 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?

With no annotations, the description carries the burden. It discloses that the tool builds an *unsigned* transaction, indicating it does not broadcast or mutate state, and specifies API key requirements. However, it does not detail what the returned unsigned tx looks like or any further steps needed, but the key point of non-broadcasting is clear.

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 concise sentences, front-loaded with the primary purpose and a single prerequisite. No filler or redundant information.

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

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

For a simple 2-parameter tool with no output schema, the description provides essential context: the action (approve a token), the form (unsigned tx), and the auth requirement. It does not explain return value format or next steps, but 'unsigned tx' implies the output type sufficiently for an agent. Slightly incomplete only because it omits what the agent should do with the unsigned tx (e.g., sign and broadcast).

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% for both parameters (token_address and amount), so the schema already provides full parameter semantics. The description adds no additional parameter-specific details beyond the 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?

Description clearly states the tool's function: 'Build unsigned tx to approve a token for Floe protocol.' Uses a specific verb ('Build') and resource ('unsigned tx to approve a token'), which distinguishes it from sibling tools like broadcast_transaction or create_lend_intent.

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?

Description mentions a prerequisite: 'Requires any Floe API key (agent floe_... or developer floe_live_...)' but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or references to related workflows. The usage context is only implied by the tool's purpose.

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?

No annotations are provided, so the description carries the full burden. It mentions the auth requirement but omits critical behavioral traits such as irreversibility, potential gas costs, or that a transaction hash is returned.

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 concise sentences. The first front-loads the core action, the second adds the necessary auth context. No wasted words.

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 covers the essential action, network, and auth. However, with no output schema, it does not mention the return value (expected tx hash) or any caveats about finality. It is minimally adequate for a simple broadcast 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% for the single parameter, fully describing 'signed_transaction_hex' as 'Signed tx as 0x RLP hex'. The description adds no additional param information, but the schema is sufficient.

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 the action ('Submit') and the resource ('a signed transaction to Base Mainnet'). This distinguishes it from sibling tools like simulate_transaction and get_transaction_status.

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

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

It specifies the authentication prerequisite ('Requires any Floe API key') and the target network. However, it gives no explicit guidance on when to use this vs alternatives (e.g., simulate first) or when not to use it.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions the API key requirement, which is useful, but does not explicitly state whether this is a read-only calculation, how results are returned, or that no state is modified. This leaves the agent with incomplete safety and side-effect knowledge.

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 that immediately states the tool's purpose and follows with the auth requirement. Every word contributes value; there is no redundancy or 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?

The tool has no output schema and no annotations, so the description must explain what the tool returns and how it fits into a workflow. It only says 'risk metrics' without specifying what those metrics are, their format, or how the result should be interpreted. This is a notable gap for an agent to use the tool 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?

The input schema already describes all parameters (borrow_amount, collateral_amount, interest_rate_percent, duration_days, liquidation_ltv_percent) with 100% coverage, so the description adds no parameter-specific meaning. The baseline score of 3 applies because the schema does the heavy lifting.

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 a specific verb ('calculate') and resource ('risk metrics') for a well-defined context ('a potential loan position'). This differentiates it from sibling tools like estimate_interest or get_loan_health, which focus on different aspects.

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 phrase 'for a potential loan position' gives implied context that this is used when evaluating a loan, but there is no explicit guidance on when to choose this tool over alternatives such as get_loan_health or estimate_interest. No exclusionary or alternative-tool guidance is provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only mentions the API key requirement and the action itself, but does not disclose whether the operation is read-only, what the return value looks like, or any side effects. This is minimal for a check-type tool.

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 two concise sentences, front-loaded with the core purpose and followed by the necessary auth requirement. There is no wasted text or repetition of schema details.

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 is adequate for a simple tool with clear purpose and fully documented parameters, but it lacks important context such as the expected result (e.g., boolean) or any limitations on what 'match' means. Considering there is no output schema, the description could be more complete, though the complexity is low.

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 schema already provides 100% coverage for both parameters ('Lend intent hash' and 'Borrow intent hash'). The description adds no additional parameter semantics, so it meets the baseline but does not exceed it.

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 ('Check') and resource ('two intents') to state exactly what the tool does. It is immediately clear and distinct from sibling tools like get_open_lend_intents or create_counter_intent, which have different purposes.

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 use case (checking if two intents are compatible) but does not explicitly say when to use it versus alternatives, nor does it mention any exclusions or prerequisites beyond the API key. It provides basic context but no comparative 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?

With no annotations provided, the description carries the full burden. It discloses that no credential is required, that it is a public probe with IP rate-limiting, and explains the exact return shape for both plain and x402-protected URLs. This is comprehensive behavioral transparency for a read-only probe.

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 three concise sentences, each earning its place: the first states the core function, the second describes behavior and return format, and the third gives a specific use case. It is front-loaded and free of unnecessary detail.

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 single-parameter tool with no output schema, the description is complete. It covers the return shape, authentication requirements, rate limiting, and a concrete usage scenario, making it fully self-contained for an agent to select and invoke correctly.

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

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

Schema coverage is 100% for the single 'url' parameter, which has a clear description 'Target URL to probe.' The tool description does not add parameter-specific meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool checks whether a URL is x402-protected and what it costs, using the specific verb 'Check' and resource 'URL'. It distinguishes itself from sibling tools like x402_pay by emphasizing it's a public probe without credentials, making its purpose unique and unambiguous.

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

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

The description explicitly provides a use case: 'Use to vet a vendor before minting keys or funding.' It implies when to use (when you need to assess a URL without credentials) but does not explicitly name alternatives or when-not-to-use, so it falls slightly short of full 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?

With no annotations provided, the description carries the full burden of disclosing effects. It clearly states the action, the post-condition (only bounded by creditLimit), and the authentication requirement (agent key). This exceeds a bare 'clears the spend limit' and provides meaningful behavioral context, though it could go further (e.g., reversibility).

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 two short sentences, front-loading the core action ('Remove the agent's session spend cap.') and adding essential context ('Requires an agent key') without any filler. Every word 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?

For a parameterless tool with no output schema and in the context of a balanced set of sibling tools, this description is complete. It covers the action, the impact on future behavior, and the necessary authority, leaving no obvious gaps for an agent to miss.

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 has zero parameters, making schema coverage trivially 100%. No parameter documentation is needed, so the baseline of 4 applies. The description correctly focuses on the action and its effects instead of parameters.

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

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

The description states a specific verb ('Remove') a specific resource ('the agent's session spend cap') and clarifies the resulting boundary ('Subsequent paid calls will only be bounded by the on-chain creditLimit'). This clearly distinguishes it from sibling tools like set_spend_limit and get_spend_limit.

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 use case: when you want to lift the session cap but still be bound by the on-chain credit limit. It also provides a prerequisite ('Requires an agent key'), which is useful guidance. However, it does not explicitly mention when not to use this tool or name alternative tools, so it misses 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?

Given the absence of annotations, the description carries full burden and informs significantly: it details financial effects (repaying facility loans, sweeping unspent funds), resource disposition (disabling keys), irreversibility, and authentication needs. This is rich behavioral context, though it omits potential edge cases or error conditions.

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 exceptionally concise and front-loaded, opening with the core action, then listing specific effects and warnings in a compact format. Every sentence contributes value without redundancy, and the parenthetical about welcome credit adds precision without bloat.

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 single-parameter destructive tool with no output schema, the description covers the essential operational aspects: irreversible action, financial outcomes, key handling, and authentication. It doesn't mention the response format or whether the agent is hard-deleted vs. deactivated, but these are secondary to the primary behavioral effects.

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 sole parameter agent_id is fully described in the schema as 'Numeric agent id', so schema coverage is 100%. The description adds no additional parameter-level detail, but none is needed for a simple identifier, so the baseline score of 3 applies.

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

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

The description clearly states the specific action: 'Permanently close an agent' and enumerates the consequences (repays loans, sweeps funds, disables keys). This distinguishes it from sibling tools like pause_agent and resume_agent, which are temporary, and the explicit 'Irreversible' further clarifies its purpose.

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 when to use it through 'Permanently' and 'Irreversible', but doesn't explicitly contrast with alternatives or state when not to use it. The developer key requirement is a useful prerequisite, but there's no direct comparison with pause_agent or other lifecycle tools.

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

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

With no annotations, the description discloses key side effects: funded wallet, sponsored delegation, $3 welcome credit (first agent only, once per account), and the no-credit-line default. This goes well beyond a simple 'create' and explains the full 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?

The description is information-dense and front-loaded, but the long arrow-chain and embedded clarifications make it a bit dense. Still, every sentence adds value and no filler 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?

For a complex create operation with no output schema, the description covers return values, auth requirements, funding default, and the one-time credit edge case. It is complete enough for an agent to set expectations and avoid mistakes.

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 parameter semantics are already documented. The description adds context for borrow_limit_raw via the pay-as-you-go note but doesn't elaborate on max_rate_bps or expiry_seconds beyond the 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 opens with 'Provision a new managed agent end-to-end' and details the exact sequence (agent row, wallet, delegation, credit). It explicitly distinguishes itself from create_agent_key by noting it returns agentId/walletAddress/delegationTxHash, NOT an API key.

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 provides clear context: defaults to pay-as-you-go and directs 'upgrade later with open_credit_line', while also stating 'mint one with create_agent_key' for API keys. It also notes the developer key prerequisite, making when-to-use vs alternatives explicit.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly warns that the plaintext key is returned only once, instructs to store it securely and not echo into chat, and explains the budget option is fail-closed. These are critical security traits not discoverable from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core action, and contains only high-value information. No fluff or repetition; 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 the tool's sensitivity (creating a credential), the description covers essential aspects: the key prefix, one-time retrieval, security handling, optional budget, and developer-key requirement. No output schema exists, but the description mentions the main output (the plaintext key) and its security implications, making it sufficiently complete 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?

The schema already has 100% parameter coverage with descriptions for all four fields. The description adds value by explaining that the budget is a 'rolling spend budget (fail-closed)', which clarifies the operational consequence of combining budget_raw and window_seconds beyond what the schema states.

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 the tool 'Mint a new agent API key (floe_...)' for an agent, identifying the resource and action. It also differentiates from siblings like rotate_agent_key and revoke_agent_key by focusing on creating a new credential for runtime tools and x402_pay.

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 clear context: this is for creating a new key and requires a developer key (floe_live_...). It does not explicitly mention alternatives or when-not-to-use, but the purpose is unambiguous enough that an agent can infer when to choose it over sibling key-management tools.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does reveal that the tool 'build[s] unsigned tx' (indicating no direct on-chain execution) and requires an API key, but it does not explain side effects, whether the intent is persisted, or what exactly the returned unsigned transaction represents. The mention of a solver matching suggests off-chain behavior but remains vague.

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 concise, front-loaded sentences with no filler. The key action ('Build unsigned tx') is first, followed by the purpose and a clear requirement. Every word 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 the tool has 8 parameters, no output schema, and no annotations, the description is too sparse. It explains what the output is (an unsigned tx) but omits crucial context: how the tx should be used, whether it needs to be signed and broadcast separately, and what 'solver matches it with lenders' implies for the lifecycle. The description is insufficient for an agent to fully understand the tool's role without additional probing.

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 covers all 8 parameters with descriptions, so the baseline is 3. The tool description adds no parameter-level information beyond what the schema already provides. The schema itself offers rich context for market_id and min_ltv_bps, so the description does not need to compensate.

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 verb ('Build') and resource ('borrow request'), and adds that a solver matches it with lenders, which clarifies its role among other intent tools. However, it does not explicitly distinguish it from siblings like create_lend_intent or create_counter_intent, so it falls short of a 5.

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 mentions a prerequisite (API key) but gives no context about scenarios suited for creating a borrow intent, nor does it reference sibling tools like create_lend_intent or create_counter_intent.

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

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

With no annotations, the description carries the full burden. It discloses the auth requirement ('Requires any Floe API key') and the auto-matching behavior, which adds value. However, it does not describe side effects (e.g., whether the original offer becomes inactive) or what happens after creation, leaving some behavioral ambiguity typical of a mutation tool.

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 succinct with four short sentences, each earning its place: action, use case, automation behavior, and auth requirement. It is front-loaded with the primary purpose, making it easy to scan.

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 (2 required params, no output schema), the description covers purpose, use case, behavior, and auth. It omits minor context like whether the counter-intent can be revoked or how the original offer is affected, but these are not critical for using the tool correctly.

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

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

Schema description coverage is 100%, and both parameters are adequately described ('Source intent offer hash' and 'Your wallet address'). The description does not add further parameter-specific details beyond what the schema already provides, so it does not elevate 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 states a specific verb ('Create a counter-intent') and identifies the target resource ('against an existing offer'). It further distinguishes this tool from siblings by calling it the 'Primary way to accept offers,' making its role clear relative to other intent tools.

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

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

It provides clear context on when to use the tool: to accept an existing offer. The phrase 'Primary way' implies it is the go-to method, though it does not explicitly list alternatives or exclusions. The mention of 'Solver auto-matches' hints at the intended workflow but lacks explicit comparison to other create/revoke tools.

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

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

With no annotations, the description carries the transparency burden. It discloses key behaviors: builds an unsigned transaction (not broadcasting), requires an API key, and relies on a solver for matching. This adds meaningful context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with the primary action front-loaded. Every word earns its place; no fluff or repetition.

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 7-parameter tool with no output schema, the description covers purpose, authentication, and the matching workflow. It doesn't explicitly describe the response or next steps (like broadcasting), but the sibling list includes broadcast_transaction, and the 'unsigned tx' wording implies the follow-up. Overall adequate.

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 has 100% description coverage with detailed parameter explanations (e.g., max_ltv_bps limits). The tool description itself adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description explicitly states 'Build unsigned tx to create a lending offer' with a specific verb ('Build') and resource ('unsigned tx for lending offer'), clearly distinguishing it from sibling tools like create_borrow_intent and create_counter_intent.

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?

Provides useful context: this is for creating a lending offer, a solver matches it with borrowers, and it requires any Floe API key. While it doesn't explicitly name alternatives or exclusions, the workflow is clear enough for an agent to decide when to use it.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals critical behaviors: the signing secret is returned only once and must be stored, valid event names are listed, and there is a 10-webhook limit. This is substantial transparency for a mutation tool.

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: one sentence for purpose, one for the secret, one list for events, and one for constraints. Every sentence carries information, with no filler. It is well-structured and easy to parse.

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 having no output schema, the description provides essential context: what the tool does, the event catalog, the secret return behavior, and resource limits. It covers the key aspects needed to invoke the tool successfully, especially given the schema already documents parameters.

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 baseline is 3. The description adds value by enumerating the valid event names for the 'events' parameter and clarifying the 'url' must be an HTTPS endpoint (though schema already says HTTPS). It also mentions the scope caveat via register_credit_threshold, further enriching parameter meaning.

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 opens with 'Register a webhook endpoint for account events,' which is a specific verb+resource pair that clearly states the tool's function. It also distinguishes itself from siblings like list_webhooks and test_webhook by mentioning the event catalog and the alternative register_credit_threshold for credit-specific events.

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 explicitly provides usage context: when to use the tool (for account events), alternatives (register_credit_threshold for credit events), and constraints (max 10 webhooks, requires a developer key). This gives clear guidance on selection and prerequisites.

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?

No annotations are provided, so the description must disclose behavioral traits. It mentions the agent key requirement, which is useful. However, it does not state whether deletion is permanent, idempotent, or what happens on error, leaving some gaps.

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, well-structured sentence that leads with the action and includes key details (source of id, auth requirement) in minimal words. Every part is meaningful.

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

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

For a simple delete tool with one parameter and no output schema, the description covers the essential information: what it does, how to get the id, and the auth context. It could mention return behavior or error handling, but this is not critical for such a straightforward 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?

The schema already provides a description for the 'id' parameter, covering its type and meaning. The description adds value by clarifying that the id comes from list_credit_thresholds and that an agent key is required, going beyond the 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 clearly states the action ('Delete'), the resource ('credit-utilization thresholds'), and the scope ('by id'), while referencing the source for the id (list_credit_thresholds). This distinguishes it from sibling tools like register_credit_threshold and list_credit_thresholds.

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 indicates how to use the tool: obtain the id from list_credit_thresholds first, and notes the required agent key. It provides clear context for use, though it does not explicitly discuss when not to use it or name alternatives.

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

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

With no annotations provided, the description carries the full burden and does so well. It explicitly discloses non-mutating behavior ('WITHOUT making the call or touching balance'), the return structure, and authentication requirements. This gives the agent a clear safety profile and expectations.

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 dense yet efficient: the first sentence states the core purpose, followed by return format, parameter selection rules, usage timing, and authentication. Every sentence serves a distinct purpose with no fluff or redundancy.

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 there is no output schema, the description appropriately explains the return value fields. It also covers key contextual aspects: non-side-effect behavior, when to use, how to select parameters, and auth requirements. For a cost-estimation tool with 8 params, this is complete enough 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?

Although the input schema has 100% coverage, the description adds critical meaning beyond individual field descriptions: it maps parameter sets to model types and instructs 'Provide only the units the model bills', resolving which parameters are relevant for which use case. This is essential semantic info not present in the 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 clearly states a specific action ('Estimate the USDC cost of a Floe Inference call') with a specific resource (Floe Inference) and scope ('given model and usage vector'). It also distinguishes itself from sibling tools by emphasizing 'WITHOUT making the call or touching balance', making it unambiguous what this tool does and doesn't do.

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?

Provides explicit when-to-use guidance: 'Use BEFORE inference to decide gating.' It also gives parameter-selection guidance per model type (text/TTS/STT/realtime voice) and prerequisite auth information ('Requires any Floe API key'). This is comprehensive for choosing this tool over alternatives.

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?

No annotations are provided, so the description must disclose behavioral traits. It only mentions the API key requirement but does not specify whether the operation is read-only, what the return value format is, or any side effects. The word 'estimate' implies a calculation, but the description lacks explicit statements about non-mutation or expected output, leaving significant behavioral gaps.

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 two sentences with no filler. It front-loads the purpose and then adds the authentication requirement. While very short, it could have included more critical usage or behavior details without becoming verbose, but as written it is appropriately sized for the content it conveys.

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 and no annotations, the description should explain what the tool returns and how it differs from similar tools like get_accrued_interest. It does neither. It lacks information about the response format, units of the interest estimate, and when to prefer this tool over others. This leaves an agent with insufficient context to fully utilize the tool correctly.

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

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

Schema description coverage is 100%, with each parameter (principal, duration_days, interest_rate_bps) having a clear description including units. The tool description adds no additional meaning beyond the schema, such as calculation specifics or relationship between parameters, so it does not enhance what the schema already provides.

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 the tool's function: 'Estimate total interest for given loan terms.' This specifies the verb (estimate), the resource (total interest), and the scope (given loan terms), distinguishing it from related tools like get_accrued_interest which deals with actual accrued interest on existing loans. No ambiguity in what the tool does.

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 usage for hypothetical loan term calculations by saying 'given loan terms,' but it does not explicitly state when to use this tool over alternatives (e.g., get_accrued_interest) or any exclusions. The only additional guidance is the API key requirement, which is more about authentication than usage 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?

With no annotations, the description takes on the full burden and does disclose key behaviors: it does not charge ('without paying'), it checks against credit and spend-limit, and it requires an agent key. It omits possible error behavior or exact side effects, but the non-payment and auth details are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all informative and front-loaded: the first states action and result, the second adds policy context, the third gives sequencing and a prerequisite. No filler.

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

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

For a no-output-schema preflight tool, the description explains the return value (USDC cost), the non-payment behavior, the timing, and the auth requirement. It lacks explicit error/edge-case detail, but the essential context for invoking the tool is 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?

Schema description coverage is 100%, and the description does not add parameter detail beyond the schema; url and method are already documented. Baseline 3 is appropriate because the schema carries the parameter semantics.

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

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

The description uses a specific verb 'Preflight' and clearly identifies the resource (x402-protected URL) with the outcome (return USDC cost without paying). It distinguishes itself from x402_pay by explicitly stating 'without paying' and 'Use BEFORE x402_pay'.

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 clear contextual guidance: use before x402_pay to decide gating in one round-trip, and it requires an agent key. It does not name alternative tools or negative cases, 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?

With no annotations provided, the description carries the burden. It discloses the API key requirement, which is useful. However, it does not elaborate on what 'full credit status' entails or confirm whether this is a read-only operation, though 'Get' implies it.

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, efficiently structured sentence that leads with the purpose and follows with the authentication requirement. No redundant information.

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

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

The tool is simple (one parameter, no output schema), and the description covers the purpose and auth requirement. However, 'full credit status' is somewhat ambiguous and could be clarified, especially given the existence of sibling tools like get_loan_health.

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% for the loan_id parameter ('Numeric loan ID'), so the description adds minimal meaning beyond the schema, only framing it in context of a loan. 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 states the verb 'Get' and the specific resource 'accrued interest and full credit status for a loan', which distinguishes it from sibling tools like estimate_interest (projection) and get_loan (general loan details).

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 when to use the tool (to retrieve accrued interest and credit status for a loan) and provides authentication context, but it does not explicitly state when to choose this over alternatives or mention any 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?

With no annotations, the description carries the burden. It discloses ordering ('newest first'), pagination behavior ('paginate with the returned cursor'), and authentication ('Requires a developer key'). These are useful behavioral traits beyond the schema. It lacks rate limits or error behavior, but still provides substantial 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?

Two sentences, front-loaded with purpose, then filters, then auth. Every clause delivers value; no filler or redundancy.

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 no output schema, the description covers feed scope, ordering, filtering, pagination, and authentication—enough to select and invoke the tool correctly. It omits the response shape, but 'feed' and the listed event types give a reasonable mental model. The complexity is moderate (6 optional params), and the description addresses all major usage aspects.

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 baseline is 3. The description adds a high-level summary of filters ('Filter by agent, type, or time range') but no new parameter-level detail beyond what the schema already explains for type, limit, since, until, cursor, and agent_id. The cursor description is already in the 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 begins with 'Unified account activity feed' and enumerates the event categories (x402 proxy calls, onramps, transfers, loan events), clearly distinguishing it from siblings like get_balances and get_usage_summary. It states the resource and scope with a specific verb implied by 'get_activity'.

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 explains filtering by agent, type, or time range and explicitly mentions pagination via the returned cursor. It also notes the developer key requirement. It does not contrast with alternatives explicitly, but the feed description implies use for listing activity events, and no sibling offers this unified view.

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?

No annotations are provided, so the description carries the burden. It discloses the developer key requirement and lists the specific fields returned, giving the agent a good sense of behavior. It does not explicitly state read-only nature or error conditions, but 'Get' and the shown fields imply a safe read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, and zero wasted words. The list of fields is compact and informative.

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 single-parameter getter with no output schema, the description adequately covers the returned fields and auth requirement. It lacks explicit read-only confirmation or error cases, but the tool is simple enough that this is not a major 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 coverage is 100% and the agent_id parameter is already described in the schema (numeric ID from create_agent/list_agents). The description adds no additional parameter semantics beyond what the schema provides.

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?

Description states 'Get one agent's full detail' with a specific list of returned fields (status, privyWalletAddress, creditUsed, etc.), clearly identifying the verb, resource, and scope. It distinguishes itself from list_agents by focusing on a single agent's detailed data.

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 context is clear: use this when you need a single agent's detailed snapshot. It does not explicitly mention alternatives or when not to use it, but the purpose is specific enough to guide selection among many sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the 404 response until the first score is computed, the auth requirement (agent key), the meaning of the confidence field, and the scoring basis (behavioral discipline plus repayment history). This goes well beyond a bare 'get' description. The only minor omission is an explicit statement that the operation is read-only, but the 'get' verb and the nature of the tool make that clear.

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 information-dense but every sentence earns its place: purpose, output fields, scoring logic, use case, error condition, and auth requirement. It is well-structured, starting with the core return value, then elaborating on fields, then providing context. There is zero fluff.

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?

Since there is no output schema, the description must define the return value, and it does so thoroughly: all six fields are listed, the multiplier semantics are explained with a concrete example (10000 = 1.0x), the 404 edge case is noted, and the auth requirement is stated. For a no-parameter getter with no output schema, this is as complete as one could reasonably expect.

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 has zero parameters, so the baseline is 4. The description adds contextual meaning by explaining that the tool acts on the calling agent's identity, which is the implicit parameter derived from the API key. There are no parameter semantics to explain, and the description properly acknowledges the auth key requirement.

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 ('Return') and clearly identifies the resource ('the calling agent's unified credit reputation'). It lists the exact output fields (score, band, confidence, collateralMultiplierBps, modelVersion, computedAt), which fully disambiguates it from sibling getters like get_credit_remaining or get_loan_state. This is a model of purpose 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?

The description explicitly states the intended use case: 'Use to understand how much collateral the next borrow will require.' This gives a clear invocation context. However, it does not mention alternatives or when not to use the tool, which would be needed for a 5. Still, the guidance is helpful and actionable.

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

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

With no annotations, the description carries full responsibility. It discloses the authentication need (floe_... key) and enumerates possible return values, which gives good behavioral clarity for a zero-parameter read operation. It does not describe error behavior or side effects, but for a read-only getter the key disclosure is valuable.

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, well-structured sentence that front-loads the core purpose and then provides the return enum and auth requirement. No wasted words.

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

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

For a simple, parameterless getter, the description fully specifies what it returns and the required credential. No output schema or further context is necessary, and the sibling tools provide the broader context for related allowlist operations.

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

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

There are zero parameters, so the baseline is 4. The description adds no parameter-specific details because none exist; the empty schema already tells the agent no arguments are needed.

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?

Description uses a specific verb ('Return') and names the exact resource (current merchant-allowlist enforcement mode) with the range of possible values ('off | host | vendor | both'). It clearly distinguishes itself from the sibling set_allowlist_mode by focusing on reading the current state.

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 phrase 'current' and the enumeration of modes make it clear this is for reading the enforcement state, contrasted with sibling tools like set_allowlist_mode. It also states the authentication requirement (agent key). It does not explicitly mention when to avoid using it, but the context is sufficient for a simple getter.

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?

No annotations are present, so the description must carry the burden. It discloses the authentication requirement ('Requires a developer key (floe_live_...)') and the exact scope of balances included. While it doesn't explicitly state read-only, the verb 'get' and 'aggregate' imply a non-mutating operation. This adds useful behavioral context beyond an empty schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first front-loads the purpose with a clear verb and scope; the second adds the essential auth requirement. No filler words or redundant explanations.

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 no params, no annotations, and no output schema, so the description must cover function and invocation requirements. It does both, though it stops short of describing the exact response structure (e.g., whether it returns a single total or per-wallet breakdown). Given the simplicity, this is reasonably complete; a small improvement would be specifying the return format.

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 has no properties, so there are zero parameters to document. Per the rubric, 0 params yields a baseline of 4; the description correctly mentions no arguments are needed aside from implicit auth, so no additional parameter semantics are required.

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 function: 'Aggregate USDC balances across the developer account' with specific scope (developer wallet, every agent wallet, API credits). This distinguishes it from sibling get_wallet_balance (single wallet) and get_credit_remaining (credits only), satisfying the specific-verb+resource criterion.

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 a use case: when a complete picture of all USDC balances is wanted. It states a prerequisite (developer key) but does not explicitly contrast with alternatives like get_wallet_balance or get_credit_remaining. However, the 'aggregate' wording and listing of all sources provide clear context, warranting a 4.

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?

No annotations are provided, so the description carries the full burden. It discloses an authorization requirement ('Requires a developer key (floe_live_...)') and implies read-only behavior via 'Preview.' It also states what data is returned (bounds and funded balances). It doesn't describe errors or return format, but for a simple read-only preview this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler. The first sentence front-loads the action and resource; the second provides usage order and auth requirement. 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?

With one simple parameter, no output schema, and a read-only preview purpose, the description covers the core aspects: what it does, when to use it, and what auth is needed. It doesn't explain the structure of the returned bounds, but the tool name and description are clear enough for an agent to invoke it correctly. A perfect 5 would require a bit more detail on output interpretation.

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% because agent_id has a clear description ('Numeric agent id.') in the schema. The tool description adds no extra parameter-level detail, so the baseline of 3 applies per the rubric—schema already does the heavy lifting.

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 ('Preview') and identifies the exact resource ('valid deposit / LTV bounds and current funded balances') and the target action ('upgrading an agent to a credit line'). It clearly distinguishes this from siblings like open_credit_line (which opens) and get_credit_remaining (which checks remaining balance).

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 states when to use the tool: 'Use BEFORE open_credit_line.' This names the direct alternative (open_credit_line) and provides a clear temporal context. While it doesn't list exclusions, the directive is sufficient and unambiguous for a pre-flight check tool.

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

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

With no annotations, the description fully covers behavioral nuances: the distinction between `available` and `headroomToAutoBorrow`, the condition where headroom can be positive while available is zero, and the proxy gating behavior. This is exceptionally transparent.

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 concise yet thorough, with each sentence contributing essential information: purpose, usage timing, field semantics, and authentication requirements. It is well-structured and front-loaded with the primary purpose.

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 has no parameters and no output schema, the description covers all necessary context: what it returns, the meaning of each field, how to use it, and the required agent key. It is fully self-contained for an agent to select and invoke correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaningful context about the return values and their interpretation, which compensates for the lack of an output 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 clearly states 'Return how much USDC credit the calling agent has left' with a specific verb and resource. It distinguishes between two important numbers and explicitly differentiates this from general balance queries, making its purpose 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?

It provides explicit 'Use BEFORE deciding whether to make a paid call' guidance and clarifies which field to use for the spend gate. However, it does not explicitly name alternative tools or state when not to use it, so it stops 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the auth requirement (developer key starting with floe_live_) and describes the output as machine-readable with key fields. It does not mention side effects, but as a read-only getter this is sufficient for an agent to understand what the tool does and what to expect.

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 two sentences, front-loaded with the core purpose and key output details, then the usage trigger and auth requirement. Every sentence adds value with no redundancy or filler.

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

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

For a tool with one parameter, no output schema, and no annotations, the description provides the essential information: what it returns (address, chain, minimums/warnings), when to use it (welcome credit exhausted), and a critical prerequisite (developer key). This is complete enough for an agent to invoke correctly.

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

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

The schema covers 100% of the single parameter (agent_id) with a type, pattern, and description. The tool description adds no additional parameter-specific meaning beyond the schema, so the baseline score of 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 opens with a clear verb ('Return') and resource ('machine-readable funding instructions'), then specifies the exact contents (USDC deposit address, chain Base/8453, minimums/warnings). This precisely distinguishes it from sibling tools, which focus on lending, borrowing, credit, and transactions.

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 explicitly states when to use the tool: 'Hand this to the human when welcome credit runs out — funding is the one step an agent cannot do alone.' This provides strong usage context and the reason why it exists. It does not mention alternatives or exclusions, but the context is unambiguous.

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?

No annotations are provided, so the description carries the burden. It discloses an important behavioral requirement: 'Requires any Floe API key (agent floe_... or developer floe_live_...).' However, it does not mention whether the operation is read-only (though implied by 'get'), error behavior, or response format, leaving some gaps for a simple get tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose. The second sentence adds necessary authentication context without redundancy. Every word earns its place, and the structure is logical: what + how + prerequisite.

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 single parameter and no output schema, so the description covers the essential context: how to invoke it (with offer hash) and the API key requirement. It does not explain what 'full details' includes or error scenarios, but for a simple lookup tool, it is sufficiently complete for an agent to select and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description's phrase 'by its offer hash' aligns with the schema's parameter description but adds no additional format, constraints, or usage semantics beyond what the schema already provides for offer_hash.

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 the tool's function: 'Get full details of a specific intent by its offer hash.' The verb 'get' plus the resource 'intent details' and the identifier mechanism ('offer hash') precisely distinguish it from sibling list tools like get_open_lend_intents, making the purpose unambiguous.

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

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

The description provides clear context: use when you need details for a specific intent identified by its offer hash. It implies differentiation from listing tools, though it does not explicitly name alternatives or state when not to use it. This meets the 'clear context' bar but falls short of explicit 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?

No annotations are provided, so the description carries the burden. It discloses the authentication requirement (any Floe API key), which is a useful behavioral detail. However, it does not mention whether the operation is read-only, error conditions, or return format. For a simple getter, the auth disclosure is a positive but not exhaustive.

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 two sentences, front-loaded with the purpose, and includes the essential auth note. Every word earns its place; no unnecessary detail.

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 single-parameter getter with no output schema or annotations, the description is largely complete: it explains what the tool does, the parameter, and a key requirement. It could potentially mention the shape of the returned details, but the name 'get_loan' and the word 'details' reasonably imply a full loan object. The description is adequate without being exhaustive.

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 parameter is already documented as a numeric loan ID. The description reiterates this ('numeric ID') but adds no new semantic meaning beyond the schema. 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 states it retrieves details of a specific loan using its numeric ID. This distinguishes it from sibling tools like get_user_loans (which lists loans) and get_loan_health/get_loan_state (which focus on specific aspects). The verb 'Get' and resource 'loan' are 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?

The description implies usage context: when you need a single loan's details by ID. It does not explicitly mention alternatives or exclusions (e.g., 'for listing use get_user_loans'), but the specificity of 'by its numeric ID' provides clear guidance for when this tool is appropriate.

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

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

No annotations exist, so the description carries the transparency burden. It discloses the API key requirement and the specific metrics checked, which implies a read-only operation, but it does not explicitly state that it has no side effects or describe error/edge-case 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 concise sentences; the first front-loads the tool's purpose and scope, the second covers authentication. No filler or redundancy.

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 read-only check tool with a single parameter and no output schema, the description adequately communicates the returned dimensions and the auth requirement. However, it could be more complete by explicitly stating the output format or common failure conditions, so it stops short of excellent.

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 only parameter, loan_id, is fully described in the schema as 'Numeric loan ID'. The description adds no additional parameter-level detail, so the schema coverage establishes the baseline of 3.

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 the tool checks loan health and enumerates specific dimensions (LTV, liquidation risk, accrued interest, early repayment terms). The verb+resource pairing is specific, though it does not explicitly differentiate from sibling tools like get_loan or get_accrued_interest.

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?

Provides only an authentication prerequisite ('Requires any Floe API key...') and no guidance on when to choose this tool over alternatives. No exclusions or alternative recommendations are given.

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

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

With no annotations, the description carries the full burden. It discloses the authentication requirement (agent key floe_...) and describes the output granularity as 'coarse' while enumerating the states. This adds meaningful context beyond the empty schema, though it could be more explicit about read-only semantics or error 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?

The description is two sentences, front-loaded with the core purpose, and every sentence earns its place: the first states what it returns, the second provides usage guidance and a prerequisite. No wasted words.

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 simple nature of the tool, the description covers the return values (the four states), a key use case, and a required credential. It could be more explicit about read-only behavior or error responses, but for a state-machine getter, this is largely sufficient.

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

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

There are zero parameters, so the baseline is 4. The description mentions an agent key as a requirement, but this is not a schema parameter and appears to be an authentication credential rather than a tool parameter, so it does not add parameter-level semantics 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 clearly states the tool returns the agent's coarse credit state-machine view and enumerates the four possible states (idle, borrowing, at_limit, repaying). This specific verb+resource combination distinguishes it from sibling tools like get_loan_health or get_credit_remaining.

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 explicit usage guidance: 'Use to gate actions that only make sense in specific states' with a concrete example ('don't spend while at_limit'). However, it does not explicitly mention alternatives or when not to use this tool, so it falls just short of the highest level.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that no API key is required and restricts results to 'active' markets, which are important behavioral traits. It does not mention return format or pagination, but the read-only nature is implied by 'List' and the simplicity of the tool.

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 exactly two short sentences, front-loaded with the primary action and outcome. There is no filler or redundancy, achieving maximum conciseness.

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 public list tool, the description is fairly complete: it states what is listed, the fields of interest (rates and liquidity), and the auth requirement. It lacks an explicit output schema or mention of pagination, but the simple scope makes it adequate for an agent to select and invoke correctly.

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

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

The tool has zero parameters, so the schema already covers everything. The description does not need to add parameter details and appropriately focuses on the tool's behavior, aligning with the baseline for zero-parameter tools.

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 'List' with a clear resource 'active lending markets' and additional detail 'with current rates and liquidity'. This distinguishes it from other get_* tools like get_token_price or get_loan_health, which focus on different data.

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 phrase 'No API key required' provides clear context on when this tool can be used, indicating it is a public access point. However, it does not explicitly contrast with alternative tools or state when not to use it, so it falls short of offering 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?

With no annotations provided, the description carries the transparency burden. It adds the authentication requirement ('Requires any Floe API key') and implies read-only behavior through 'browse', but does not explicitly state read-only status, response format, or pagination behavior. Moderate 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?

The description is composed of three short sentences: the primary purpose, a related usage hint, and the authentication requirement. It is front-loaded and concise, with no filler or redundant information.

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

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

For a simple paginated list tool with schema-covered parameters, the description covers the essential context: the resource, the auth prerequisite, and the connection to create_counter_intent. While it doesn't describe the response fields, the tool name and 'browse' make the return type inferable. No output schema exists, but the brevity is acceptable for this complexity.

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 already documents both parameters (skip and limit) with descriptions, achieving 100% schema coverage. The description adds no additional parameter semantics, so the baseline of 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 states the tool's function with a specific verb ('browse') and resource ('open borrow requests'), and distinguishes it from sibling tools such as get_open_lend_intents. The purpose is immediately understandable.

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 a clear use case: browsing open borrow requests, and explicitly points to create_counter_intent for lending, indicating a typical workflow. However, it does not explicitly contrast with get_open_lend_intents, but the context is sufficient for most agents.

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

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

With no annotations, the description carries the burden. It discloses the auth requirement and implies a read-only operation via 'browse,' but does not mention pagination, response format, or rate limits. Adds some context but lacks richer behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both valuable: the first conveys purpose, the second conveys auth requirement. No fluff, front-loaded and efficient.

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?

Although the tool is simple, the absence of an output schema means the description should explain what a successful response contains (e.g., list of offers with fields). It does not, and it omits any mention of default pagination or how to inspect individual intents via sibling tools.

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 skip and limit are fully documented. The description adds no extra parameter meaning, matching the baseline for high schema coverage.

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 ('browse') and resource ('open lend offers') with the purpose 'available for borrowing against.' It clearly distinguishes from siblings like get_open_borrow_intents and create_lend_intent by focusing on reading existing lend intents.

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?

States a clear prerequisite ('Requires any Floe API key') and implies usage context (to find lend offers to borrow against). Does not explicitly mention alternatives or exclusions, but the purpose is clear enough to guide tool selection.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It discloses the return shape ({ active: false } when no cap), and the authentication requirement (agent key floe_...). It does not explicitly state that this is a read-only operation with no side effects, but 'Return' implies it. This is solid transparency for a simple getter.

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 three short sentences, each earning its place: the first states the purpose, the second gives the absence return value, and the third provides the authentication prerequisite. It is front-loaded with the main purpose and contains no fluff or redundant details.

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 getter with no output schema and no annotations, the description is highly complete. It covers what it returns, the special case when no cap is set, and the required credential. The sibling tool context makes it clear that this is the read-only counterpart to set_spend_limit and clear_spend_limit, so the agent has enough information to use it correctly.

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

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

The input schema has zero parameters, so baseline is 4 per the rubric. The description adds the context that an agent key (floe_...) is required, which is an authentication requirement rather than a parameter. No parameter information is needed, and the description does not conflict with the empty 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 clearly states the tool's purpose: to return the agent's currently-active session spend cap. It specifies the verb ('Return') and the resource ('the agent's currently-active session spend cap'), and distinguishes from sibling tools like set_spend_limit and clear_spend_limit by being read-only. The mention of returning { active: false } when no cap is set adds specificity.

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 clear context for when to use the tool: whenever you need to check the current spend cap. It implies the read-only nature and states a prerequisite (requires an agent key). However, it does not explicitly mention alternatives or exclusions, such as pointing to set_spend_limit or clear_spend_limit for modifying the cap, which would earn 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does add the key detail that API key authentication is required, and implies a read-only, time-sensitive operation by saying 'current'. However, it does not mention potential side effects, rate limits, or what happens if the key is invalid, which would strengthen 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?

The description is concise and front-loaded: the first sentence states the core function, and the second sentence adds the essential prerequisite. Every word earns its place, with no redundancy or irrelevant detail.

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

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

For a simple tool with one optional parameter and no output schema, the description is nearly sufficient. It explains the API key requirement and the tool's general purpose, while the schema details the default market. It could optionally mention the return format (e.g., price representation) but that is reasonably implied for a price oracle tool.

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

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

The schema description covers the single parameter (market_id) with 100% coverage, including its type and default behavior. The tool description adds no additional parameter semantics beyond what the schema already provides, hence the baseline score of 3.

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 a specific verb ('Get') and resource ('current oracle price for collateral token'), distinguishing it from sibling tools, none of which directly fetch token prices. The purpose is unambiguous and self-contained.

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 mentions a prerequisite ('Requires any Floe API key') but does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage context is implied by the tool's name and purpose, but no direct comparison to other tools is given.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds the auth requirement (any Floe API key) and the verb 'Check' implies a read-only operation. However, it doesn't disclose what statuses are returned or behavior on invalid hashes, which would be useful.

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 concise sentences with no wasted words. The first states the core purpose, the second provides essential auth context. Both sentences earn their 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?

For a simple single-parameter tool without output schema, the description is adequately complete for invocation. It covers what the tool does and the auth prerequisite. It could mention the return statuses, but the tool name and simplicity make this a minor gap.

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

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

The input schema fully documents the single parameter (transaction_hash with pattern and description). The tool description adds no additional semantic detail beyond the schema, so baseline of 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 uses a specific verb 'Check status' and identifies the resource as 'a submitted transaction'. It clearly distinguishes itself from sibling tools like broadcast_transaction (which submits) and simulate_transaction (which simulates). The purpose is unambiguous.

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

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

The description clearly states a prerequisite: requires any Floe API key, which is important for usage. It implies use after a transaction is submitted, but does not explicitly exclude alternatives or mention when not to use. Still, the context is reasonably clear.

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?

No annotations are provided, so the description carries the transparency burden. It adds the authentication requirement and the rollup nature, but does not explicitly state whether it's a read-only operation, describe side effects, or detail response behavior beyond 'KPIs, daily series, and top endpoints.' This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose, and every clause adds value. The metaphor 'how is my fleet doing' is efficient and memorable, and the auth requirement is a useful inclusion.

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

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

For a simple analytics rollup with no output schema, the description conveys the main content (KPIs, series, endpoints) and the required auth context. It could mention the optional agent_id filtering more explicitly, but given the schema covers that, the description is reasonably 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 schema already describes both parameters with 100% coverage, so the description adds little beyond the baseline. It mentions 'time window' and agent scoping implicitly, but no additional semantic detail beyond what the schema provides.

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 this is a spend/usage analytics rollup returning KPIs, daily series, and top endpoints — a specific verb and resource. It implies a high-level 'one-call view' but does not explicitly contrast with sibling tools like get_activity, so it stops short of full differentiation.

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 clear context for when to use it ('how is my fleet doing' one-call view) and notes a prerequisite (developer key). It does not explicitly exclude scenarios or name alternative tools, but the usage context is sufficiently clear.

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

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

With no annotations, the description must carry the burden of disclosure. It adds the authentication requirement and the dual-role (borrower/lender) behavior, which is useful. However, it does not explicitly state that it is a read-only operation (though 'Get' implies it), nor does it describe the return format, pagination behavior, or error cases. There is a clear gap but the core behavioral context is present.

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 two short sentences, front-loaded with the primary function and immediately followed by the authentication requirement. Every word adds value, with no redundancy or 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 a simple read tool with two well-described parameters and no output schema, the description is reasonably complete. It covers the key scope (all loans, dual role) and the necessary auth context. Missing details like response shape or pagination are partly implied by the parameters and the nature of the tool. For a list endpoint, this is sufficient.

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 schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by clarifying that wallet_address is used to fetch loans for both borrower and lender roles, which is not present in the schema. This semantic enrichment justifies a 4.

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 'Get all loans for a wallet address' with a specific verb and resource, and the 'both as borrower and lender' clause provides a scope that distinguishes it from sibling tools like get_loan or intent-specific tools. This is a precise, non-tautological statement of purpose.

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 clear context for when to use this tool (to fetch all loans for a wallet) and includes a prerequisite (requires any Floe API key). It does not explicitly name alternatives or say when not to use it, but the scope and requirement provide enough guidance for most users.

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

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

With no annotations, the description carries the burden of disclosing behavior. It does mention the required API key type, which is helpful. However, it does not explicitly state that the operation is read-only or describe the return format, though the word 'Check' implies a safe query.

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 that efficiently conveys both the purpose and the authentication requirement. Every word contributes value, and there is no redundant or filler content.

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 (2 parameters, no output schema, no annotations), the description covers the essential purpose and auth context. It could optionally note the default behavior when token_symbol is omitted, but the schema already explains that, so the description is sufficiently 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 provides full descriptions for both parameters (wallet_address and token_symbol), achieving 100% coverage. The tool description adds no additional parameter semantics beyond what the schema already offers, so the baseline of 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 states the action ('Check token balances') and the resource ('for a wallet'), making the tool's purpose unambiguous. It does not explicitly differentiate from similar siblings like get_balances, but the scope is clear enough for selection.

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 provided on when to use this tool versus alternatives such as get_balances or get_token_price. The only contextual note is the authentication requirement, which is a prerequisite rather than a usage condition.

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

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

With no annotations, the description carries the burden. It discloses the key safety behavior: it only builds an unsigned transaction, thus no on-chain state change. It also states the API key requirement. However, it does not reveal what the output looks like, whether it performs health checks before liquidation, or any failure conditions.

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: two sentences, no redundant text, and the core action is front-loaded. Every phrase earns its place, including the API key requirement.

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 having no output schema, the description does not mention what the tool returns (presumably an unsigned transaction object) or how it relates to sibling tools like simulate_transaction or broadcast_transaction. It also leaves ambiguity about the optional market_id parameter and the conditions under which liquidation is attempted, making the description incomplete for a 4-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 each parameter (loan_id, market_id, max_repayment, wallet_address). The description adds no additional parameter-level semantics beyond what is in the schema, so a baseline score of 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 states the action: 'Build unsigned tx to liquidate an unhealthy loan,' with a specific verb (build), resource (unsigned tx), and target (unhealthy loan). This distinguishes it from related tools like repay_loan and broadcast_transaction by emphasizing 'unsigned tx' and 'liquidate'.

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 use case (liquidating an unhealthy loan) but does not explicitly mention when to use this tool over alternatives like repay_loan, nor does it note that the built transaction would need to be broadcast separately via broadcast_transaction. It also doesn't describe prerequisites beyond the API key requirement.

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

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

With no annotations, the description carries the burden. It discloses the authentication requirement (developer key) and the returned fields, which is useful. But it does not mention read-only semantics, pagination, rate limits, or error behavior, leaving some behavioral traits undisclosed.

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 two short sentences with no fluff. The first sentence front-loads the main action and results, and the second adds the essential auth prerequisite. Every word contributes value.

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 simplicity (0 params, no output schema), the description explains the core purpose and return fields, but lacks clarity on response structure (e.g., array vs. single object), pagination, or any limits. It is adequate for a basic list tool but not fully 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 has zero parameters, so the baseline is 4. The schema is empty and coverage is 100% vacuously. The description need not explain parameters; it correctly implies no input arguments are required, aside from the developer key which is an auth requirement, not a 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 clearly states the tool lists every agent owned by the developer account, includes specific fields (status, wallets, credit limits), and is distinct from the singular "get_agent" sibling. The verb "List" and scope "every agent" make the purpose unambiguous.

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

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

The description implies usage when you need a full list of agents, and notes the prerequisite of a developer key. However, it does not explicitly contrast with alternatives like get_agent or provide when-not-to-use guidance, so guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the authentication requirement (agent key), the scope of entries, and that spend caps are included. It does not explicitly state the return format or error behavior, but for a read-only list operation, this is adequate 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?

The description is two sentences long, front-loaded with the action and resource, and contains no redundant or filler words. Every clause adds value (scope, exclusions, authentication requirement).

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 parameterless list tool with no output schema, this description is complete: it states the purpose, scope, exclusions, and a prerequisite. It gives enough detail for an agent to decide when to use it and what to expect.

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 has zero parameters, so the baseline is 4. The description correctly focuses on the tool's behavior rather than parameter details, which is unnecessary here.

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 it lists the agent's merchant-allowlist entries, specifying the scope (host 'api' and payee 'vendor' policies) and explicitly mentioning spend caps. It distinguishes itself from sibling tools like get_allowlist_mode or add/remove allowlist entries by defining its exact resource and function.

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 provides usage context by stating what the tool includes and excludes (session/task spend policies are excluded) and notes the prerequisite of an agent key. However, it does not explicitly name an alternative tool for the excluded policies, so it misses the full 'when to use vs. alternatives' guidance that a 5 would require.

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

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

With no annotations provided, the description carries full behavioral disclosure. It adds meaningful context beyond the obvious: mentions the three webhook types (credit.warning, credit.at_limit, credit.recovered) and the authentication requirement (agent key floe_...). This goes beyond a bare 'list' statement, though it does not cover return format or error 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?

The description is two sentences, front-loaded with the primary action, followed by two concise pieces of behavioral context. No superfluous words, no repetition of the tool name beyond the necessary subject. Excellent structure.

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

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

For a simple list tool with no parameters, no annotations, and no output schema, the description covers the key aspects: action, associated webhook events, and authentication. It could mention what the return value looks like, but that is easily inferred for a list operation. The description is sufficiently complete for its simplicity.

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

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

There are zero parameters and the schema is empty, so there is nothing to document. The baseline for 0-parameter tools is 4, and the description adds no unnecessary param details. It correctly omits what does not 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?

The description clearly states the tool's function: 'List the agent's registered credit-utilization thresholds.' It uses a specific verb ('List') and resource ('credit-utilization thresholds'), and the added detail about webhook events distinguishes it from sibling mutation tools like register_credit_threshold and delete_credit_threshold.

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 context is clear: this is for reading registered credit thresholds. It does not explicitly mention when not to use it or name alternatives, but given the simple read-only nature and zero parameters, the intended use is obvious. No exclusions are needed, so it earns a 4.

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

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

With no annotations, the description carries the full burden. It discloses the return shape (OpenAI-compatible model objects with id, modality, context_window), the keyless pay-as-you-go nature, and the authentication requirement. However, it doesn't explicitly state that the operation is read-only or describe pagination/error behavior, so it's not fully transparent but still strong.

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 three sentences, each earning its place: purpose, return values and usage, and auth requirement. It is front-loaded with the main action, uses no filler, and is easily scannable.

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, no-output-schema tool, the description covers the necessary context: what the tool returns, how to use the returned data, and auth. It could optionally mention pagination or read-only semantics, but it is sufficiently complete for an agent to invoke and interpret results.

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

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

There are zero parameters, and the schema coverage is 100% (empty object). The baseline for 0 params is 4. The description adds context about the returned id format and how to use it, which is relevant to parameter-like behavior but not required since no params 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?

The description opens with a specific verb+resource: 'List the models available on Floe Inference'. It clearly identifies the tool's scope and distinguishes it from sibling tools by naming the specific gateway and the types of model objects returned (OpenAI-compatible with fields like id, modality, context_window).

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 explicit usage guidance: the returned id should be used with specific endpoints, and estimate_inference_cost is suggested as an alternative for pricing calls. It also states the authentication prerequisite (any Floe API key). This clearly helps the agent decide when and how to use the tool.

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?

No annotations are provided, so the description carries the full burden. It discloses that secrets are never returned, which is an important behavioral constraint, and states the auth requirement. It omits pagination details or response format, but for a simple list operation it offers solid 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?

The description is two sentences, both purposeful. The first states exactly what is listed, and the second adds the secret-exclusion and auth requirements. There is no redundancy or filler.

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

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

For a parameterless list operation with no output schema, the description covers the key aspects: the resource, the fields returned, the exclusion of secrets, and the auth requirement. This is sufficient for an agent to know what to expect.

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 has zero parameters, so the schema is empty. Per rubric, the baseline is 4, and the description correctly omits parameter details since none 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?

The description uses the specific verb 'list' with the resource 'the account's registered webhooks', clearly stating the scope and returned fields (subscribed events, scope, active flag). It distinguishes this from sibling tools like create_webhook and test_webhook.

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 usage for listing webhooks but does not explicitly contrast it with alternatives or provide when/when-not guidance. The only context given is the required developer key, which is a prerequisite rather than usage direction.

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

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

With no annotations, the description carries the full burden. It discloses a side effect ('the server signs a borrow intent collateralized from the agent's wallet'), a prerequisite (wallet must hold deposit), and an authorization requirement (developer key). However, it does not explain the return value, reversibility, or potential failure modes, leaving some behavioral gaps.

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 concise and well-structured: three sentences that front-load the core purpose, then add prerequisites and authorization. Every sentence adds necessary information, with no filler or redundancy.

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 moderate complexity (4 parameters, no output schema, no annotations), the description covers purpose, prerequisites, auth requirements, and references to related tools. It could benefit from stating what the response contains, but it is adequate for an agent to understand the operational context.

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 schema provides full 100% coverage of all 4 parameters. The description adds value by linking deposit_raw to collateralization from the agent's wallet, referencing get_credit_line_bounds for valid ranges, and clarifying that max_ltv_bps and max_rate_bps are optional overrides. This enriches the schema's basic definitions.

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 the tool's function: 'Upgrade a pay-as-you-go agent to a managed credit line.' It distinguishes from siblings like create_borrow_intent by emphasizing the upgrade action and the managed credit line outcome, making the purpose specific and unambiguous.

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

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

The description provides explicit prerequisites: the wallet must already hold the deposit (with a reference to get_funding_instructions) and advises checking get_credit_line_bounds first for valid deposit/LTV ranges. It also notes the developer key requirement. It lacks explicit alternative exclusions (e.g., 'use create_borrow_intent instead'), but the context is clear.

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

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

With no annotations provided, the description carries the full burden and does well: it explicitly states that all calls with the agent's keys will fail auth from the next request until resume_agent, and that only active agents can be paused. It also discloses the developer key requirement. It stops short of describing idempotency or return values, but the core behavioral impact is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-load the core purpose, then add behavioral and prerequisite information. No wasted words, and the structure is efficient and scannable.

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 single-parameter mutation tool with no output schema, the description covers purpose, effect, prerequisites, and auth. It is complete enough for an agent to select and invoke the tool correctly, especially with sibling names like resume_agent and close_agent providing contrast.

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 single parameter agent_id is described as 'Numeric agent id.' The description itself adds no additional detail about the parameter beyond referencing 'the agent's keys,' which is context rather than parameter semantics. With high schema coverage, 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 opens with a specific verb and resource: 'Pause (suspend) one agent — the per-agent kill-switch.' This clearly identifies the operation and its scope, and the contrast with 'resume_agent' distinguishes it from the obvious sibling. The mention of 'per-agent kill-switch' adds precise functional identity.

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 clear usage context: it is used to suspend a single agent, only works on active agents, and requires a developer key. It also states the effect lasts 'until resume_agent,' implying the recovery path. However, it does not explicitly list 'when not to use' or alternative tools beyond the implicit resume_agent.

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

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

With no annotations provided, the description carries the full burden. It discloses important behavioral traits: crossing direction triggers (from below), event names (credit.warning, credit.at_limit, credit.recovered), the 9500 bps special case, the per-agent cap, and authentication requirement. This goes well beyond a typical one-liner.

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 brief, front-loaded with the primary action, and every sentence adds meaningful detail (event triggers, recovery, cap, auth). No wasted words.

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 tool with no output schema, the description covers the key aspects: purpose, event behavior, cap, and authentication. Gaps such as return value/created resource formatting and duplicate handling exist, but the description is complete enough for correct tool selection and basic 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 coverage is 100%, so baseline is 3. The description adds extra semantic value by explaining the crossing direction ('from below'), the recovery event ('Drops below'), and the 9500 bps special case, which are not fully captured in the schema parameter descriptions alone.

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

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

The description uses a specific verb ('Register') and resource ('credit-utilization threshold'), and clearly differentiates from sibling tools list_credit_thresholds and delete_credit_threshold by focusing on creation and resulting webhook events.

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 provides clear context for when to use the tool (to create a threshold), including constraints like the cap of 20 thresholds per agent and requirement of an agent key. It does not explicitly mention alternatives or when not to use it, but the context is sufficient.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the auth requirement (agent key) and the action (revoke), but does not mention side effects, error handling, idempotency, or response behavior. For a mutation tool, this is a notable 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?

The description is a single, well-structured sentence that front-loads the action and purpose, includes the source hint, and states the auth requirement. Every word contributes; there is no redundancy or 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 simple input schema (one integer param), no annotations, and no output schema, the description provides enough context for basic invocation: what to do, how to identify the entry, and what credential is needed. It does not cover error scenarios or idempotency, but for a tool of this simplicity, the overall package is reasonably 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 schema already describes policy_id thoroughly with a description and exclusiveMinimum, giving 100% coverage. The description adds value by specifying that the id comes from list_allowlist, which serves as a concrete source hint for the agent. This exceeds 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 uses the specific verb 'Remove' with a parenthetical 'revoke' to make the action unambiguous, and names the target resource 'merchant-allowlist entry' along with the key identifier 'by policy id'. It also references 'list_allowlist' to distinguish from sibling tools like add_allowlist_entry, making the purpose 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 implies usage context by noting the entry comes from list_allowlist and that an agent key is required, but it does not explicitly state when to use this tool versus alternatives (e.g., add_allowlist_entry) or exclusion scenarios. The prerequisite is a usage guideline, but it is not fully developed.

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