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

Discloses key behaviors: cost ($0.10 USDC per call), output structure, channel flexibility, and validity period. Lacks details on failure modes or rate limits, but is otherwise 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?

Three sentences, front-loaded with action verb 'Mint', no redundant information. Every sentence adds 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 no output schema and few parameters, the description fully explains purpose, inputs, outputs, and when to use it. No apparent gaps.

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

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

All parameters have schema descriptions (100% coverage), so baseline is 3. Description adds context (EIP-712 verification, single-use, Base mainnet), elevating beyond schema-only 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 clearly states the tool mints an agent session using EIP-712 verification and on-chain attestation on Base mainnet. It specifies the output (single-use 6-digit code, expiration, transaction hash). Sibling tools are unrelated, so no ambiguity.

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?

Explicit guidance: 'Use this when an agent needs to authenticate itself...via voice call or HTTPS handshake.' Includes cost and settlement details, helping distinguish from other 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 full burden. It discloses real-time nature, decoded formats, batch limit, sources, cost, and settlement details. Lacks explicit read-only claim but is inferable.

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?

Concise yet comprehensive: includes purpose, outputs, batch, sources, cost, usage guidance, and examples with no superfluous text.

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?

Adequate for a single-parameter query tool with high schema coverage. Could mention error handling or rate limits, but not critical.

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 well-documented structurally. Description adds context (examples, batch hint) but not essential beyond 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 it provides real-time aviation weather for any ICAO airport, listing specific outputs (METAR, TAF, SIGMET, forecast) and batch capability. It distinguishes well from unrelated sibling 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?

Explicitly lists use cases (airport weather, flight planning, etc.) and provides example ICAO codes. While it doesn't mention when not to use, the sibling tools are unrelated, so guidance 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?

No annotations provided, but description fully discloses cost ($0.02/call), data source (FRED), settlement (Base mainnet), and that it always returns a current snapshot. No side effects or contradictions.

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 efficiently convey purpose, outputs, and context. No redundant phrases, though could be marginally tighter. Well-structured with front-loaded 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 zero parameters and no output schema, the description covers all needed context: what rates are returned, cost, source, and that it's a snapshot. No gaps remain for an agent to use 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?

No parameters exist, and schema coverage is 100%. Description explicitly states 'No parameters required', adding clarity beyond the schema. Baseline 4 for zero params is exceeded by the helpful note.

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 live US mortgage and macro rates, listing specific rates (30-year, 15-year fixed, prime, fed funds, CPI). It distinguishes itself from siblings by focusing on financial rates, with no ambiguity.

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

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

Explicitly tells when to use: when user asks about current mortgage rates, refinance rates, prime rate, etc. Although it does not mention when not to use or alternatives, no close sibling tools exist, making the guidance 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, the description carries full burden. It reveals it returns 50+ fields, includes AVM and schools, and importantly states the cost ($2.00 USDC from wallet on Base mainnet). This discloses a behavioral trait (payment) beyond typical read operations. Could add rate limits or auth details, but cost transparency is 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 front-loaded with purpose, then details, then usage guidance, then cost. Each sentence adds value. Slightly verbose but well organized. Could merge '50+ fields' line with earlier sentence.

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

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

Given the tool's complexity (50+ fields, no output schema), the description provides a solid overview of return categories (property, AVM, demographics, schools). The two parameters are well described. The description compensates for lack of output schema by listing data types.

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%, but the description adds value: provides an example address format and notes that 'include' defaults to all sections. This helps the agent understand usage beyond schema 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?

Tool name 'property_dossier' combined with description 'Comprehensive US property intelligence from a single address' clearly indicates a specific verb (get) and resource (property dossier). The description lists detailed data categories, distinguishing it from siblings like mortgage_rates or aviation_weather.

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 this when the user asks about: property research, real estate analysis, mortgage qualification, neighborhood data, school zoning, property due diligence.' It also mentions the cost and blockchain settlement, aiding decision-making. Lacks explicit 'when not to use', but siblings provide 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?

Without annotations, the description discloses cost ($0.50 USDC), settlement network (Base mainnet), and deterministic passthrough with source attribution. Could mention failure modes or data handling, but sufficient for expected 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 focused sentences with a bullet list of use cases and cost note. No wasted words, front-loaded with key 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?

No output schema, but description details return values (score, provenance, IDs, URLs) and cost/deterministic nature. Covers all aspects for a screening 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 coverage is 100%, baseline 3. Description adds value by noting 'dob improves match accuracy' and 'country code is ISO-3166 alpha-2', providing context beyond 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 it screens against 100+ global sanctions lists, names specific lists (OFAC, UN, EU, UK), and lists return fields (match score, provenance, etc.). It distinguishes from siblings by providing a specific compliance use case.

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

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

Explicitly tells when to use: 'Use this when the user asks about: compliance checks, KYC, screening counterparties, OFAC/sanctions, due diligence.' Also clarifies no LLM involvement, ensuring reliability.

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, description fully discloses: powered by ATTOM, costs $0.02 USDC per call, settled on Base mainnet from user's wallet. This covers data source, cost, and payment method. Also indicates it is a read operation (returns data). No contradictions.

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?

Description is 4 sentences, front-loaded with purpose, then usage guidelines, then cost. Efficient but could be slightly more concise. Good 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?

Given single parameter and no output schema, description covers purpose, usage, cost, and data source. It mentions summary and detail but lacks explicit response structure. Still fairly complete for the tool's 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?

Only one parameter (address) with schema description already providing format and example. Coverage is 100% so baseline is 3. The description does not add additional semantics 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 it returns US property title chain history with specific data types (recorded deeds, mortgages, preforeclosure events) and includes summary and chronological detail. It distinguishes from sibling tools like property_dossier by being specifically about title chain.

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

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

Explicitly lists use cases (title verification, ownership history, etc.) and says 'Use this when the user asks about:' providing clear guidance. Does not mention when not to use or alternatives, but the list sufficiently directs usage.

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 reveals cost ($0.02 USDC per call), settlement details (Base mainnet from your wallet), and return information (balance, block height, on-chain receipt). While it does not mention rate limits or error handling, the disclosed cost and return structure are sufficient for this simple query 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 concise and well-structured, with the main action stated upfront. Each sentence adds meaningful information (supported chains, token resolution, cost, use cases). It could be slightly shorter, but there is 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 the tool's simplicity, full schema coverage, and no output schema, the description provides adequate context: it explains what the tool returns (balance, block height, receipt), costs, and supported chains. It does not cover error scenarios or timeout behavior, but for a balance-checking tool 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?

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that common tokens (USDC, USDT, WETH, WBTC, DAI) resolve by symbol and others need contract addresses. It also clarifies that the threshold parameter returns a sufficient/deficient flag. This additional context helps the agent understand parameter usage better.

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 wallet balances across 5 EVM chains, returning native or ERC-20 balances with optional threshold checks. It specifies supported chains and token resolution methods. This is a specific verb+resource description that fully conveys the tool's purpose without ambiguity.

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 this when the user asks about: wallet balance, token balance, checking if a wallet has enough funds, multi-chain balance lookup.' This provides clear guidance for the AI agent on context triggers, and given sibling tools are unrelated, no alternative guidance is needed.

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