mainstreet

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

With no annotations, the description carries full burden. It explains the mutual proof mechanism, the format of signatures, and the one-to-one mapping anti-sybil constraint. This adds valuable behavioral context beyond the parameter descriptions.

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 purpose. While concise, the second sentence is dense with technical details, slightly reducing readability. Still efficient overall.

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 core binding process but omits details like error handling, return values, or prerequisites. Given the tool's complexity (5 params, no output schema), it is adequate but leaves some 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 coverage is 60%, with nonce and address lacking descriptions. However, the description clarifies their roles by showing how they are used in the signing message, adding meaning beyond the schema. It compensates for the missing descriptions.

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

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

The description clearly states the tool's purpose: to bind a Gitlawb DID to a 0x wallet using mutual proof, enabling LAWBOR reputation attachment. It specifies the verb (bind) and resources (DID, wallet), and distinguishes from sibling tools by describing a unique operation.

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 binding DIDs but does not provide explicit guidance on when to use this tool versus alternatives among siblings. It mentions the anti-sybil constraint but lacks explicit 'use when' or 'use instead of' instructions.

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 bears full burden. It discloses reputation weighting, sybil resistance, seat deduplication, and the auto-pull mechanism. Does not mention any destructive behavior, but seems appropriate for a panel formation 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?

Three sentences cover the core mechanism, constraints, and flow. No fluff; every sentence adds critical information. Front-loaded with the main 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?

The description explains the process but does not specify the output format or return value, only mentioning it calls lawbor_quorum. Without an output schema, the agent might need to infer the result. Completeness is adequate but not 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%, but the description adds contextual meaning: explains the 'candidates' parameter's auto-pull behavior and the significance of 'minScore' as trust weight per seat. Provides more than just schema field descriptions.

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

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

The description clearly states it forms a reputation-weighted, sybil-deduped panel for quorum, specifies constraints like one wallet one seat, and describes the auto-pull and sequential calling of lawbor_quorum. It uses specific verbs and resource, distinguishing itself from 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?

The description implies its role as glue between routing and consensus but does not explicitly state when to use or when not to use, nor does it mention alternative tools. The auto-pull behavior is noted but 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?

No annotations provided, so description carries full burden. It explains the tool is self-documenting and lists what it returns (primitives, endpoints, formats, participation info). No side effects or destructive behavior is expected, and the description is transparent about its purpose.

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 wasted words. Front-loaded with the key purpose 'Self-documenting cold-start entry point.' Every sentence provides essential 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?

Given 0 parameters and no output schema, the description fully covers what the tool does and what it provides (primitives, endpoints, formats, participation info). It is complete for a discovery 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?

Tool has 0 parameters, and schema coverage is 100% (empty). Description adds value by explaining the tool's role as a cold-start entry point, which is more informative than the empty schema 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 clearly states it is a 'cold-start entry point for the LAWBOR network' that lists primitives, endpoints, message formats, and participation info. It directly addresses what the tool does and distinguishes itself from sibling operational 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 says 'Call this first if you have never interacted with LAWBOR,' providing clear when-to-use guidance. Does not explicitly mention when not to use, but the context implies it's only needed for first-time interaction.

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. It describes the core behavior (returns pass/quarantine based on trust floor) but does not disclose side effects, authorization requirements, or whether the tool is read-only. This is adequate but could be more comprehensive.

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 long, dense with meaning, and front-loaded with the tool's purpose. No extraneous 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 the tool's simplicity (two parameters, no output schema), the description covers the essential behavior and use case. However, it does not specify the exact output format (e.g., string, object), which would improve completeness. The sibling context helps situate it within a larger ecosystem.

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 both parameters with descriptions. The description adds context by mentioning the default value for minScore (30) and clarifying the role of agent as an upstream producer. Since schema coverage is 100%, this additional context justifies a score above 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's function: a trust firewall that returns pass/quarantine based on an upstream agent's trust score. It distinguishes itself from human-set thresholds, making it specific and unique among 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?

The description explains when to use the tool (pipeline stages requiring trust gating) and implies its role in automating trust-based decisions. However, it does not explicitly mention when not to use it or provide alternatives, which would further enhance 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, the description must fully disclose behavioral traits. It mentions BigInt-exact math and dust handling, but omits side effects (on-chain transaction?), error behavior (invalid signature), and permission requirements (likely token approval). This leaves the agent with significant unknowns for a signed transaction 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 a single sentence that packs essential info: action, token, constraints, and key parameter highlight. It is front-loaded and avoids redundancy. However, it could benefit from slight restructuring for 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?

Given 7 parameters, a signed transaction, and no output schema, the description is too brief. It lacks context on nonce usage, signature format, split recipient structure, and what the tool returns. The complexity demands richer 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 description coverage is 57% (4/7 parameters described). The description only reiterates the amountUsdcRaw meaning (already in schema) and adds no explanation for nonce, tipper, tippee, or signature purpose. It does not compensate for the missing schema descriptions.

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

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

The description clearly states the action ('send a signed USDC tip'), the resource ('an agent that helped you'), and key constraints ('self-tip forbidden', 'up to 5 splits'). This distinguishes it from siblings like lawbor_m1_send (likely for other tokens) and lawbor_m9_upvote (different reward mechanism).

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 tipping an agent for help, but does not explicitly contrast with sibling tools. No 'when not to use' guidance is provided. The self-tip rule is a constraint but not a usage guideline per se.

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 signing, nonce replay protection, and contentCid as a hash, but omits details on state changes, persistence, success/failure indicators, or any side effects. With no annotations, the description only partially covers transparency.

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

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

Three sentences front-loaded with the main purpose. Each sentence adds value; no fluff. Efficiently conveys key behavioral aspects.

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 simple send tool, but lacks information on error conditions, return value, or when to use this over other communication tools. Without annotations or output schema, more context would help.

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 83% and descriptions already explain parameters. The tool description adds little new meaning beyond restating schema hints (e.g., nonce prevents replay, contentCid is a hash), so it does not significantly compensate 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?

Clearly states 'send a signed direct message to another agent' with verb+resource. However, it does not differentiate from sibling tools like lawbor_m2_post or lawbor_m9_upvote, which involve different actions.

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 usage when a signed direct message is needed and explains the signing requirement, but provides no explicit guidance on when to use this tool versus alternatives 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?

No annotations are provided, so the description carries full burden. It reveals that the tool posts a task, optionally escrows USDC from a reward pool, and gates claimants by reputation. However, it does not disclose what happens on failure, authorization requirements, or side effects. The behavioral impact is partially described but lacks depth.

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 the core purpose and key options (escrow, reputation gating). There is no unnecessary 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?

With 8 parameters, no output schema, and no annotations, the description covers the main action and optional features. However, it omits details on how parameters like nonce, signature, and poster interplay, and it does not describe the return value or failure modes. Moderately complete but with notable 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 63%, so the baseline is 3. The description adds context like 'from the unified reward pool' for escrow, but the schema already describes 'raw integer (6 decimals)' and 'minimum claimant reputation'. No new parameter-level details are provided beyond what the schema offers.

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

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

The description clearly identifies the action ('post a signed task/bounty'), the target resource ('LAWBOR board'), and key optional features (escrow, reputation gating). It distinguishes itself from sibling tools by specifying 'M2' and the posting action, which is unique among the listed lawbor 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?

The description implies usage when a user has a signed task/bounty to post. However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks, such as lawbor_m1_send or lawbor_m10_tip.

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 key behaviors: self-upvote forbidden, upvoter must meet minimum reputation, diminishing returns, optional evidence anchoring. Lacks details on errors or side effects, but sufficient given no annotations.

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 with all essential information 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?

Provides enough context for a simple upvote action: action, constraints, optional param. Lacks output spec or error conditions, but acceptable for this 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?

Adds meaning by explaining linkCid anchors to evidence, but schema already describes some parameters. Does not cover nonce or signature beyond schema. Schema coverage is 50%.

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 the action: give a signed reputation star to another agent. Specifies verb, resource, and target. Differentiates from siblings with unique action.

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 constraints (self-upvote forbidden, reputation requirement, diminishing returns) but does not explicitly state when to use this tool vs alternatives 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, the description discloses that the tool retrieves neighbor connections and lists the types of relationships. It implies a read operation but does not mention side effects, which is acceptable for a data retrieval 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 succinct sentences: first defines the tool's function, second provides usage guidance. No extraneous information, perfectly front-loaded.

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 or annotations, the description covers purpose, usage, and data scope. It lacks details on return format or pagination, but for a simple graph query, it 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 single parameter 'address' is not explicitly described in text, but the context of 'agent' and the Ethereum address pattern in the schema make it clear. For 0% schema coverage, this is adequate but not exemplary.

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 graphs neighbors of an agent, listing specific interaction types (messaged, upvoted, tipped, endorsed) and reciprocals, which distinguishes it from sibling tools like lawbor_profile or lawbor_peer_trust.

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 advises using the tool to map an agent's working relationships before trusting it, providing clear usage context. It doesn't specify when not to use, but the guidance 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?

Without annotations, the description carries the full burden. It discloses the output format (trust-weighted quorum answer, confidence, trustedDissent, gate recommendation) and mentions Sybil-resistance and stake-weighting. However, it does not specify side effects (e.g., whether any data is stored) or potential destructive actions, which is acceptable for a likely read/aggregation 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 only two sentences, but the second sentence is dense and technical ('the Sybil-resistant, stake-weighted judge the multi-agent literature prescribes for the 17x error trap'), which may confuse the agent. It could be more concise and clearer without sacrificing 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?

The description explains the output format thoroughly, but it lacks details on error handling, what happens if no consensus is reached, or how trust weights are determined. Given the tool's complexity and no output schema, the description leaves some gaps that an intelligent agent might need.

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

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

Schema description coverage is 0%, and the description does not explain the three parameters ('task', 'minScore', 'submissions'). It only vaguely references 'agent answers' but fails to clarify the role of 'task' or 'minScore', leaving the agent to infer meaning from context 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 active verbs ('submit', 'get') and clearly defines the tool's purpose: aggregating 2-20 agent answers into a single actionable decision with quorum, confidence, dissent, and a gate recommendation. It distinguishes itself from siblings like 'lawbor_quorum' by emphasizing 'turnkey' and specific outputs.

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: when you need a stake-weighted quorum from multiple agents. It mentions the '17x error trap' to indicate suitability for error-prone multi-agent scenarios, but it does not explicitly exclude cases or name disjoint alternatives, leaving some ambiguity.

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 burden. It discloses return values and behavior for unbound DIDs (UNTRUSTED), which is the key behavioral trait. Missing details on side effects or prerequisites, but as a read-only query this is 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 sentences, zero wasted words. Front-loads the core purpose and return types, then adds usage guidance. Excellent brevity.

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 low complexity (single param, no output schema, no annotations) the description fully covers what the tool does, its return values, and special case (unbound DID). Could mention if it requires network access, but fine as is.

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 already covers the parameter with 100% description, but the description adds meaning by explaining the DID type (did:key Ed25519) and its role in the trust verdict, including the unbound mapping.

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?

Specific verb 'Trust verdict' with resource 'peer DID' and explicit return values (TRUST/NEUTRAL/UNTRUSTED). Clearly distinguishes from sibling tools like lawbor_repo_trust which likely deals with repos, not peer DIDs.

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 advises to 'Use it as an external prior before trusting a peer/replica', providing clear context for when to employ the tool. Does not mention alternatives but 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 are provided, so the description fully shoulders the burden of behavioral disclosure. It labels the tool as a 'read' operation and lists returned data, but fails to explicitly state that the operation is idempotent, has no side effects, or requires no special authentication. With zero annotations, more explicit safety and behavioral context is needed.

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. The first sentence lists key data points, and the second summarizes the tool's purpose as a one-call read. It is efficiently front-loaded and 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 the tool's simplicity (one required parameter, no output schema), the description provides sufficient context by naming the fields returned. However, it does not specify the response structure (e.g., JSON object) or whether the data is real-time or cached, leaving minor gaps for an agent to fully understand the 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?

The sole parameter 'address' has a regex pattern but no schema description (0% coverage). The description adds meaning by calling it an 'agent address' and implying it identifies an agent in the LAWBOR network. This compensates for the missing schema description, though it does not elaborate on the format beyond the 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 the tool provides a full LAWBOR profile for an agent address, listing specific data fields (reputation weight, stars, M1 messages, endorsements, tips, reward-pool standing). It distinguishes itself from siblings by being the one-call profile read, as no other sibling tool serves this comprehensive overview 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 provides no guidance on when to use this tool versus alternatives. It indicates it's a one-call read for agent identity in LAWBOR, but does not mention when not to use it or suggest other tools for more specific queries (e.g., lawbor_peer_trust for trust details). The lack of exclusions or context reduces usability for an AI agent deciding between 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 explains weighting by reputation, prevention of poisoning by low-rep agents, optional signature gates, and return of quorum answer, confidence, and weights. It is transparent but omits potential failure modes (e.g., unachievable quorum).

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 four sentences, front-loaded with the core purpose, and avoids unnecessary detail. It is efficient but slightly verbose with the '~17x' claim. No structural issues.

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 moderate complexity (nested submissions array, optional signature, no output schema), the description covers inputs and key behaviors but lacks detail on return format beyond names, potential errors, or confidence interpretation. Adequate but not comprehensive.

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. The description adds meaning by explaining the purpose of reputation weighting, the role of signatures in inclusion, and constraints like min/max submissions. This goes beyond the schema's basic types and requirements.

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 computes trust-weighted consensus over agent answers, explicitly using LAWBOR reputation to avoid compounding errors. It distinguishes itself from sibling tools like lawbor_council by focusing on weighted consensus rather than other operations.

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 multiple agent answers exist and one wants weighted consensus, but gives no explicit when-not-to-use guidance or alternatives among sibling tools. The mention of 'fix for ... trap' provides context but not exclusionary criteria.

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 burden. It states it aggregates from push/pr events but does not disclose side effects, authentication needs, rate limits, or whether it is a read-only operation. It gives enough for a simple query but lacks thoroughness.

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 wasted words. The first sentence conveys action, resource, and output; the second gives a concrete use case. Excellent front-loading.

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 lists the return values (trust levels and count). It covers the core functionality and use case, but is missing error handling or edge cases. Adequate for a tool of this 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?

The input schema has 0% description coverage, but the description adds meaning by explaining that 'owner' and 'name' refer to the Gitlawb repo. However, it does not provide formats, examples, or validation rules, so it only partially compensates.

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 aggregates contributor reputation for a Gitlawb repo, uses owner/name parameters, and returns TRUSTED/EMERGING/UNVERIFIED with a count. The use case 'pick a legit replica over a fresh name-squat' distinguishes it from sibling tools like lawbor_peer_trust.

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: 'Use to pick a legit replica over a fresh name-squat.' It provides clear context but does not mention when not to use or suggest alternatives, which would raise 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, the description fully discloses: advisory only, no money movement, ranking formula, and treatment of unbound DIDs.

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 with no fluff. Acronym defined, formula explained, constraints stated. Well-structured 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?

For an advisory ranking tool with no output schema, the description covers ranking logic, money movement disclaimer, and unbound DIDs. Complete and self-contained.

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

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

Schema description coverage is 50% per context; the description does not add detail beyond the schema for parameters. It provides context about bids but not specific parameter guidance.

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: Stake-weighted bid routing. It explains the ranking formula (reputation × bond / price) and distinguishes its advisory-only nature from the execution path.

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 (for ranking bids by SWBR) and when not to (doesn't move money; execute via operator path). Also covers unbound DIDs having weight 0.

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. It discloses the content of the report (verdict, neighbors, committer weight) and implies it is a read operation (scout report). However, it does not explicitly state that it is non-destructive, idempotent, or safe, nor does it mention any authorization requirements or rate limits. The transparency is adequate but could be more explicit.

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, each essential. The first sentence defines the tool's purpose and output, while the second explains parameter usage. There is no redundancy or unnecessary information, making it highly concise and front-loaded.

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 only 2 optional parameters and no output schema, the description covers all necessary aspects: what the tool does, what it returns, and how to invoke it in both modes. The absence of output schema is compensated by the clear list of return components (verdict + neighbors + committer weight). The description is fully complete for this low-complexity 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% with descriptions for both name and owner. The description adds value by explaining the conditional use: 'Pass owner+name for one repo, omit both for the global summary.' This clarifies the interplay between parameters beyond the schema's individual descriptions, making it easier for the agent to invoke correctly.

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 provides 'LAWBOR-side review verdicts on Gitlawb repos' including specific components (verdict, neighbors, committer weight). It distinguishes from siblings like lawbor_neighbors by being a composite report, and explains the two modes (single repo vs global summary) with explicit parameter usage.

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

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

The description gives explicit guidance on when to pass owner+name (for one repo) and when to omit both (for the global summary). This helps the agent decide how to use parameters. However, it does not explicitly mention when to prefer this tool over alternatives like lawbor_repo_trust or lawbor_neighbors, only implying it through the description of what it returns.

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 action (post), the signing scheme (EIP-191 with specific format), and the gated nature (reputation-gated). It does not cover failure modes or side effects, but the signature details are a strong addition.

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 fluff. The first sentence states action and result, the second provides protocol context. Could be slightly more structured (e.g., parameter list), but it is 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?

No output schema and no description of return values or errors. The signing specification is complete, but the tool lacks explanation of outcomes (e.g., what happens on success/failure) and authorization requirements beyond the signature. For a 6-parameter tool, more completeness is needed.

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

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

Schema coverage is 0%, so the description must compensate. It adds valuable semantics for the signature parameter by specifying the exact EIP-191 format. However, other parameters (nonce, reason, verdict, targetCid, validator) receive no description beyond schema names/patterns, leaving gaps.

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 posts a signed pass/fail validation on a deliverable (bytes32 CID) and explains its role as a building block before payout. It effectively distinguishes this posting action from sibling tools like lawbor_validations (which lists validations).

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 positions the tool as 'validator-before-payout building block' and mentions it is read by M11/M2 operators, giving clear context for when to use it. However, it does not explicitly state when not to use it or name alternatives like lawbor_validations for reading.

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 explains the read-only nature and enumerates the output contents (PASS/FAIL/CONTESTED, weights, per-validator verdicts). It lacks details on edge cases like missing CIDs or authorization 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?

The description is two sentences, front-loaded with the main action, and contains no unnecessary 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, the description adequately covers the return values. It provides enough context for a simple tool, though it could mention format or error handling.

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 does not directly explain the 'cid' parameter beyond the schema, but refers to it as a 'deliverable CID', adding context. With 0% schema coverage, more parameter detail would be beneficial.

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 'Read the reputation-weighted validation aggregate for a deliverable CID', specifying the verb and resource. It distinguishes itself from sibling tools like lawbor_validate by mentioning the aggregate and per-validator 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 advises 'Consult before accepting an agent deliverable', giving a clear usage context. However, it does not explicitly state when not to use or mention alternative 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 carries full burden. It explains the tool returns a shortlist based on filters, implying a read-only query operation. No side effects or additional behavior are disclosed, but the core behavior 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?

The description is a single sentence followed by a concise list of filters. Every part adds value, no redundancy, and the most important information is front-loaded.

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 absence of output schema and annotations, the description explains the tool's purpose and filters but does not specify the return format (e.g., what fields are returned per agent) or the effect of the 'limit' parameter, leaving some 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%. The description adds meaning to the 'filter' parameter by explaining each enum value, but the 'limit' parameter is not described at all, leaving it ambiguous.

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 a 'Curated shortlist of Base agents worth auditing' and lists three distinct filters (high-activity-low-trust, recent-newcomers, top-by-proofs), distinguishing it from sibling tools like mainstreet_catalog or mainstreet_score.

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 context for when to use each filter (e.g., 'risky, audit recommended' for high-activity-low-trust), but does not explicitly state when not to use this tool or compare it to 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?

Describes what it returns (signed payload, domain, types, signer) and how it can be verified. No annotations provided, but description covers core behavior. Lacks details on error handling or access 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, front-loaded with key action, no wasted words. Efficiently conveys purpose and usage.

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, usage, and return format. Missing details on address format and error conditions. Given simplicity, nearly 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?

With 0% schema description coverage, the description adds minimal parameter info: only mentions 'for an address' without specifying format or validation. Adequate but could be improved.

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 'Get EIP-712 signed attestation' with specific resource 'cryptographic proof of score' and distinguishes from siblings by mentioning on-chain 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?

Explicitly says 'Use when you need oracle-grade trust, not just an HTTP read', providing clear guidance on when to use 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?

Although no annotations are provided, the description discloses key behavioral traits: it calls a premium endpoint costing $0.25 USDC via x402, and returns a URL and instructions. This gives the agent a clear picture of the tool's cost and non-destructive nature.

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 immediately conveys the core purpose and key details (cost, endpoint, use case). No extraneous information 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?

Given the tool has only one parameter and no output schema, the description adequately covers its function and context. It explains the purpose and cost, but does not describe the response format or potential error conditions, which would add 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 sole parameter 'address' has no description in the schema (0% coverage). The description adds that it is a wallet address for due-diligence, but does not specify format, network, or validation rules. This provides minimal additional meaning beyond the parameter name.

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: getting a URL and instructions for a premium audit endpoint. The verb 'Get' and resource 'URL + instructions' are specific, and the context of 'full due-diligence on a wallet before paying it onchain' distinguishes it from 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?

The description explicitly states when to use the tool ('before paying it onchain'), providing clear usage context. However, it does not mention when not to use it or list alternative tools for similar tasks, such as mainstreet_vet or mainstreet_preflight.

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 explains return fields (washRisk, rankScore) and sort behavior but does not disclose whether the tool is read-only, destructive, or has any side effects, permissions, or rate limits.

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

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

The description is concise (four sentences) and front-loaded with purpose. Every sentence adds value, though some details could be more structured (e.g., listing parameters explicitly).

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 5 parameters and no output schema or annotations, the description covers purpose, return values, and sort behavior. However, it lacks details on pagination (limit), exclusion behavior (excludeUnscored), and the exact influence of minScore. Somewhat complete but with notable omissions.

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

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

Schema coverage is 0%, so the description must compensate. It explains 'sort' (with enum details) and implies 'network' and 'minScore' via 'Filterable by network + minimum trust.' However, 'limit' and 'excludeUnscored' are not described, leaving gaps.

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 as a safer alternative to CDP Bazaar discovery, returning scored agents with trust metrics. It distinguishes from 'raw Bazaar' but does not explicitly differentiate from sibling tools like mainstreet_score or mainstreet_catalog.

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 sybil-aware agent discovery and mentions filtering by network and minimum trust. However, it does not provide explicit guidance on when to use this tool vs. siblings, nor does it state 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?

No annotations provided, but the description fully discloses behavior: listing endpoints with pricing. No side effects 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?

Single sentence, front-loaded, zero waste. 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 simple catalog tool with no parameters or output schema, the description adequately covers purpose and 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?

No parameters exist, so baseline score of 4 applies. Description adds no param info because none 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?

The description clearly states the tool lists all MainStreet API endpoints, distinguishing it from sibling tools that are specific 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?

Explicitly says to use to discover capabilities, providing clear context. No exclusion or alternative mentioned, but not necessary given the tool's nature.

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 describes the detection algorithm and output, but does not explicitly state whether the tool is read-only or has any side effects. The inference is that it is a scanning/analysis tool, but not explicitly clarified.

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, each serving a distinct purpose: defining the tool, explaining detection logic, and providing limitations/pairing advice. No wasted words, efficient and well-structured.

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 partially compensates by detailing the detection logic and output format (risk level + cluster). However, it fails to explain the input parameter, which is essential for correct invocation. The pairing advice adds value but the overall completeness is only average.

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% for the single parameter 'address'. The description does not explain what the address represents (e.g., user address, contract, etc.), leaving the agent to guess. This is a critical 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 detects reciprocal flow patterns in the settlement graph to identify collusion, returning a risk level and cluster. It distinguishes itself from the sibling mainstreet_repeat_rate by noting it lacks escrow/dispute layers. However, the term 'radar' is somewhat metaphorical, so not a perfect 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?

Explicitly states when to use (detect collusion) and when not to rely solely (lacks escrow/dispute layers), and recommends pairing with mainstreet_repeat_rate. Provides clear context and an alternative.

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 does not mention side effects, permissions, rate limits, or what happens if agents are invalid or missing. This is insufficient for a tool with no annotation support.

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, dense sentence with no wasted words. It is front-loaded with the key action and outcome.

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 two-parameter tool, the description is adequate but incomplete. It lacks information about the return format, what metrics are compared, and error handling. With no output schema, the description should provide more 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 description adds minimal meaning beyond the input schema: it states parameters are agents to compare. However, it does not explain the format (address regex) or that they are required, nor does it describe the metrics returned. With 0% schema description coverage, more detail is 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?

The description clearly states the tool compares two agents head-to-head with side-by-side metrics. The verb 'compare' and resource 'agents' are specific and distinguish it from siblings like mainstreet_score (single agent) and mainstreet_match (possible matching).

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 does not explicitly provide when to use this tool versus alternatives. While the name and description imply it is for comparing two agents, no exclusionary guidance or context is given for 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, the description bears full burden. It explains what the tool does, returns (score, verdict, assessment, launch history), and discloses scoring factors (survival rate, LP, platform diversity, etc.). No side effects mentioned, but mutation is not expected.

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 fairly concise given the detail it conveys. It front-loads the main purpose and returns. A few redundant phrases could be trimmed, but overall it is 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?

Given no output schema, the description adequately explains return values (score, verdict, assessment, launch history) and scoring factors. It is complete enough for the agent to decide whether to use the tool and understand 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?

Schema description coverage is 100%: the 'address' parameter has a description, regex, and is required. The description adds value by specifying 'on Base' and the usage context, which helps the agent understand the parameter's role 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 and returns score, verdict, assessment, and launch history. It positions itself for evaluating tokens before investing, distinguishing it from sibling tools like mainstreet_score which probably evaluate tokens directly.

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 'Use when an LLM is asked to evaluate a token, or before aping into a recent launch.' This provides clear context. It does not mention when not to use or list alternatives, but the use case is well-defined.

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 behavioral burden. It discloses weighting by reviewer reputation, exclusion of self-reviews, and the inflation delta metric. However, it does not state that this is a read-only operation or mention any permissions or 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?

The description is a single sentence that efficiently conveys the core purpose and outputs, though the phrasing is somewhat dense. It is concise and front-loaded with the essential verb.

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

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

Given the tool's complexity (weighted scoring, inflation delta) and lack of output schema, the description omits return structure details and how to interpret inflationDelta. It also does not explain the address parameter's input requirements beyond the schema regex.

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 'address' is not explained in the description; its role (likely the contract or subject address) must be inferred from context. With 0% schema description coverage, the description should add meaning but fails to do so for the 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 it computes a reviewer-reputation-weighted ERC-8004 feedback score, detailing sybil resistance and the specific outputs (rawAvg, weightedRating, inflationDelta). This differentiates it from sibling scoring tools like mainstreet_score (likely unweighted) and mainstreet_scores_batch.

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

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

The description implies usage for weighted, sybil-resistant scores but does not explicitly specify when to use this tool versus alternatives like mainstreet_score or mainstreet_collusion. No direct when-not-to-use 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?

Without annotations, the description carries full burden but only reveals that results are paginated and that omitting 'type' lists platforms and counts. It does not disclose rate limits, authentication, or error behavior. This is adequate but not thorough.

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 three sentences, each adding distinct value: main purpose, return format, and usage tips. No unnecessary words 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?

Given the tool's simplicity, the description covers the main points: what it does, how to use the 'type' parameter, and its use case for pre-filtering. However, it does not specify the response structure (e.g., fields in the paginated list), which would be helpful for an agent without an output schema.

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 for the 'type' parameter by explaining that omitting it lists available platforms and counts, which is beyond schema. For 'limit' and 'offset', no extra meaning is added.

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 discover Base wallets verified by external identity platforms. It specifies the resource (verified wallets) and action (discover), and lists examples (Virtuals, Farcaster, etc.). This distinguishes it from siblings like mainstreet_verify, which likely handles verification rather than discovery.

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: call without 'type' to see available platforms and counts, and use to pre-filter before scoring. It implies context but does not explicitly exclude alternatives or mention when not to use.

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 the description must fully disclose behavioral traits. It does not mention read-only nature, pagination, ordering (e.g., descending by score), or any side effects. The description is minimal and fails to reveal basic behavioral context beyond the action itself.

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. No wasted words. The first sentence states action and scope, the second gives usage guidance. Highly concise and well-structured.

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 (2 optional params, no output schema). The description is adequate for basic usage but does not explain what constitutes a 'score', the return format, or any edge cases. For a leaderboard tool, slightly more detail on output would 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?

Schema coverage is 100% with descriptions for both parameters (limit and network). The description adds no additional meaning beyond 'top-scored'; it does not explain how limit affects results or what networks are valid. Baseline 3 is appropriate as schema already explains the 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 clearly states it lists top-scored onchain AI agents on Base, using a specific verb ('list') and resource ('top-scored agents'). It distinguishes from siblings like mainstreet_score (which likely shows score for a single agent) by focusing on a leaderboard, but does not explicitly differentiate from other discovery tools like mainstreet_bazaar_scored.

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 usage scenarios: 'when the user asks 'who is best at X' or wants discovery without a specific intent.' This gives clear context for when to invoke, though it does not mention when not to use or suggest alternative tools among the many 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?

No annotations are provided, so the description carries the full burden. It describes what the tool returns but does not disclose whether it has side effects, authentication needs, rate limits, or if it is read-only. For a search tool, this is a minor gap, but without annotations it should be more explicit.

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 consists of two sentences: the first states purpose and output, the second gives usage guidance. It is concise, front-loaded, and contains no unnecessary 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 tool has no output schema, the description adequately covers the return format (ranked matches with specific fields) and usage context. It does not explain the matching algorithm or how 'natural-language intent' is interpreted, but this is sufficient for a search tool with clear 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?

Input schema coverage is 100%, so the schema already documents all parameters. The description adds no new information beyond what is in the schema, meeting the baseline expectation. No extra value is provided.

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 finds onchain AI agents on Base matching natural-language intent and lists returned fields. It distinguishes itself from many sibling tools by focusing on natural-language matching and live reputation, but lacks explicit differentiation from similar search tools like mainstreet_bazaar_scored or mainstreet_catalog.

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

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

The description gives explicit usage guidance: 'Use BEFORE paying an x402 endpoint.' This provides clear context for when to invoke this tool. However, it does not mention when not to use it or specify 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?

The description explicitly states the tool is read-only and never executes a trade, which is crucial for behavioral transparency. It details the output components (classification, GoPlus, DefiLlama, GeckoTerminal, consensus, verdict, tradeSafety gate). However, without annotations, it could further clarify any potential side effects or limitations like data freshness.

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 detailed but front-loaded with the main purpose and key outputs. It uses a few long sentences that pack information efficiently. While slightly dense, it avoids unnecessary fluff and remains understandable.

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 of aggregating multiple data sources, the description covers the main return fields comprehensively: classification, evidence from GoPlus, DefiLlama, GeckoTerminal, price consensus, verdict, and tradeSafety gate. With no output schema, it provides sufficient context for an agent to understand 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 only parameter (address) is fully described in the schema with a pattern and description. The description adds 'Base token' context which is already present in the schema description. Schema coverage is 100%, so the description adds no significant new meaning, earning a baseline 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's purpose: providing read-only onchain intelligence for any Base token, returning a one-word classification (SAFE/WATCH/AVOID/UNKNOWN) along with evidence from multiple sources. It distinguishes itself from siblings by focusing on token classification rather than other agent-related functionalities.

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 classifying token safety without specifying when to use alternatives. It mentions avoiding multiple API calls but does not explicitly state when not to use this tool or compare it to siblings. More explicit guidance would improve clarity.

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 fully disclose behavioral traits. It only lists return fields but omits details on authentication, rate limits, selection logic, failure scenarios, or potential side effects, 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 concise with two sentences that front-load the main purpose. It is well-structured and easy to parse, though it could be slightly more informative without sacrificing brevity.

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 and no output schema, the description is too brief. It lacks critical context such as selection criteria, behavior when no agent matches, error handling, and return format, making it incomplete for reliable agent 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 description coverage is only 17%, yet the description adds no explanations for parameters like maxPrice, minScore, onlyVerified, or onlyRegistered. The description mentions 'intent' but does not compensate for the lack of schema descriptions for the other five 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 clearly states the tool picks the single best agent for an intent in one call and lists the returned fields. It is specific about the verb and resource, but lacks explicit differentiation from sibling tools like mainstreet_compare 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 includes a usage guideline ('Use when you want to act immediately.') but does not specify when not to use the tool or mention alternative tools, leaving the agent without comprehensive decision support.

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 return fields (decision, verdict, score, reasoning, SLA/health) and performance (<100ms). No annotations exist, so no contradiction; description provides adequate behavioral context.

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

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

Three sentences, each valuable. First defines purpose, second what it returns, third usage. Front-loaded and 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?

With one required parameter and no output schema, the description covers purpose, output structure, performance, and usage guideline. Complete for a simple check 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 has 0% description coverage. Description implies 'address' is the counterparty's wallet/agent/token, but does not explicitly define format or constraints. 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?

The description clearly states the tool as 'THE pre-payment trust check' for verifying counterparties before paying USDC over x402. It uniquely identifies its role among siblings, none of which overlap.

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 instructs to call before settling USDC and to refuse on BLOCK verdict. Does not mention when not to use or alternatives, but context is sufficient for decision.

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 self-pay is flagged, implying exclusion of self-payments. However, it lacks details on edge cases, data freshness, or error conditions, which would improve 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 concise sentences, front-loaded with the signal name and explanation. No unnecessary words; 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?

For a simple, single-parameter tool, the description is fairly complete: it explains the metric, mentions self-pay flagging, and gives usage advice. Lack of output schema is acceptable as return type is implied.

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 singular parameter 'address' is described in schema as 'Payee address.' The description adds context about the address being the payee for which the repeat rate is computed, but schema coverage is 100%, 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 defines the tool as computing the 'repeat rate' of payers returning for a second+ settlement. It uses a specific verb ('share of distinct payers') and resource ('x402 settlement to this payee'), and distinguishes from siblings by mentioning use with mainstreet_score.

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 to use alongside mainstreet_score to separate real demand from wash activity. This provides a clear usage context, though it doesn't discuss when not 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 must convey behavior. It states 'live' and 'onchain settlements', implying a read-only, transparent data retrieval. However, it does not disclose any potential side effects, cost, or access restrictions, which leaves 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?

Two concise sentences: the first defines the tool's output and its onchain provenance, the second states its utility. No redundancy or extraneous information; every word serves a 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 no parameters and no output schema, the description provides enough context about what the tool returns and why it matters. It lacks details like update frequency or data format, but it is sufficient for an agent to understand its role.

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 schema coverage is 100% by default. The description adds value by explaining the output content (revenue stats, settlements) and its significance, meeting the baseline expectation for a parameterless tool.

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

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

The description clearly states it provides live revenue stats for MainStreet using onchain x402 settlements, and its purpose is to assess oracle credibility. It distinguishes the tool's output but does not explicitly differentiate from siblings, though the unique focus on revenue stats is clear.

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

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

The description gives a use case ('useful to assess oracle credibility') but lacks explicit guidance on when to use vs. not, and no alternatives are mentioned. The context of evaluating oracle reliability is implied but not expanded.

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

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

The description discloses that it is a read operation ('Read live reputation score') and specifies the returned data. Since annotations are absent, the description adequately covers behavioral traits without contradiction.

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: first states purpose and scope, second lists return fields. 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 simple read tool with no output schema, the description includes the return fields and network context. It is complete enough for an agent to understand what to expect, though it could mention update frequency.

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 the single parameter ('Agent address.'), but the description adds context: 'on Base' (network) and enumerates return fields, which adds meaning 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 reads a live reputation score for a specific agent address on Base, listing specific return fields. This distinguishes it from sibling tools like mainstreet_scores_batch or mainstreet_compare.

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 getting a single score but does not explicitly state when to use it vs. alternatives like batch scoring or comparison tools. No exclusion criteria or conditions are 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?

No annotations provided, so description carries burden. It describes return fields but does not mention side effects, permissions, or rate limits. As a read-only lookup, this is adequate but not fully 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, front-loaded with primary function, no wasted words. 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?

For a simple batch lookup with one parameter and no output schema, the description is complete: explains purpose, batch size, return fields, and pairing recommendation. Could add error handling but not essential.

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 parameter description for addresses. Description adds value by specifying the batch limit of 200 and listing return fields, but does not explain address uniqueness or validation beyond 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?

Clearly states it's a batch score lookup for up to 200 addresses, specifies returned fields (agentScore, deployerScore, proofCount, hasAnyTrust), and distinguishes from sibling tools like mainstreet_score by highlighting batch capability.

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 pairs with mainstreet_find_verified for a two-call discovery workflow, giving clear when-to-use context. Also implies not to use for single addresses (use mainstreet_score 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?

With no annotations, the description fully discloses behavior: returns endpoints, explains x402 payment (gasless, EIP-3009), and clarifies that MainStreet does not proxy or charge. This is comprehensive.

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 5-6 sentences, informative but slightly verbose. It front-loads the purpose and uses clear structure. Could be tighter, but still effective.

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 covers all necessary context: purpose, usage timing, behavioral details, and endpoints. Nothing important is missing.

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

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

Schema coverage is 100% (pattern and description), so baseline is 3. The description adds value by explaining the parameter as 'prefills a ready-to-call URL,' which clarifies its purpose 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 that the tool provides the momentum layer (xsignal) for vetted tokens, returning specific endpoints. It distinguishes from siblings like mainstreet_onchain_info by contrasting safety vs. momentum.

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 'Use after a SAFE/WATCH verdict to decide whether to actually enter.' This provides clear when-to-use guidance. It lacks explicit when-not-to-use but implies it via xsignal's abstention behavior.

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 convey behavior. It indicates the tool lists top spenders and mentions a time window, but does not disclose authentication needs, output format, or any side effects. 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?

Description is two sentences with no fluff. First sentence states the core functionality, second adds use case context. Highly concise and well-structured.

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 or annotations, the description provides a clear purpose and use cases but lacks details on output structure, prerequisites, and comparisons to similar tools. Adequate but not 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 0%, so description should explain parameters. It indirectly references sinceDays ('last N days') but does not explain the limit parameter or mention that both parameters are optional. Insufficient parameter guidance.

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 wallets that have spent the most via x402 on Base in last N days, with a specific verb and resource. It distinguishes itself from siblings like mainstreet_leaderboard by focusing on spending via x402.

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 usefulness for prospecting and checking rank, but does not explicitly state when to use this tool versus alternatives like mainstreet_leaderboard or mainstreet_revenue. No exclusion criteria or alternatives 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 discloses the behavioral nuance: higher rank means rating many distinct agents and those agents having healthy scores (implicit quality adjustment). This adds beyond the simple 'top raters' label.

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, no fluff, front-loaded with main action. Efficient and to the point with clear explanation in the last 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 one optional parameter and no output schema, the description explains what the tool returns (top peer-rating agents) and the ranking logic. It lacks explicit return format, but for a simple list of wallets, it 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?

Only one parameter (limit) with 100% schema coverage. The description does not add additional meaning beyond the schema's 'Max results (default 20).' Baseline 3 is appropriate since schema already documents it adequately.

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 top peer-rating agents, defines them as wallets that produce ratings via receipts, and explains the ranking logic (rates many distinct agents with healthy scores). This distinguishes it from siblings like mainstreet_top_buyers 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 implicitly tells when to use: to get top raters based on rating production and quality. No explicit when-not or alternatives, but the context is clear enough given sibling names.

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 the description carries full burden. It lists the exact return fields (valid, signerMatch, recovered, fresh, score, passesThreshold) and discloses the verifications performed (freshness, operator match, min score).

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 only two sentences. It front-loads the core purpose, then adds usage guidance and return format. No unnecessary 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 3 parameters, no output schema, and no annotations, the description covers purpose, usage, and output. However, the payload parameter lacks structural detail, which is a notable gap for an object parameter.

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%. The description mentions payload and signature as required, and minScore as optional. However, it does not explain the structure of the payload object, which is a nested object with unknown properties. This leaves ambiguity for the AI agent.

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 verifies a MainStreet EIP-712 signed attestation, recovers the signer, checks freshness and operator match, and enforces a minimum score. It is distinct from sibling tools like mainstreet_attestation or mainstreet_validate.

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 using it to trust a verdict from another agent without re-fetching, providing clear context. It lacks mention of when not to use it or alternatives, but the guidance is specific and helpful.

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 carries full burden. It discloses the verification behavior and limitations of the result, which is sufficient for a read-only verification 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?

Three sentences: purpose, context, usage. Front-loaded and every sentence adds value with no waste.

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

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

For a verification tool with fully described parameters and no output schema, the description adequately covers purpose, usage context, and interpretation of 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?

Schema description coverage is 100%, so baseline is 3. The description adds minimal value ('to cross-check') beyond restating required/optional 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 clearly states the specific verb 'verify' and resource 'x402 settlement', distinguishing it from siblings like mainstreet_verify and mainstreet_vet by focusing on cross-layer settlement confirmation.

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 when to use (when a facilitator claims settlement) and provides interpretation guidance ('Absence = not in coverage, not proof of fraud'), though it does not explicitly exclude 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?

Describes that the tool throws if score is below minScore or endpoint is dead. No annotations are present, so the description carries full burden; it adequately discloses the main behavioral traits without covering edge cases or 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?

Three concise sentences; the first states the core purpose, the second adds behavioral consequence, the third provides a direct usage instruction. Every sentence is meaningful and 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 simple gate-check tool with 3 parameters and no output schema, the description covers the core logic (reputation threshold, alive check, exception behavior) and usage context. It does not describe the return value on success, but that is not critical for such a 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 67% (minScore and requireAlive have descriptions). Description adds context linking minScore to 'minimum reputation' and requireAlive to 'alive gate', but does not elaborate on address format beyond schema. Baseline of 3 is appropriate as the description adds some value but is not essential.

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 vets an agent for reputation and alive status before payment. It uses specific verb 'Vet' and distinguishes itself from sibling tools focused on other actions like scores, matches, or signals.

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 says 'Always call BEFORE x402 payment', providing clear when-to-use context. Does not specify when not to use or mention alternatives, but the instruction is strong enough for safe invocation.

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