mainstreet

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

Discloses the mutual proof mechanism and signature formats, but lacks critical behavioral details such as what happens if the DID is already bound, whether the operation is idempotent, and any authentication requirements. No annotations provided, so the description carries the full burden but falls short of full transparency.

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

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

The description is very concise, using a single sentence to convey the main action and a second to detail the signatures. No redundant words; key constraints are 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?

Covers the core mechanism but omits important contextual details: no output schema, no error handling, no prerequisites (e.g., need for a DID and wallet). For a tool with 5 required parameters and no output schema, the description is adequate but not fully complete for an AI agent to use without additional knowledge.

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 beyond the schema by explaining the signature strings for didSig and walletSig. However, the nonce parameter is only mentioned in context without explaining its origin or constraints. With 60% schema coverage, the description compensates partially but leaves a gap for the nonce.

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: 'Bind a Gitlawb DID to a 0x wallet via MUTUAL proof'. It specifies the purpose of attaching LAWBOR reputation and the anti-sybil constraint, distinguishing it from sibling tools like lawbor_profile or lawbor_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?

No guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., having a DID or wallet), nor when not to use it. The sibling tools list includes similar reputation-related actions, but the description lacks context for decision-making.

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

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

With no annotations, the description carries the full burden. It discloses reputation-weighting, sybil deduplication, auto-pull behavior, and that it collects answers and calls quorum. Missing details on error handling or return format, but otherwise transparent.

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

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

Two sentences that are front-loaded with the main purpose. Each sentence adds value without redundancy. 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?

Description covers core behavior well but lacks information on what the tool returns (no output schema) and any prerequisites (e.g., trust scores must exist). It mentions calling lawbor_quorum internally, which is helpful. Minor gaps given complexity.

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

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

Schema coverage is 100% with basic descriptions, but the description adds significant meaning: explains that omitting candidates triggers auto-pull of top trusted set, clarifies 'one wallet one seat' for deduplication, and outlines the overall workflow of collecting panelist answers and invoking lawbor_quorum.

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 forms a reputation-weighted, sybil-deduped panel of K agents to run a quorum. It specifies unique behavior (one wallet one seat, auto-pull top trusted) and mentions the subsequent call to lawbor_quorum. This distinguishes it from siblings like lawbor_quorum and lawbor_scout.

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?

Context is provided: 'glue between routing and consensus', and behavior when no candidates are provided. However, it does not explicitly state when to use this tool versus alternatives (e.g., lawbor_validate for single agent opinion) 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 provided, but description is self-documenting and lists contents; does not disclose safety, side effects, or auth requirements. Adequately describes behavior for a read-only discovery tool.

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

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

Two sentences, front-loads key purpose and usage, no redundant 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 parameters, no output schema, and no annotations, the description fully covers the tool's purpose and usage 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?

No parameters, so baseline score of 4 per guidelines. Description adds no parameter info, but 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 it is a cold-start entry point that lists all primitives, live endpoints, message formats, and participation info, distinguishing it from sibling tools that have specific 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?

Explicitly says 'Call this first if you have never interacted with LAWBOR,' providing clear context for when to use, though no exclusions or alternatives are mentioned.

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 clarifies the decision logic (pass vs. quarantine based on earned trust) and indicates no destructive behavior. It is transparent about the outcome but does not mention side effects or error handling.

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

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

The description is two sentences, front-loaded with a clear metaphor and no filler. Every sentence adds value, making it highly efficient and easy to parse.

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

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

The description explains the binary outcome (pass/quarantine) but does not specify the exact return format or structure. With no output schema, this omission means the agent may not know how to interpret the result. It otherwise covers core functionality adequately.

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

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

Schema coverage is 100%, and the description adds context beyond the schema by explaining the 'minScore' as an earned-trust floor and the agent as upstream producer. This enriches understanding of how parameters function in the pipeline context.

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 'Trust firewall between pipeline stages' and explains the core function: given an agent and minScore, returns pass/quarantine. It distinguishes from sibling tools like lawbor_peer_trust or lawbor_validate by focusing on pipeline gating behavior.

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 use cases (quarantine low-trust agent outputs) and replaces a manual confidence threshold. However, it does not explicitly state when not to use this tool or mention alternatives, though sibling context provides some differentiation.

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

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

With no annotations, description reveals key traits: mathematical exactness, dust handling, raw integer decimals, self-tip prohibition, and signature requirement. Provides sufficient behavioral context beyond schema.

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

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

Two concise sentences, front-loaded with the tool identifier and action, no fluff. 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?

Covers core purpose, critical behavioral notes, and key parameters. Missing explanation of nonce and helpedCid, and no mention of return value, but given the tool's focused nature, it is largely sufficient.

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

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

Schema coverage is 57%, so baseline is 3. Description adds meaning for 'amountUsdcRaw' (raw 6-decimals integer) and 'splits' (dust handling), but does not explain nonce, signature format beyond what schema already describes.

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 'send a signed USDC tip to an agent' with specific details like 'BigInt-exact math, dust goes to the tippee' and 'Self-tip forbidden', distinguishing it from siblings such as lawbor_m1_send and others.

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 implies when to use (tipping an agent that helped you) and states 'Self-tip forbidden', but does not explicitly compare to similar tools or provide exclusionary guidance. Clear context but no 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 discloses key behavioral traits: the calling agent must sign the payload with their own key, a nonce prevents replay attacks, and contentCid is a hash. This goes beyond the schema, which only describes parameter formats. However, it does not mention potential side effects, costs, or whether the message is stored permanently or ephemerally.

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

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

The description is extremely concise, consisting of two sentences that cover the core purpose and key technical details. No superfluous information is included, making it easy for an agent to quickly grasp the tool's function.

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

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

The description covers the essential sending mechanism and cryptographic details. However, it lacks information on what happens after sending (e.g., confirmation, return value, persistence). With no output schema, the agent is left uncertain about the tool's behavior beyond invocation.

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

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

Schema description coverage is high (83%), so the schema already documents most parameters. The description primarily reiterates the schema's explanation of contentCid and adds context about signing, but does not significantly enhance parameter understanding beyond what is already available. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose as sending a signed direct message to another agent. The verb 'send' and resource 'signed direct message' are specific. It does not explicitly differentiate from sibling messaging tools like lawbor_m2_post, but the context of signing and direct messaging provides some distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or cases where a different tool would be more appropriate. This omission forces the agent to infer usage from the tool's name and purpose.

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

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

With no annotations, the description carries full burden. It discloses optional escrow and reputation gating, but lacks detail on side effects, required permissions, or return behavior. Provides moderate transparency beyond the schema.

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

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

The description is a single sentence that efficiently conveys the core functionality with no redundant words. It is appropriately sized 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?

Despite moderate complexity (8 parameters, no output schema), the description does not explain the signature scheme, nonce role, or success/error handling. It lacks completeness for reliable agent invocation.

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

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

The description adds some context (e.g., 'raw 6-decimals integer', 'from the unified reward pool') to parameters like 'escrowUsdcRaw' and 'requiredRep', but largely repeats schema descriptions. Given 63% schema coverage, the added value is moderate.

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: posting a signed task/bounty to the LAWBOR board with optional USDC escrow and reputation gating. It uses specific verbs and resources, distinguishing it from sibling tools like 'lawbor_m1_send' or 'lawbor_m10_tip'.

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

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage from context alone.

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

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

Annotations are absent, so the description must fully disclose behavior. It reveals key constraints (no self-upvote, reputation threshold, diminishing returns, optional evidence anchoring). However, it does not specify the outcome (e.g., transaction hash), error conditions, irreversibility, or the effect on the upvoter's reputation. The phrase 'diminishing returns per upvoter' is ambiguous (does it affect star value or upvoter influence?).

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, concise and front-loaded with the core action. No superfluous words. Every sentence adds necessary context: purpose, constraints, and optional parameter role.

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 or annotations exist, so the description must compensate. It explains the action and some constraints but omits expected return values (e.g., success/error), the role of 'nonce' (replay protection?), and how the signature is validated. For a 6-parameter tool with a signature, the description is incomplete for an agent to invoke correctly without external knowledge.

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% (3 of 6 parameters have descriptions). The description adds meaning for 'linkCid' ('anchors the star to evidence') and implicitly for 'upvoter' and 'target' via the 'self-upvote forbidden' constraint. However, 'nonce', 'reason', and 'signature' are not explained beyond the schema. The description compensates moderately but does not cover all parameters 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 the action: give a signed reputation star to another agent. It distinguishes from self-upvote and specifies constraints (reputation threshold, diminishing returns). The verb 'give' and resource 'signed reputation star' are precise, and sibling tools like lawbor_m10_tip or lawbor_m2_post are distinct in 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?

Implicit guidelines are provided: self-upvote forbidden, upvoter must meet reputation minimum, diminishing returns apply. No explicit alternatives mentioned, but the constraints help an agent decide when to invoke this tool. For a reputation system, these conditions are crucial and well-stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It lacks any mention of side effects, read-only nature, permissions, or rate limits. While it describes the relationships included, it does not warn about potential absence of data or other behavioral traits.

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 defines the function, and the second provides usage guidance. This is highly concise and appropriately sized for a simple tool with one parameter.

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 lack of output schema and annotations, the description gives a reasonable overview of what the tool does and when to use it. However, it does not describe the output format, pagination, or any limits, which would be helpful for 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' is not explained in the description beyond its presence in the schema. With 0% schema description coverage, the description should clarify that the parameter is an Ethereum address or agent identifier, but it does not add meaning beyond the schema's pattern.

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

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

The description clearly states the tool's purpose: retrieving graph neighbors of an agent in the LAWBOR network, detailing the types of relationships (messaged, upvoted, tipped, endorsed, and reciprocals). It distinguishes well from sibling tools that focus on individual 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?

The description provides clear context for when to use the tool: 'before trusting it' to map an agent's working relationships. However, it does not explicitly mention when not to use it or list alternatives among sibling tools, leaving some room for improvement.

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

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

With no annotations provided, the description carries the full burden. It discloses behavioral traits: the tool returns a trust-weighted quorum answer, confidence, trustedDissent, and a recommendation (PROCEED/REVIEW/REJECT_RESAMPLE). It also mentions Sybil resistance and stake-weighting. However, it does not discuss side effects, permissions, or idempotency.

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 but dense with jargon (e.g., '17x error trap'). The first sentence front-loads the purpose, but the second sentence is somewhat redundant. While not overly long, the structure could be clearer and more accessible.

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 (nested objects, 3 parameters, no output schema), the description is incomplete. It does not explain the 'task' and 'minScore' parameters, and it lacks details on output format, error handling, or preconditions. The description covers only the high-level behavior.

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

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

Schema description coverage is 0%, so the description should compensate. It only references 'submissions' indirectly by mentioning 'submit 2-20 agent answers', but it does not explain the 'task' or 'minScore' parameters. Thus, it adds no significant 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 the tool's function: submitting 2-20 agent answers to get a trust-weighted quorum decision with confidence, dissent, and a go/no-go gate. It distinguishes from siblings like 'lawbor_quorum' and 'lawbor_gate' by emphasizing the combined orchestration and Sybil resistance.

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

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

The description implies when to use the tool (when you have multiple agent answers and need a consolidated decision) but does not explicitly state when not to use it or mention alternative tools like 'lawbor_quorum' or 'lawbor_gate'. No exclusions or alternatives 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 are provided, so the description bears full responsibility. It discloses that the tool returns a trust verdict (TRUST/NEUTRAL/UNTRUSTED) and describes the edge case of unbound DIDs yielding UNTRUSTED. This is transparent about the query's behavior.

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

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

The description is concise, two sentences long, and front-loads the core purpose. Every clause adds value with no redundant information.

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

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

Given the tool's simplicity (one parameter, no output schema), the description fully explains what it does, what it returns, and a key edge case (unbound DID). It is complete for an agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100% with a single parameter 'did' described as 'did:key:z6Mk… (Ed25519).' The description adds little beyond the schema, merely repeating that it's for a peer DID. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a trust verdict for a Gitlawb peer DID, with specific possible values (TRUST/NEUTRAL/UNTRUSTED). It distinguishes from sibling tools like lawbor_repo_trust and lawbor_bind_did by focusing on peer trust based on LAWBOR reputation.

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 guidance on when to use: as an external prior before trusting a peer/replica. It does not mention exclusions or alternatives, but the intended use case is clear.

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

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

No annotations are provided, so the description carries the burden. It describes the tool as a 'read' operation, implying no destructive side effects, but doesn't specify if the data is real-time, cached, or any permissions needed. For a read tool, this is adequate 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 two sentences: the first lists the key data fields, and the second frames the tool's role as a one-call read. It is front-loaded with the purpose and concise, with 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 single parameter and no output schema, the description lists the output fields (reputation weight, stars, M1 messages, etc.) and states it's a full profile read. It is nearly complete but could mention the output format (e.g., JSON) or error handling. Overall, covers most expectations for a simple retrieval tool.

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

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

Schema description coverage is 0%, so the description must compensate. It identifies the 'address' parameter as an agent address but does not explain its format or constraints beyond the schema's regex. The description adds meaning by stating it's for an agent, but not enough to fully compensate for the lack of 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 tool's purpose: retrieving the full LAWBOR profile for an agent address, listing specific data fields. It distinguishes itself from siblings by calling itself the 'one-call who is this agent in the LAWBOR network read', implying it's a comprehensive profile read compared to more specific 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 implies usage for getting a full profile but does not explicitly state when to use this tool over siblings like 'lawbor_neighbors' or 'lawbor_peer_trust', nor does it mention when not to use it. No alternatives or exclusions 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?

The description discloses key behaviors: trust-weighting by reputation, optional signature gating, and return fields. Without annotations, it carries the burden well, though it could mention potential side effects (none likely) but is transparent enough.

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

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

Two sentences, front-loaded with purpose and a striking analogy. Each sentence adds value with no fluff. Perfectly concise.

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 covers return values (quorum answer, confidence, weights) and explains signature validation. It could mention error cases or constraints (max 20 submissions, from schema) but is largely complete.

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

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

The schema already covers parameters (question and submissions) with descriptions. The description adds meaning by explaining how submissions are weighted (by reputation) and that signatures are optional for inclusion. This goes beyond the schema's basic 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 explains the tool's purpose: trust-weighted consensus over N agent answers, weighing by LAWBOR reputation, returning quorum answer, confidence, and per-agent weights. It distinguishes itself from sibling tools like lawbor_gate or lawbor_neighbors by focusing on consensus.

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 use: as a fix for multi-agent compounding-error trap, implying it's for aggregating multiple answers. It doesn't explicitly list alternatives or when not to use, but the purpose is clear and distinct from siblings.

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

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

With no annotations, the description takes full responsibility. It discloses that it aggregates from push/pr events and returns trust levels with a count. It implies read-only behavior but does not mention authentication or prerequisites; still adequate for a simple 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 extremely concise: two sentences that front-load the core functionality and then provide a specific use case. Every sentence adds value with 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?

Given the tool's simplicity (2 params, no output schema, no annotations), the description is nearly complete. It covers input, process, output, and use case. A minor omission is a note on prerequisites (e.g., repo must be ingested), but overall 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?

Schema coverage is 0%, so the description must compensate. It adds meaning by linking 'owner' and 'name' to a Gitlawb repo, clarifying their role beyond the bare schema. This helps the agent understand what to provide.

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 aggregates contributor reputation for a Gitlawb repo, specifies the input (owner/name), source (push/pr events), and output (trust levels + count). It distinguishes from sibling tools like lawbor_peer_trust by focusing on repo-level 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 provides a clear use case ('Use to pick a legit replica over a fresh name-squat'), which guides when to use the tool. However, it does not include explicit exclusions or mention of when not to use it versus 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?

Discloses that the tool is advisory (no money movement) and that unbound DIDs carry weight 0. With no annotations provided, the description carries the full burden and does so adequately, though it doesn't explicitly state read-only behavior or mention authentication requirements.

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

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

Two short sentences plus a clarifying note on unbound DIDs. Every sentence adds value, no redundancy, and the key acronym SWBR 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?

Explains the ranking logic and that it's advisory, but does not specify the output format (e.g., ranked list with scores). Given no output schema, this is a notable gap for an AI agent to use the result correctly.

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

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

Adds significant meaning beyond the input schema by explaining the ranking formula (reputation × bond / price) and that unbound DIDs have zero weight. The schema only describes field types; the description gives the evaluation logic, which is critical for correct usage.

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 does stake-weighted bid routing (SWBR), ranking bids by reputation × bond / price instead of lowest price. It distinguishes itself as advisory only, moves no money, and explains the ranking logic, making the purpose highly specific and distinct 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?

Explicitly states 'Advisory ranking only — moves no money; execute the award/escrow via the operator path,' providing clear context on when to use it (ranking) and when not to (execution). However, it does not directly compare to sibling tools or list exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output components (verdict, neighbors, committer weight) but omits safety, rate limits, side effects, or authorization needs. With no annotations, a score of 3 reflects adequate but incomplete transparency.

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

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

The description is two sentences with no wasted words. The first sentence states purpose and output, the second explains parameter logic. Efficient 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 2 optional parameters and no output schema, the description adequately covers usage modes and output components. It does not define domain terms like 'neighbors' or 'committer lawbor weight', but the context is sufficient for an agent familiar with the domain.

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%, baseline is 3. The description adds meaning by explaining the two usage modes (specific vs. global) and stating what the output includes, which goes beyond the schema's parameter 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 defines the tool as providing 'LAWBOR-side review verdicts' on repos, including verdict, neighbors, and committer weight. It distinguishes between single-repo and global summary modes, setting it apart from siblings like lawbor_neighbors or lawbor_repo_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 explains when to use each parameter combination: pass owner+name for a specific repo, omit both for global summary. It does not explicitly state when not to use the tool or name alternatives, but the guidance is clear and practical.

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 the signing scheme (EIP-191), the exact message format, and the reputation-gating nature. With no annotations provided, it carries the full burden and does well, though it lacks details on side effects like state changes or prerequisites.

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

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

Two sentences: first states purpose and format, second explains context and signing. No unnecessary words, front-loaded with key information.

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

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

Given the tool's complexity (6 params, no annotations, no output schema), the description covers purpose, signing mechanism, and usage context. It lacks parameter definitions and output description, but overall is functional.

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%, but the description only partially explains parameters (validator, targetCid, verdict, nonce, signature through the signing format). It does not explain the 'reason' parameter or provide detailed formats for each parameter, which is insufficient for a 6-parameter tool.

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

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

The description clearly states the tool posts a signed, reputation-gated pass/fail validation on a deliverable using a bytes32 CID. It uses a specific verb and resource, distinguishing it from sibling tools like lawbor_bind_did or lawbor_council.

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 this is a 'validator-before-payout building block' and mentions that an M11/M2 operator reads the result before paying or slashing, providing clear usage context. However, it does not explicitly state when not to use it or list exclusions.

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

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

With no annotations provided, the description must fully convey behavioral traits. It uses the verb 'Read,' implying a non-destructive operation, but does not explicitly state read-only, auth requirements, or other safety details. The description is adequate but could more directly disclose 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?

Two sentences with no wasted words. The first sentence states what the tool does, the second gives a usage recommendation. Ideal front-loading and conciseness.

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

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

Given no output schema, the description adequately describes return values (status, weight, per-validator verdicts). It also provides a practical use case. Missing details like data freshness or pagination are excusable for a simple single-CID lookup.

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 identifies the parameter as a 'deliverable CID' and mentions the output uses CID, but does not explain the format or constraints (e.g., hex pattern). This adds some meaning beyond the schema's pattern but falls short of full clarity.

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 specifies the action ('Read'), the resource ('reputation-weighted validation aggregate for a deliverable CID'), and the output components ('PASS/FAIL/CONTESTED + pass/fail weight + per-validator verdicts'). This distinguishes it from sibling tools like 'lawbor_validate' (which performs validation) and other read 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 provides clear usage context with 'Consult before accepting an agent deliverable,' which tells the agent when to invoke this tool. It does not explicitly list alternatives or when not to use it, but the straightforward use case 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 must carry the burden. It implies a read-only list operation and hints at the output's purpose but does not disclose authorization needs, rate limits, or return format details.

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

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

Two sentences, front-loaded with the main purpose, and zero superfluous words. Every phrase adds value.

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

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

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

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

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

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

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

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

The description clearly states it provides a 'curated shortlist of Base agents worth auditing' and lists three filter categories, which distinguishes it from siblings like mainstreet_audit_info (detailed audit info for a single agent) and mainstreet_leaderboard.

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

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

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

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

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

Without annotations, the description carries the burden. It discloses that the tool returns a signed payload, domain, types, and signer, and explains onchain verification. It doesn't mention idempotency or rate limits, but the context is reasonably transparent for a read-like operation.

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

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

Two sentences, no waste. The main purpose is front-loaded, and each sentence adds value: first states what it does, second gives usage guidance and return structure.

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

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

Given no output schema, the description explains the return payload adequately. The single parameter is understood, but the tool's role among siblings is clear. A minor gap is the lack of parameter format details.

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

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

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

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

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

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

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

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

Explicitly states 'Use when you need oracle-grade trust, not just an HTTP read', providing clear guidance on when to use this tool over others. No exclusions, but the context is sufficient.

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

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

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

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

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

Single sentence efficiently communicates key information: endpoint, cost, purpose. No redundancy.

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

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

For a simple tool with one parameter and no output schema, the description covers the essential use case and return type (URL + instructions). Lacks detail on response format or prerequisites but sufficient for basic understanding.

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

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

Schema coverage 0%; description only implies 'address' is a wallet address via context ('wallet before paying it onchain'). No format, validation, or example provided for the single parameter.

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

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

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

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

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

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

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

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

The description discloses key behaviors: returns x402 agents, includes trust score, washRisk, rankScore, and offers a special sort that applies a wash penalty. Since no annotations are provided, the description carries the burden and does so adequately.

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

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

The description is a single well-structured sentence that front-loads the main purpose and key features. It is concise but still packs 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?

The description covers purpose, return fields, sort options, and filters. However, it lacks details on pagination, error handling, or default behavior for optional parameters, and there is no output schema to supplement.

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

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

Schema coverage is 0%, but the description adds meaning to the 'sort' parameter (explaining trust-weighted with wash penalty) and mentions filters by network and minimum trust. However, 'limit' and 'excludeUnscored' remain unexplained, partially compensating for low schema coverage.

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

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

The description clearly states it is a 'Drop-in safer alternative to CDP Bazaar discovery' that returns scored agents with trust, wash risk, and rankScore. It distinguishes itself from the raw Bazaar by offering sybil-aware ranking, making the purpose very specific and actionable.

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

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

The description indicates this tool is for agent discovery when trust and sybil-awareness are needed, contrasting with the raw Bazaar. It implies when to use it but does not explicitly exclude other scenarios or mention alternative sibling tools.

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

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

With no annotations, the description carries full burden. It accurately indicates a read-only listing of endpoints, implying no side effects. While it doesn't detail behavior like return format or pagination, the simple nature of listing makes this adequate.

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

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

Two concise sentences perfectly front-load the purpose and usage. Every word adds value without redundancy.

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

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

For a listing tool with no parameters and no output schema required, the description fully covers what the agent needs to know to select and invoke it correctly.

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

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

The tool has zero parameters, so the description need not explain them. It appropriately focuses on the output purpose rather than input semantics.

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

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

The description explicitly states that the tool lists all MainStreet API endpoints, distinguishing between free and paid with prices. This clearly defines the tool's function and differentiates it from sibling tools that likely perform specific operations on these endpoints.

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

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

The description advises using the tool to discover available capabilities, providing clear context. However, it does not explicitly state when not to use this tool or mention alternatives, which would improve guidance for the agent.

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

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

No annotations provided, so description must disclose all behavior. It describes detection logic and output but omits potential side effects, authentication needs, or operational constraints. 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?

Three efficient sentences: domain, detection mechanism, and pairing advice. No redundancy, front-loaded with key action verb 'Detects'.

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?

Single required parameter, no output schema; description defines output format and tool limitation. Covers core purpose and result type. Could elaborate on risk level criteria or input validation, but sufficient for a straightforward 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 does not explain the 'address' parameter beyond the tool's context. While the parameter is self-explanatory (blockchain address), the description misses the opportunity to add clarity or constraints.

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 detects collusion/wash trading via reciprocal flow analysis, and specifies output risk levels. It distinguishes itself from the sibling tool mainstreet_repeat_rate by noting the pairing need.

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 recommends pairing with mainstreet_repeat_rate due to missing signal layers, providing actionable guidance. Lacks explicit when-not-to-use scenarios but effectively communicates context.

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

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

With no annotations, the description carries full burden but only states the basic operation. It does not disclose read-only nature, prerequisites, or any side effects.

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

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

One concise sentence with no fluff. Every word adds value.

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

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

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

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

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

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

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

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

The description uses a specific verb 'compare' and resource 'agents', clearly indicating head-to-head comparison with side-by-side metrics. It is distinct from sibling tools like mainstreet_score or mainstreet_match.

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

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

The description provides no guidance on when to use this tool versus alternatives. No when-to-use or when-not-to-use context is given.

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

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

No annotations are provided, so the description carries full burden. It details the output: score 0-100, verdicts (SAFE, CAUTION, BLOCK), human-readable assessment, and launch history with alive/rugged status. It also explains the scoring factors. This provides good behavioral transparency for a read-only analysis tool.

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

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

The description is concise and well-structured: a succinct purpose statement, a usage recommendation, and a brief explanation of the score. No filler or redundancy. Every sentence adds value.

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

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

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

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

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

Schema coverage is 100%, with a parameter description stating 'Deployer wallet address (the wallet that called the factory).' The tool description adds context: 'on Base' and 'reputation of a token DEPLOYER wallet', clarifying the purpose behind the parameter. This goes slightly beyond the schema.

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

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

The description clearly states the tool checks the reputation of a token deployer wallet on Base, differentiating it from siblings like mainstreet_score (for tokens) and mainstreet_vet. It specifies verb 'Check', resource 'reputation of a token DEPLOYER wallet', and network 'Base'.

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

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

It explicitly says 'Use when an LLM is asked to evaluate a token, or before aping into a recent launch.' This gives clear context for when to use. However, it does not mention exclusions or alternatives, such as when to use sibling tools instead.

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

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

Without annotations, the description fully carries the burden of behavioral disclosure. It reveals that the tool excludes self-reviews, returns both raw and weighted scores, and calculates inflationDelta to show the effect of sybil/self reviews. No contradictions with annotations (none provided). It is transparent about what the tool does and 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?

The description is a single sentence that packs essential information: purpose, weighting mechanism, exclusions, and outputs. It is concise and front-loaded, though the technical terminology (rawAvg, weightedRating, inflationDelta) might be dense for some agents.

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 single parameter and lack of output schema, the description explains the return values adequately. It covers the aggregation method and the meaning of inflationDelta. No additional context is needed for the tool's purpose.

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' has zero schema description coverage and the tool description does not explain its role. While it is likely the address to query, the description does not confirm this or provide any additional meaning beyond the schema's type and 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 calculates a weighted ERC-8004 feedback score, specifies the weighting by reviewer reputation, exclusion of self-reviews, and the returned values (rawAvg, weightedRating, inflationDelta). This distinguishes it from sibling tools like mainstreet_score and mainstreet_scores_batch which likely have different aggregation methods.

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

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

The description implies the tool is for sybil-resistant scoring but does not explicitly state when to use it over alternatives. No when-not-to-use or prerequisite conditions are provided. The mention of 'deferring to third parties' gives some context but lacks explicit 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?

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

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

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

Three front-loaded sentences: purpose, return format/behavior, usage context. No wasted words; every sentence earns its place.

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

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

Covers purpose, behavior with/without type, pagination, and usage context. Lacks specifics on response structure (e.g., total count), but tool is simple enough that the description is mostly complete.

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

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

Schema coverage is 100% with clear descriptions for each parameter (type, limit, offset). Description adds minimal extra meaning beyond reinforcing the 'omit type' behavior, so baseline 3 is appropriate.

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

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

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

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

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

Explicitly states 'Use to pre-filter a trusted set of agents/wallets before asking for individual scores.' Includes behavior when `type` is omitted (list available platforms), but does not mention when not to use or alternatives.

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

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

No annotations are provided, so the description carries the full burden. It only states that the tool lists top-scored agents, without disclosing behavioral traits such as whether it's read-only, authentication requirements, rate limits, or what happens on invalid input. The description is too sparse for an unannotated tool.

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

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

The description is two sentences, front-loaded with the purpose and immediately followed by usage guidance. Every sentence earns its place with zero redundancy or fluff.

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

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

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

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

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

Schema description coverage is 100%, with both parameters (limit, network) described in the schema (default values and filtering). The description does not add any additional semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool lists top-scored onchain AI agents on Base, with a specific verb ('List') and resource ('top-scored onchain AI agents'). It also provides a usage example ('who is best at X'), distinguishing it from siblings that focus on scoring, comparison, or verification.

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

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

The description explicitly says when to use the tool: when the user asks 'who is best at X' or wants discovery without a specific intent. It provides positive guidance but does not mention when not to use it or suggest alternatives among the many sibling tools.

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

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

No annotations are provided, so the description bears full responsibility. It states the tool 'finds' and 'returns ranked matches' but does not disclose behavioral traits like rate limits, authentication requirements, or potential side effects. The read-only nature is implied but not explicit, leaving significant gaps.

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

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

The description is two sentences with no fluff. It front-loads the action ('Find onchain AI agents...') and efficiently includes usage guidance and return details. Every word contributes value.

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

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

Given the tool has six parameters, no output schema, and no annotations, the description provides a moderate level of completeness. It explains the return fields but lacks details on result format, error handling, or any constraints. The 'Use BEFORE' instruction adds context, but overall it falls short of fully informing an agent.

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

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

Schema coverage is 100% with descriptions for all six parameters. The description does not repeat or add meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description starts with a specific verb 'Find' and resource 'onchain AI agents on Base' matched via 'natural-language intent'. It clearly distinguishes from siblings like 'mainstreet_find_verified' by focusing on intent matching. The mention of return fields (reputation, settlement history, etc.) reinforces the unique purpose.

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

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

The description explicitly advises 'Use BEFORE paying an x402 endpoint', providing clear context for when to invoke. However, it does not mention when not to use this tool or suggest alternatives (e.g., mainstreet_find_verified for verified-only searches), which would improve the score.

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

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

With no annotations, the description discloses it is read-only and non-destructive, and explicitly states it never executes a trade, providing good behavioral clarity.

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-loads the purpose and classification, though it could be slightly more concise; every sentence adds value.

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

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

Despite no output schema, the description thoroughly explains the return values including classification, evidence from multiple sources, and trade safety gate.

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 well-documented in the schema; the description adds context about it being a Base token contract address.

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 onchain intelligence for any Base token, returning a classification and evidence, distinguishing it from siblings as a consolidated read-only tool.

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

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

The description implies a consolidated one-call usage and notes it never executes trades, distinguishing from trade-executing tools, but lacks explicit when-not-to-use or alternatives guidance.

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

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

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

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

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

The description is concise with two sentences. It front-loads the core purpose and lists return fields. Every sentence is meaningful, though a bit more structure (e.g., separating input from output) could improve readability.

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

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

For a tool with 6 parameters and no output schema, the description is somewhat complete but lacks detail. It lists return fields but does not explain error conditions, default behavior, or what 'best' means (e.g., scoring criteria). The simplicity lowers the bar, but more context would be beneficial.

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

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

Schema description coverage is only 17% (only allowWeak has a description). The tool description does not explain any of the 6 parameters, nor does it clarify how maxPrice, minScore, or other filters affect the selection. Given the low coverage, the description fails to add value over the schema.

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

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

The description clearly states the tool's purpose: 'Pick the single best agent for an intent in one call.' It specifies the action (pick), the resource (best agent), and the scope (single, one call). The returned fields are listed, which distinguishes it from sibling tools that may return multiple agents or do comparisons.

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

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

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

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

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

No annotations are provided, so the description carries full burden. It states the tool returns a decision+verdict+score+reasoning+SLA/health and runs in <100ms, implying it is a safe, read-only check. However, it does not disclose authentication requirements, rate limits, or behavior on invalid addresses. This leaves some behavioral gaps.

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

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

The description is two sentences with no wasted words. It front-loads the purpose and efficiently covers usage, output, and performance. Every sentence earns its place.

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

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

Given the tool has one simple parameter and no output schema, the description covers the core functionality: what it does, when to call it, and what it returns. It lacks details on error handling or address format verification, but overall it is complete for its intended use.

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

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

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

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

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

The description clearly states it is a pre-payment trust check for buyer agents paying Base counterparties over x402. It specifies the exact context and output (decision, verdict, score, reasoning, SLA/health). This distinguishes it from sibling tools like mainstreet_verify or mainstreet_score, which likely serve different purposes.

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

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

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

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

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

No annotations are provided, so the description carries full burden. It discloses key behavioral traits: organic return-rate, self-pay flagged, volume cannot fake it. This adequately communicates safety and authenticity properties for the metric.

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 tightly written sentences with zero waste. The first sentence front-loads the signal identifier and core explanation; the second provides immediate usage guidance.

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

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

Given the simple single parameter, lack of output schema, and no annotations, the description covers purpose, behavioral caveats, and usage context. It does not specify the return format, but the metric is intuitive. Minor gap.

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

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

The schema description already labels 'address' as 'Payee address.' The tool description adds value by explaining what the metric is, but does not add new constraints or formatting details beyond what the schema provides. With 100% schema coverage, the baseline is 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 computes a repeat rate ('share of distinct payers who came back for a 2nd+ x402 settlement'), uses a specific verb ('share'), and distinguishes from siblings by referencing 'mainstreet_score' as a complementary tool.

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

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

It explicitly advises 'use alongside mainstreet_score to separate real demand from wash activity,' providing clear context for when to apply this tool relative to a specific sibling. However, it lacks explicit when-not-to-use guidance or alternatives.

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

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

With no annotations, the description carries full burden. It mentions 'live', 'transparency', and 'real x402 settlements onchain', indicating real-time on-chain data. However, it lacks details on update frequency, potential costs, or whether any state changes occur.

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

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

The description is extremely concise with two front-loaded sentences. The first sentence states the core function, the second adds context. No wasted words.

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

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

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

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

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

The tool has zero parameters and schema coverage is 100% (empty). Per guidelines, baseline for 0 parameters is 4. The description correctly adds no parameter-related content.

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

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

The description clearly states it provides 'Live revenue stats for MainStreet', which is a specific verb+resource. It distinguishes from sibling tools like mainstreet_leaderboard or mainstreet_verify by focusing on revenue data.

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

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

The description includes a use case: 'Useful to assess oracle credibility.' This gives clear context for when to use it, but it does not explicitly mention when not to use it or alternatives among the many sibling tools.

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

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

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

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

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

Two sentences: first defines purpose and output format, second enumerates returned data. Front-loaded, no wasted words.

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

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

For a single-parameter read tool with no output schema, the description adequately covers purpose, parameter, and return fields. Could mention if all addresses are valid or any restrictions, but overall complete.

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

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

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

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

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

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

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

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

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

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

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

With no annotations, the description carries the full burden. It discloses the batch nature (up to 200 addresses) and return fields, which is helpful. However, it does not mention error handling, rate limits, or authentication requirements, leaving some behavioral aspects unclear.

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

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

The description is succinct with two sentences, no unnecessary words. It front-loads the core functionality and includes a useful pairing tip without excess.

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

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

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

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

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

Schema coverage is 100%, so the description adds limited value beyond the schema. It reiterates the batch size (up to 200) but the schema already specifies maxItems. It does not provide additional context for the address parameter's meaning or format beyond the schema's pattern.

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

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

The description clearly states it performs a batch score lookup for up to 200 addresses, specifying the return fields (agentScore, deployerScore, etc.). It distinguishes itself from siblings like mainstreet_score (single) and mainstreet_find_verified (discovery) by explicitly pairing them.

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

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

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

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

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

With no annotations, the description carries full burden. It discloses the tool is read-only (reading top spenders) and indicates the sorting and filtering behavior. No negative side effects are implied.

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

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

Two sentences that are concise and front-loaded with essential purpose, followed by a use-case sentence. No wasted words.

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

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

Given no output schema and low parameter coverage, the description could explain return fields or ordering. It implies order by spending amount but lacks full context on output.

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

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

Schema coverage is 0% so description must compensate. It mentions 'last N days' for the sinceDays parameter but does not explain the limit parameter. Provides partial but not complete parameter semantics.

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

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

The description clearly identifies the specific verb (spent), resource (wallets), and context (via x402 on Base, time range). It distinguishes from sibling tools like mainstreet_top_raters which focus on ratings.

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

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

The description explicitly states two use cases: prospecting for customers and allowing buyers to see their own rank. However, it does not mention when not to use this tool or provide alternatives among siblings.

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

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

With no annotations, the description carries full burden. It explains ranking criteria but does not disclose potential edge cases, authentication needs, or what happens when no data exists. 'Leaders-of-leaders' concept is explained well.

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

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

Two concise sentences front-load the purpose and ranking logic with no redundant words. Excellent structure.

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

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

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

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

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

Schema coverage is 100% with one 'limit' parameter (min 1, max 50, default 20). Description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool returns top peer-rating agents (wallets) and explains the ranking logic: rates many distinct agents and those agents have healthy scores. It distinguishes from siblings like mainstreet_top_buyers by specifying 'raters' rather than 'buyers'.

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

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

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

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

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

With no annotations, the description fully discloses behavior: recovers signer, checks freshness and operator match, optional minScore. It also lists return fields. However, it does not mention potential failure modes or authentication requirements.

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

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

Two sentences: first specifies action and features, second gives usage guidance and return fields. No wasted words, front-loaded with purpose.

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

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

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

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

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

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

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

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

The description clearly states the tool verifies a MainStreet EIP-712 signed attestation with specific actions: recovers signer, checks freshness, matches operator, and optionally enforces min score. It distinguishes from siblings by focusing on verification of received verdicts.

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

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

The description explicitly states when to use: 'Use to trust a verdict you were handed by another agent without re-fetching.' It provides clear context but does not explicitly exclude other scenarios or mention alternatives.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool checks an index, that optional fields are for cross-checking, and that absence means not in coverage (not necessarily fraud). This is good transparency 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?

The description is two sentences, each serving a purpose: first stating the core function, second explaining the optional parameters and caveat. It is concise, front-loaded, and free of 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?

The description explains the tool's purpose and parameter usage well, but it does not describe the return value or output format. Given no output schema, this is a gap. Sibling tools exist for verification, but no alternatives are mentioned. Basic completeness for a simple verification tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by summarizing that 'tx' is required and 'to/from/amount' are optional for cross-checking the claim, which clarifies the intended use of the parameters 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 verifies a claimed x402 settlement onchain, specifying the verb 'verify' and the resource 'claimed x402 settlement'. It distinguishes from sibling tools like mainstreet_verify by focusing on x402 cross-layer trust gaps.

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: to confirm an onchain transfer matching a claimed settlement. It also clarifies the meaning of absence ('not in coverage, not proof of fraud'). While it doesn't explicitly exclude alternatives, the context implies it is for x402 settlement verification only.

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

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

No annotations provided. Description mentions throwing behavior but does not disclose whether the tool is read-only, has side effects, or requires authentication. For a validation step, more detail on return value or idempotency would help.

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

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

Two sentences, minimal and front-loaded. First sentence explains core function, second gives critical usage instruction. No fluff.

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

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

Reasonably complete for a simple validation tool: covers purpose, conditions, and placement. But lacks details on return value (success indicator) and how to proceed after vetting. With no output schema, description should fill that gap.

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

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

Schema covers 67% of parameters with defaults but no additional meaning in description. Address parameter lacks any semantic explanation beyond the pattern. Description adds nothing about parameter behavior beyond what schema provides.

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

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

Description clearly states verb and resource: 'Vet an agent against minimum reputation + alive gate'. It distinguishes this tool from siblings (e.g., mainstreet_score, mainstreet_verify) as a pre-payment safety check. The purpose is specific and unambiguous.

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

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

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

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