mainstreet

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

No annotations are provided, so the description must carry the burden. It implies a read-only list operation and hints at the output's purpose but does not disclose authorization needs, rate limits, or return format details.

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 superfluous words. Every phrase 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?

For a list tool with no output schema and 2 parameters (0% described in schema), the description covers the filter choices but omits limit and return structure. Given 18 siblings, it could better position itself relative to audit_info or vet.

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

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

Schema coverage is 0%, so description must compensate. It explains the enum filter values ('high-activity-low-trust', etc.) but does not mention the 'limit' parameter or its meaning, leaving a gap.

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 a 'curated shortlist of Base agents worth auditing' and lists three filter categories, which distinguishes it from siblings like mainstreet_audit_info (detailed audit info for a single agent) and mainstreet_leaderboard.

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

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

The description explains the three filters with concise tags (risky, fresh, safest), giving immediate context for when to use each. However, it does not explicitly state when NOT to use this tool or compare to alternatives like mainstreet_find_verified.

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 carries the burden. It discloses that the tool returns a signed payload, domain, types, and signer, and explains onchain verification. It doesn't mention idempotency or rate limits, but the context is reasonably transparent for a read-like operation.

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, no waste. The main purpose is front-loaded, and each sentence adds value: first states what it does, second gives usage guidance and return 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 no output schema, the description explains the return payload adequately. The single parameter is understood, but the tool's role among siblings is clear. A minor gap is the lack of parameter format details.

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 description mentions the parameter 'address' as 'for an address', but does not specify format (e.g., 0x-prefixed hex). Schema coverage is 0%, so the description should compensate more. With one required parameter, a score of 3 is adequate.

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 specifies the verb 'Get' and the resource 'EIP-712 signed attestation for an address', clearly defining cryptographic proof of score. It distinguishes from a plain HTTP read, making it distinct among siblings like mainstreet_score and mainstreet_verify.

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 states 'Use when you need oracle-grade trust, not just an HTTP read', providing clear guidance on when to use this tool over others. No exclusions, 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?

No annotations provided, so description must carry full burden. It mentions the endpoint is premium and costs $0.25 USDC, but lacks disclosure on read-only/destructive nature, rate limits, auth requirements, or what 'full due-diligence' entails.

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

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

Single sentence efficiently communicates key information: endpoint, cost, purpose. No 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 simple tool with one parameter and no output schema, the description covers the essential use case and return type (URL + instructions). Lacks detail on response format or prerequisites but sufficient for basic understanding.

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 0%; description only implies 'address' is a wallet address via context ('wallet before paying it onchain'). No format, validation, or example provided for the single 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?

Clearly states it retrieves URL and instructions for a premium audit endpoint, specifying the cost and purpose (due-diligence on a wallet before onchain payment). Distinguishes from siblings by focusing on info retrieval for the audit endpoint.

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?

Implied usage for wallet due-diligence before payment, with cost context. Does not explicitly exclude alternatives or mention when not to use, but the purpose is clear enough.

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; description provides basic behavior (returns agents with trust scores, sortable, filterable) but omits critical details like read/write nature, authentication needs, result limits, or pagination.

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 no redundancy. First sentence is marketing-flavored but second is concise and informative. Could be tighter without 'drop-in safer' claim.

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 5 parameters, no output schema, and no annotations, the description leaves significant gaps: meaning of 'x402', limit behavior, excludeUnscored usage, and result format are absent.

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

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

Schema coverage is 0%, but description covers three parameters (sort, network, minScore) indirectly. It misses limit and excludeUnscored entirely, and does not explain enum values for sort. Partial compensation.

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 it returns agents with trust scores and is sortable/filterable. However, it does not differentiate from sibling tools like mainstreet_leaderboard or mainstreet_catalog beyond positioning as a CDP Bazaar alternative.

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

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

Only vague guidance: 'safer alternative to CDP Bazaar discovery.' No explicit when-to-use, when-not-to-use, or alternatives among siblings 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 full burden. It accurately indicates a read-only listing of endpoints, implying no side effects. While it doesn't detail behavior like return format or pagination, the simple nature of listing makes this adequate.

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 perfectly front-load the purpose and usage. Every word adds value without 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 listing tool with no parameters and no output schema required, the description fully covers what the agent needs to know 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?

The tool has zero parameters, so the description need not explain them. It appropriately focuses on the output purpose rather than input 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 explicitly states that the tool lists all MainStreet API endpoints, distinguishing between free and paid with prices. This clearly defines the tool's function and differentiates it from sibling tools that likely perform specific operations on these endpoints.

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 advises using the tool to discover available capabilities, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, which would improve guidance for the 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, the description carries full burden but only states the basic operation. It does not disclose read-only nature, prerequisites, or any side effects.

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?

One concise sentence with no fluff. Every word 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?

The tool has no output schema and few context signals. The description does not explain return format, data freshness, or any usage constraints, leaving significant gaps.

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

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

Schema description coverage is 0%, so description must compensate. It implies parameters are agents but does not clarify they are addresses or specify the format beyond the schema pattern.

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 'compare' and resource 'agents', clearly indicating head-to-head comparison with side-by-side metrics. It is distinct from sibling tools like mainstreet_score or mainstreet_match.

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. No when-to-use or when-not-to-use context 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 full burden. It details the output: score 0-100, verdicts (SAFE, CAUTION, BLOCK), human-readable assessment, and launch history with alive/rugged status. It also explains the scoring factors. This provides good behavioral transparency for a read-only analysis 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: a succinct purpose statement, a usage recommendation, and a brief explanation of the score. No filler or redundancy. 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?

Despite lacking an output schema, the description thoroughly explains return values (score, verdict, assessment, launch history) and scoring factors. It also provides usage context. This makes the tool's functionality fully understandable without additional documentation.

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%, with a parameter description stating 'Deployer wallet address (the wallet that called the factory).' The tool description adds context: 'on Base' and 'reputation of a token DEPLOYER wallet', clarifying the purpose behind the parameter. This goes slightly 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 tool checks the reputation of a token deployer wallet on Base, differentiating it from siblings like mainstreet_score (for tokens) and mainstreet_vet. It specifies verb 'Check', resource 'reputation of a token DEPLOYER wallet', and network 'Base'.

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 says 'Use when an LLM is asked to evaluate a token, or before aping into a recent launch.' This gives clear context for when to use. However, it does not mention exclusions or alternatives, such as when to use sibling tools instead.

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?

Discloses paginated address list return and behavior without `type`. No annotations provided, so description carries full burden; it adequately covers key behaviors for a simple discovery tool, though lacks details on pagination metadata or rate limits.

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

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

Three front-loaded sentences: purpose, return format/behavior, usage context. No wasted words; 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?

Covers purpose, behavior with/without type, pagination, and usage context. Lacks specifics on response structure (e.g., total count), but tool is simple enough that the description is mostly 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?

Schema coverage is 100% with clear descriptions for each parameter (type, limit, offset). Description adds minimal extra meaning beyond reinforcing the 'omit type' behavior, so 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?

Description clearly states verb 'Discover' and specific resource 'Base wallets verified by an external identity platform', listing exact platforms. Differentiates from sibling tools like mainstreet_verify which likely verify individual addresses.

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 states 'Use to pre-filter a trusted set of agents/wallets before asking for individual scores.' Includes behavior when `type` is omitted (list available platforms), but does not mention when not to use or 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 carries the full burden. It only states that the tool lists top-scored agents, without disclosing behavioral traits such as whether it's read-only, authentication requirements, rate limits, or what happens on invalid input. The description is too sparse for an unannotated 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 sentences, front-loaded with the purpose and immediately followed by usage guidance. Every sentence earns its place with zero redundancy or 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?

For a simple leaderboard tool with two optional parameters and no output schema, the description is fairly complete. It covers purpose and usage context. It could mention the return format or what 'top-scored' means, but the low complexity makes this acceptable.

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 both parameters (limit, network) described in the schema (default values and filtering). The description does not add any additional semantics 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 clearly states the tool lists top-scored onchain AI agents on Base, with a specific verb ('List') and resource ('top-scored onchain AI agents'). It also provides a usage example ('who is best at X'), distinguishing it from siblings that focus on scoring, comparison, or verification.

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 says when to use the tool: when the user asks 'who is best at X' or wants discovery without a specific intent. It provides positive guidance but does not mention when not to use it or suggest alternatives among the 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?

No annotations are provided, so the description bears full responsibility. It states the tool 'finds' and 'returns ranked matches' but does not disclose behavioral traits like rate limits, authentication requirements, or potential side effects. The read-only nature is implied but not explicit, leaving significant 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 two sentences with no fluff. It front-loads the action ('Find onchain AI agents...') and efficiently includes usage guidance and return details. 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 tool has six parameters, no output schema, and no annotations, the description provides a moderate level of completeness. It explains the return fields but lacks details on result format, error handling, or any constraints. The 'Use BEFORE' instruction adds context, but overall it falls short of fully informing an agent.

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% with descriptions for all six parameters. The description does not repeat or add meaning beyond what the schema provides, 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 starts with a specific verb 'Find' and resource 'onchain AI agents on Base' matched via 'natural-language intent'. It clearly distinguishes from siblings like 'mainstreet_find_verified' by focusing on intent matching. The mention of return fields (reputation, settlement history, etc.) reinforces the unique 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 explicitly advises 'Use BEFORE paying an x402 endpoint', providing clear context for when to invoke. However, it does not mention when not to use this tool or suggest alternatives (e.g., mainstreet_find_verified for verified-only searches), which would improve the score.

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 must disclose behavioral traits. It states the tool returns one agent with specific fields but does not mention whether the operation is read-only, if it has side effects, or what happens if no agent matches the intent. The verb 'pick' suggests a read operation, but this is not confirmed.

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 with two sentences. It front-loads the core purpose and lists return fields. Every sentence is meaningful, though a bit more structure (e.g., separating input from output) could improve readability.

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 6 parameters and no output schema, the description is somewhat complete but lacks detail. It lists return fields but does not explain error conditions, default behavior, or what 'best' means (e.g., scoring criteria). The simplicity lowers the bar, but more context would be beneficial.

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 only 17% (only allowWeak has a description). The tool description does not explain any of the 6 parameters, nor does it clarify how maxPrice, minScore, or other filters affect the selection. Given the low coverage, the description fails to add value over 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 tool's purpose: 'Pick the single best agent for an intent in one call.' It specifies the action (pick), the resource (best agent), and the scope (single, one call). The returned fields are listed, which distinguishes it from sibling tools that may return multiple agents or do comparisons.

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 includes 'Use when you want to act immediately,' providing context on when to use the tool. However, it does not explicitly state when not to use it or mention alternatives among the 18 sibling tools. This limits its usefulness for decision-making.

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 full burden. It states the tool returns a decision+verdict+score+reasoning+SLA/health and runs in <100ms, implying it is a safe, read-only check. However, it does not disclose authentication requirements, rate limits, or behavior on invalid addresses. This leaves 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 two sentences with no wasted words. It front-loads the purpose and efficiently covers usage, output, and performance. 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 has one simple parameter and no output schema, the description covers the core functionality: what it does, when to call it, and what it returns. It lacks details on error handling or address format verification, but overall it is complete for its intended use.

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 has 0% description coverage, and the tool description does not explicitly describe the 'address' parameter. While the context ('before paying a Base counterparty') implies the address is the counterparty, the description adds no direct semantic meaning to the parameter. The agent must infer its purpose.

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 is a pre-payment trust check for buyer agents paying Base counterparties over x402. It specifies the exact context and output (decision, verdict, score, reasoning, SLA/health). This distinguishes it from sibling tools like mainstreet_verify or mainstreet_score, which likely serve 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?

It explicitly instructs to call this tool 'before settling USDC to any wallet, agent, or token — refuse on BLOCK.' This gives clear when-to-use guidance. However, it does not mention when not to use or suggest alternatives, which would be a minor improvement.

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 mentions 'live', 'transparency', and 'real x402 settlements onchain', indicating real-time on-chain data. However, it lacks details on update frequency, potential costs, or whether any state changes occur.

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 with two front-loaded sentences. The first sentence states the core function, the second adds 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?

For a simple no-parameter tool, the description covers purpose and usage context. However, lacking an output schema, it could briefly describe the output format (e.g., JSON structure) to improve completeness.

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 and schema coverage is 100% (empty). Per guidelines, baseline for 0 parameters is 4. The description correctly adds no parameter-related content.

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 'Live revenue stats for MainStreet', which is a specific verb+resource. It distinguishes from sibling tools like mainstreet_leaderboard or mainstreet_verify by focusing on revenue 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 description includes a use case: 'Useful to assess oracle credibility.' This gives clear context for when to use it, but it does not explicitly mention when not to use it or alternatives among the 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?

No annotations provided, so description carries full burden. Lists return fields (score, health, settlements, SLA, receipts, trust level) and implies read-only operation. Lacks details on latency or prerequisites, but sufficient for basic behavioral understanding.

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: first defines purpose and output format, second enumerates returned data. Front-loaded, 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 single-parameter read tool with no output schema, the description adequately covers purpose, parameter, and return fields. Could mention if all addresses are valid or any restrictions, but overall 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?

Schema coverage is 100% with one parameter. Description adds context by specifying 'on Base' and implying it's for a single address, going beyond the schema's minimal description.

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

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

Explicitly states 'Read live reputation score 0-100 for a specific agent address on Base.' Clear verb, resource, and scope. Distinguishes from batch or list siblings.

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?

Implies single-address use via 'for a specific agent address,' but does not explicitly contrast with sibling tools like mainstreet_scores_batch or mainstreet_compare for when to avoid.

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 batch nature (up to 200 addresses) and return fields, which is helpful. However, it does not mention error handling, rate limits, or authentication requirements, leaving some behavioral aspects unclear.

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 two sentences, no unnecessary words. It front-loads the core functionality and includes a useful pairing tip without excess.

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 complexity (batch tool with many siblings) and absence of output schema, the description adequately explains the return values and suggests a complementary workflow. It could mention potential error cases or rate limits, but overall it's sufficient for a basic understanding.

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 description adds limited value beyond the schema. It reiterates the batch size (up to 200) but the schema already specifies maxItems. It does not provide additional context for the address parameter's meaning or format beyond the schema's pattern.

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 performs a batch score lookup for up to 200 addresses, specifying the return fields (agentScore, deployerScore, etc.). It distinguishes itself from siblings like mainstreet_score (single) and mainstreet_find_verified (discovery) by explicitly pairing them.

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

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

It provides a usage pattern: 'Pair with mainstreet_find_verified for two-call discovery'. However, it does not explicitly state when not to use this tool (e.g., for a single address) or list alternatives beyond the pairing suggestion.

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 the tool is read-only (reading top spenders) and indicates the sorting and filtering behavior. No negative side effects are implied.

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 that are concise and front-loaded with essential purpose, followed by a use-case sentence. 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 no output schema and low parameter coverage, the description could explain return fields or ordering. It implies order by spending amount but lacks full context on output.

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

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

Schema coverage is 0% so description must compensate. It mentions 'last N days' for the sinceDays parameter but does not explain the limit parameter. Provides partial but not complete 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 clearly identifies the specific verb (spent), resource (wallets), and context (via x402 on Base, time range). It distinguishes from sibling tools like mainstreet_top_raters which focus on ratings.

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 two use cases: prospecting for customers and allowing buyers to see their own rank. However, it does not mention when not to use this tool or provide alternatives among siblings.

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 explains ranking criteria but does not disclose potential edge cases, authentication needs, or what happens when no data exists. 'Leaders-of-leaders' concept is explained well.

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-load the purpose and ranking logic with no redundant words. 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?

Given a single optional parameter and no output schema, the description adequately explains the ranking logic and output nature. Minor gap: not specifying what fields are returned per agent, but acceptable for a top-N list.

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% with one 'limit' parameter (min 1, max 50, default 20). Description adds no extra meaning beyond the schema, so 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 tool returns top peer-rating agents (wallets) and explains the ranking logic: rates many distinct agents and those agents have healthy scores. It distinguishes from siblings like mainstreet_top_buyers by specifying 'raters' rather than 'buyers'.

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

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

No explicit guidance on when to use this tool vs alternatives like mainstreet_top_buyers or mainstreet_leaderboard. The description implies usage for finding top raters but lacks exclusions or comparisons.

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 discloses behavior: recovers signer, checks freshness and operator match, optional minScore. It also lists return fields. However, it does not mention potential failure modes or authentication requirements.

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: first specifies action and features, second gives usage guidance and return fields. No wasted words, front-loaded with 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?

For a tool with 3 params, one nested object, and no output schema, the description covers verification logic, usage context, and return fields. Lacks payload structure details but sufficient for common use.

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

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

Schema coverage is 0%, so description must compensate. It maps minScore to 'optionally enforce a minimum score' and implies payload/signature for attestation. But payload is a nested object without field details, leaving ambiguity. Adds some value beyond schema but insufficient for completeness.

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 verifies a MainStreet EIP-712 signed attestation with specific actions: recovers signer, checks freshness, matches operator, and optionally enforces min score. It distinguishes from siblings by focusing on verification of received verdicts.

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: 'Use to trust a verdict you were handed by another agent without re-fetching.' It provides clear context but does not explicitly exclude other scenarios or mention 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 provided. Description mentions throwing behavior but does not disclose whether the tool is read-only, has side effects, or requires authentication. For a validation step, more detail on return value or idempotency would help.

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, minimal and front-loaded. First sentence explains core function, second gives critical usage instruction. No 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?

Reasonably complete for a simple validation tool: covers purpose, conditions, and placement. But lacks details on return value (success indicator) and how to proceed after vetting. With no output schema, description should fill that 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 covers 67% of parameters with defaults but no additional meaning in description. Address parameter lacks any semantic explanation beyond the pattern. Description adds nothing about parameter behavior beyond what 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 clearly states verb and resource: 'Vet an agent against minimum reputation + alive gate'. It distinguishes this tool from siblings (e.g., mainstreet_score, mainstreet_verify) as a pre-payment safety check. The purpose is 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?

Explicitly states when to use: 'Always call BEFORE x402 payment'. Also describes failure conditions (throws if below minScore or dead endpoint). However, no mention of when not to use this tool or alternatives like mainstreet_preflight.

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