MegaChad

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

With no annotations provided, the description carries full burden for behavioral disclosure. It reveals that the transaction bundles approve calls and addLiquidity, notes the pair refunds excess supply, and states LP shares are stake-eligible. While it lacks details on authorization or error handling, it provides meaningful behavioral context beyond a simple 'build transaction' statement.

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

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

The description is two concise sentences, front-loaded with the core action and essential details. Every sentence adds value: the first lists the transaction steps, the second adds refund and staking context. No unnecessary words or repetition.

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

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

Given the tool has 4 parameters (all covered in schema) and no output schema, the description is fairly complete. It explains the transaction flow, refund behavior, and stake eligibility. However, it could benefit from indicating that the output is a transaction object or mentioning any prerequisites like 'address' parameter for skipping approvals, which is implicit in the schema but not reinforced in the description.

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

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

Input schema coverage is 100% (all four parameters described). The description does not add substantial meaning beyond the schema; it mentions 'human units' which is already in the schema descriptions for amountMC and amountMG. The address parameter is not further explained in the description. Baseline 3 is appropriate as the schema already documents 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?

The description clearly states the tool builds a transaction that includes approve steps for MC and MG tokens, followed by addLiquidity on MegaChadLP. It specifically identifies the pair and mentions that LP shares are stake-eligible, distinguishing it from siblings like build_amm_swap_tx (swap) and build_staking_tx (staking).

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

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

The description does not provide guidance on when to use this tool versus alternatives. It only describes what the tool does without context for appropriate usage, such as prerequisites or scenarios where other tools might be preferred. No explicit when-to-use or when-not-to-use information 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?

With no annotations, the description fully discloses key behaviors: no on-chain minOut, off-chain slippage, and the need to verify received balance. The exact swap sequence is detailed.

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

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

Three concise sentences, front-loaded with purpose, 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?

No output schema, so description should explain return values. It describes the plan but does not detail the output format (e.g., transaction object). With 4 parameters, some gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add meaningful parameter-specific info beyond the schema, though it mentions slippageBps default in 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 builds a two-step swap plan for MC↔MG through MegaChadLP, with specific method calls (ERC20.transfer, pair.swap). It is distinguishable from siblings like get_swap_quote which provides quotes.

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 two-step plan and off-chain slippage computation, but does not explicitly state when to use this tool vs alternatives like get_swap_quote or when not to use it.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions 'May be payable', lacking details on revert conditions, gas, or side effects. The description minimally covers behavior.

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

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

Two concise sentences with no fluff. Key information is front-loaded: action, resource, and condition.

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 adequately covers purpose and preconditions. Could mention that it returns calldata, but not required.

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 100% coverage on one parameter. Description adds meaning by specifying the proposal must be queued and past timelock, providing context beyond the schema's 'Proposal ID'.

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

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

The description clearly states the action (build execute calldata) for a specific resource (Queued Jestermogger proposal past its 2-day timelock), distinguishing it from siblings like build_queue_tx or build_veto_tx.

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 specifies condition (past timelock) and context (Queued proposal). While no alternatives are named, the sibling list provides context for when to use other tools.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions the GET returns eligibility and POST builds calldata, but does not disclose side effects (e.g., whether POST modifies state), authorization requirements, rate limits, or error scenarios. This leaves significant gaps for an agent to safely invoke the tool.

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

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

The description is two sentences but includes somewhat jargon-heavy terms ('Framemogger top-3-burner eligibility') that may not be immediately clear. It is not overly long, but could be restructured to front-load the core action more effectively.

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 dual-mode nature and the single parameter, but lacks details on return values, error handling, and prerequisites (e.g., does the proposer need to be eligible? Is there a call to action after checking?). With no output schema, more context would help an agent interpret responses.

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

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

The input schema already describes the 'proposer' parameter with 100% coverage. The description adds marginal value by linking the parameter to eligibility checking, but does not provide additional syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly indicates that the tool serves two purposes: checking eligibility via GET and building calldata via POST. It names the specific governance context ('Framemogger top-3-burner eligibility') and distinguishes from sibling build tools by focusing on proposal transactions. However, the dual nature could be confusing if an agent expects a single action.

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

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

The description explicitly states the usage ordering ('quickly check eligibility before drafting') and outlines the two HTTP methods and their respective inputs. While it does not list when not to use the tool or alternatives, the context is sufficient for an agent to decide.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions starting a 2-day timelock, which is a key side effect. However, it does not mention whether the tool requires authority, what happens on failure, or the exact output format (though 'calldata' is 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?

The description is two sentences, each conveying essential information: the action and the consequence. It is front-loaded and contains no unnecessary words or repetition.

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

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

Given the single parameter, no annotations, and no output schema, the description provides adequate context for the tool's purpose and effect. However, it could be more explicit about the return value (that it generates transaction calldata) and any prerequisites (e.g., proposal must be in 'Succeeded' state).

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

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

The input schema already covers the single parameter 'proposalId' with a clear description. The tool description only restates the parameter name ('queue(proposalId)') without adding new semantic meaning. Baseline 3 due to 100% 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 the tool's function: building calldata to queue a succeeded governance proposal. It uses a specific verb ('build') and resource ('queue(proposalId) calldata'), and distinguishes itself from sibling tools like build_propose_tx or build_vote_tx by focusing on the queue step.

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 this tool: only for 'Succeeded Jestermogger proposal'. It also hints at the subsequent step (execution after timelock). However, it doesn't explicitly exclude scenarios like pending or failed proposals, or directly contrast with sibling tools like build_execute_tx.

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: it returns an array of {to, value, data} for eth_sendTransaction, details that stake actions produce two transactions (approve+stake) while unstake/claim produce one. This is transparent and informative.

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

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

The description is three sentences with no unnecessary words. It is front-loaded with the main purpose and structured logically. Every sentence provides essential information.

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

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

Given 4 parameters with full schema coverage and no output schema, the description adequately explains the return format and how to use the output. It covers all behavioral aspects needed for an agent to invoke the tool and handle the response.

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 100% coverage with descriptions, but the description adds important context: amount is in human units, and address is used to skip the approve if allowance is sufficient. This adds value 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 specifies it builds transactions for stake/unstake/claim on two distinct venues (MoggerStaking and JESTERGOONER V4), with different contract tokens. It differentiates the tool from sibling build_* 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 clearly states when to use the tool (for staking actions) and how to specify venue and action. It does not explicitly mention when not to use or alternatives, but the context is sufficient for selection.

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

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

With no annotations, description carries full burden. It reveals conditional startVetoVote step and explains voter parameter checks (council-membership, duplicate-vote). Adequately sets expectations despite no annotation support.

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

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

Two sentences deliver core action, value mapping, conditional behavior, and parameter nuance without redundancy. Highly efficient.

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

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

No output schema, but description covers return behavior (conditional extra step) and parameter constraints. Complexity is moderate; additional detail on output format would be nice but not essential.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning: maps support enum to veto/defend, explains voter's role in validating membership and state, exceeding 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?

Description clearly states it builds castVetoVote calldata for NFTVetoCouncil, explains support values (veto/defend), and mentions conditional extra step. Distinct from sibling tools like build_vote_tx.

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 describes when to use (veto voting on NFTVetoCouncil) and when extra step is needed. No direct mention of when not to use, but context implies differentiation from other voting 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 notes the vote weight calculation but fails to disclose that this builds a transaction (a write operation), auth needs, or output format.

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 efficient sentences: first states purpose, second adds critical details. No wasted words.

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

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

The description covers what the tool builds and vote weight, but omits output type, prerequisites (e.g., active proposal, token balance), and whether it's a read or write operation. Adequate but not fully complete.

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

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

Schema coverage is 100% and both parameters are described. The description adds vote weight context but repeats enum values already in schema, providing limited additional meaning.

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

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

The description clearly states the tool builds a castVote transaction on Jestermogger, with specific verb+resource and distinct from sibling build 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 mentions support values and vote weight, implying when to vote, but lacks explicit guidance on prerequisites (e.g., active proposal, token balance) or when not to use compared to alternatives.

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

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

With no annotations provided, the description must carry the full burden. It discloses that responses are 'structured' and lists functional intents, but omits critical behavioral traits: whether the chat maintains conversation state/session history, required authentication, rate limits, or how it handles ambiguous queries.

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 filler. It front-loads the core purpose before listing intents. The intent enumeration is efficient but could be improved with categorization or a clearer link to the sibling tools that fulfill similar functions.

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, and the tool's position as a generalist among many specialists, the description should clarify the tool selection strategy. The intent list provides functional coverage, but the absence of output format details or statefulness information leaves 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?

Input schema has 100% description coverage for both parameters. The description reinforces the 'plain English' nature of the message parameter but adds no additional semantic detail (e.g., prompt engineering tips, expected length constraints) beyond what the schema already provides. Baseline 3 is appropriate given complete 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 the core action (send a plain English message) and return type (structured, actionable responses). It also enumerates supported intents. However, it does not effectively distinguish this generalist chat tool from specific siblings like `get_price` or `get_wallet_info`, leaving ambiguity about which tool to select.

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?

While the description lists 11 supported intents (price, stats, wallet, etc.), it provides zero guidance on when to use this conversational interface versus the dedicated, single-purpose sibling tools (e.g., `get_price`, `get_swap_quote`). The agent cannot determine if this is a fallback tool or primary interface.

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

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

With no annotations provided, the description carries the full burden and successfully discloses the return structure (step-by-step plan with bridge URLs, calldata, and burn instructions). However, it fails to clarify the safety profile—specifically whether this is a read-only planner or if it triggers actual transactions, which is critical context for a tool mentioning 'burn instructions' and 'swap calldata'.

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?

Every element earns its place in a single dense sentence: the action (Build), scope (cross-chain from [9 chains] to MegaETH), and return value composition (plan with URLs, calldata, instructions). Zero waste, perfectly front-loaded.

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

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

For a 4-parameter bridging tool with complete schema coverage but no output schema, the description adequately compensates by detailing the returned execution plan components. It appropriately omits authentication details (likely wallet-based) but could benefit from mentioning rate limits or execution risks given the financial nature of the operation.

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

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

Schema description coverage is 100%, with parameters fully documented (amount format example, wallet purpose, referrer commission detail). The description meets the baseline score of 3 since the schema adequately defines semantics without requiring additional elaboration in the description text.

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 builds a cross-chain 'looksmaxx' plan from specific listed chains to MegaETH, using a specific verb and resource. However, it assumes domain knowledge of what 'looksmaxx' means without contrasting explicitly against the sibling tool 'get_looksmaxx_plan' to clarify when to choose this cross-chain variant.

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?

Usage is implied by the enumerated source chains (use when bridging from Ethereum, Base, etc.), but provides no explicit guidance on when to prefer this over 'get_looksmaxx_plan' or 'get_bridge_info', nor any prerequisites or conditions for invocation.

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. Effectively discloses returns ('signature payload', 'approval status') and critical next-step behavior (must POST to /api/gasless/burn to complete). Could specify what asset gets burned or required approvals.

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

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

Three sentences with zero waste: sentence 1 states purpose, sentence 2 details returns, sentence 3 gives essential next-step instruction. Front-loaded with specific technical terminology (EIP-712, gasless burn).

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?

Strong completeness given no output schema: explains both immediate returns (payload, status) and downstream workflow (POST endpoint). Missing only specific return structure details or confirmation of what exactly gets burned.

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

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

With 100% schema coverage, the description appropriately focuses on contextualizing the single parameter within the EIP-712 typed data flow rather than repeating schema definitions. Mentioning 'wallet must sign' clarifies the address parameter's role as the signer.

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

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

Description uses specific technical language ('Get EIP-712 typed data for a gasless burn') that precisely identifies the operation and distinguishes it from sibling tools like get_swap_quote or get_bridge_info. The verb-resource combination is exact.

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?

Describes the multi-step workflow clearly ('Returns the signature payload... After signing, POST... to relay'), which implicitly guides usage. Lacks explicit 'when-not-to-use' alternatives (e.g., vs regular burn), but provides strong procedural 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?

No annotations are provided, so the description must disclose behavior. It explains the time-ordered nature, default block window, and estimate of time span (~8 min). However, it does not mention whether it is read-only, what the response format looks like, rate limits, or error handling. With zero annotations, more detail would be expected.

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

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

Two sentences, front-loaded with the core purpose, then specific event list and defaults. 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, the description is fairly complete: it lists event types, defaults, and time estimate. It could mention whether results are paginated or if there are limits on total events returned, but overall it gives enough context for an agent to understand what to expect.

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

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

Input schema has 100% coverage with descriptions for both parameters. The description adds context on defaults and block time estimate but does not add syntax or format details beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description clearly states it is a 'unified time-ordered feed of recent on-chain events' and lists specific event types (burns, sends, stakes, etc.). It distinguishes itself from sibling tools which are focused on building specific transactions, so the agent knows this is for viewing activity.

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

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

The description gives explicit context on what events are included and default parameters (blocks=2000, limit=50). While it does not state when not to use or name alternatives, the sibling tools are obviously different (building txs), so it's clear this is for monitoring. Could mention use cases like 'use this to see recent protocol activity'.

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 transparently states that the tool returns the complete surface in a single response, implying a read-only operation with no side effects. Slightly lacking details about potential size or pagination, but sufficient.

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 purpose and usage. Every word earns its place, with no unnecessary information.

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

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

Given zero parameters and no output schema, the description provides all necessary context: what the tool returns (a directory), when to use it (first call), and its scope (complete surface). It feels complete for an agent to understand and invoke correctly.

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

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

The input schema has zero parameters, and the description correctly does not add parameter info. Per guidelines, zero parameters earn a baseline of 4, and no additional value is needed beyond what the schema provides.

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

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

The description clearly defines the tool as a 'master directory' listing all endpoints, tools, and examples. It distinguishes itself from siblings by being the recommended first call for agents, providing a unique and specific 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 recommends this as the first call for any agent, providing clear usage context. It does not list exclusions or alternatives, but the nature of the tool as a starting point is effectively communicated.

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 disclosure burden. While it lists return fields, it omits behavioral traits such as whether this performs a live blockchain query versus cached data, authentication requirements, error handling for unregistered agents, or confirmation that this is read-only. It describes data but not execution semantics.

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

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

The description is a single, dense sentence with zero wasted words. It front-loads the core action ('Returns') and immediately specifies the domain-specific data types, efficiently communicating 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?

While the description compensates for the missing output schema by listing returned data categories, it lacks structural detail (e.g., nested vs flat object, data types) that would aid an agent in consuming the response. Given the absence of annotations and output schema, more detail on the return shape or error conditions would be necessary for full 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 input schema contains zero parameters. Per the evaluation guidelines, zero parameters establishes a baseline score of 4, as there are no parameter semantics to elaborate upon beyond the schema itself.

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 retrieves specific ERC-8004 registration metadata and on-chain agent identity components (ID, owner, wallet), reputation metrics, and contract addresses. The specificity of 'ERC-8004' and the enumeration of fields naturally distinguishes it from sibling tools like get_identity or get_wallet_info, though it lacks explicit comparative language.

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 enumerates return data but provides no guidance on when to invoke this tool versus alternatives like get_identity or get_wallet_info. There are no stated prerequisites, conditions for use, or explicit exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses the AMM type, fee, and returns (expected output, price impact, spot prices). It also explains the effect of omitting parameters. It could explicitly state it's read-only, but 'quote' implies no state change, so it's largely transparent.

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

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

The description is two sentences, front-loaded with purpose, warnings, and usage notes. Every sentence is essential and provides distinct value, avoiding 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?

Given the lack of output schema, the description lists the returned data (expected output, price impact, spot prices). It covers the pair specifics, optional behavior, and the critical token naming issue. For this tool's complexity, it is fully complete.

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

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

Schema coverage is 100% and both parameters have descriptions. The description adds value by explaining that omitting 'from' and 'amount' inspects reserves, which is not in the schema. This provides additional meaning beyond the schema definitions.

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

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

The description clearly states it quotes a swap on the MegaChadLP MC/MG pair, specifying the exact tokens and AMM type. It distinguishes from siblings like get_swap_quote by highlighting the tokenA/tokenB naming quirk, making its purpose unique and unambiguous.

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

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

The description gives clear context: use this tool for quoting swaps on this specific pair, with a warning that standard routers won't work. It also explains the optional behavior to inspect reserves. However, it does not explicitly mention when not to use it or compare to alternatives, leaving a slight gap.

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

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

No annotations provided, so description carries full burden. It discloses content types ('canonical and aggregator bridges') which adds behavioral context, but lacks operational details like data freshness, caching behavior, or authentication requirements expected for a third-party bridge data API.

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?

Exactly two sentences with zero redundancy. First sentence establishes purpose and domain scope (MegaETH, source chains); second sentence clarifies content categories (canonical vs aggregator). Every word earns its place.

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

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

Appropriately complete for a zero-parameter information tool. Without output schema, the description adequately signals return content (bridge listings by type). Could be improved by noting response format or data freshness, but sufficient for agent selection given the limited 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?

Input schema has zero parameters, triggering baseline score of 4. The description appropriately does not invent parameters, and the empty schema is correctly interpreted as a simple information retrieval operation requiring no filtering inputs.

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 specific verb 'Returns' with clear resource 'bridge information' and explicit scope 'for moving assets to MegaETH from Ethereum, Arbitrum, Base, and other chains'. It distinguishes from siblings like get_swap_quote by focusing specifically on bridging infrastructure rather than swapping.

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

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

Provides clear contextual guidance by specifying the exact use case (moving assets to MegaETH from specific L1/L2 chains), which implies when to invoke it. However, lacks explicit 'when not to use' guidance or named alternatives like cross_chain_looksmaxx.

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

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

With no annotations provided, the description carries the full burden of disclosure. It compensates partially by detailing the returned data structure (ERC-8004 scores, domain names, profile info, images), but lacks operational details like pagination behavior, caching policies, rate limits, 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?

The description consists of two efficient sentences with zero waste. The first sentence front-loads the core action and resource, while the second enumerates included data fields. 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 absence of an output schema, the description appropriately compensates by listing the components of the leaderboard return value (scores, domains, images). For a parameterless read operation, this provides sufficient context for invocation, though pagination or response size limits remain undocumented.

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

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

The input schema contains zero parameters, which according to the rubric establishes a baseline score of 4. The description does not need to compensate for parameter documentation.

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 ('Returns') and clearly identifies the resource as a 'burner leaderboard ranked by total burns.' While it effectively implies distinction from siblings like get_portfolio or get_gallery through domain-specific terminology (ERC-8004, .mega domains, looksmaxxed), it does not explicitly name alternatives or differentiating use cases.

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 explicit guidance on when to use this tool versus alternatives like get_megachad_stats or get_gallery. There are no 'when-not-to-use' exclusions, prerequisites, or contextual triggers 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?

With no annotations, the description fully bears the transparency burden. It explains all returned components (schedule, current week, weekly emission, split) and the formula. It does not mention side effects or auth needs, but for a read-only fetch with no parameters, this level of detail is sufficient.

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 zero wasted words. The formula is efficiently included. Every piece of information is relevant 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?

The description is complete for a zero-parameter read-only tool. It explains all return components and the underlying calculation. No output schema exists, so the description adequately covers what the agent needs to know.

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

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

There are no parameters (schema coverage 100%), so the description adds no parameter details. The baseline for zero-parameter tools is 4, and the description does not need to explain parameters.

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

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

The description clearly states the tool returns the full 225-week MEGAGOONER emission schedule plus current week, on-chain weekly emission, and the EmissionController split. It includes the explicit formula, making the purpose highly specific and differentiating it from siblings, none of which handle emission schedules.

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 purpose, implying when to use it (to get emission schedule data). While it doesn't explicitly state when not to use or suggest alternatives, the context of sibling tools shows no overlap, and the zero-parameter interface makes usage straightforward. A minor improvement could add 'Use this to retrieve emission schedule data; no other tool provides this information.'

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 disclosure burden. Adds valuable context about return data structure (IPFS URLs, addresses, timestamps), but omits operational details like read-only safety confirmation, rate limits, pagination total behavior, or caching characteristics implied by the offset/limit 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?

Single dense sentence front-loaded with action verb and resource. Every clause earns its place—'IPFS image URLs, burner addresses, timestamps, and NFT token IDs' efficiently specifies return payload without waste. Optimal length for the complexity.

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?

Compensates well for missing output schema by enumerating specific return fields. Appropriate for a simple read-only browsing operation with two standard pagination parameters. Minor gap: could explicitly confirm non-destructive read-only nature given absence of annotations.

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 100% description coverage for both parameters (limit and offset). Description mentions no parameters, but baseline score is 3 since schema fully documents pagination semantics without requiring duplication.

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?

Excellent specific verb ('Browse') combined with clear resource ('looksmaxxed burns') and concrete return value details (IPFS URLs, burner addresses, timestamps, NFT token IDs). Clearly distinguishes from sibling tools like get_nft_metadata (specific metadata retrieval) and chat_with_megachad (conversational).

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

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

Implies usage through 'Browse recent' but provides no explicit when-to-use guidance, prerequisites, or alternative tools (e.g., when to use get_nft_metadata vs this gallery view). Lacks explicit exclusions or conditions.

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

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

No annotations are provided, so the description must convey behavioral traits. While the tool name and description suggest it is a read-only query (getter), the description does not explicitly state that it does not modify state or require special permissions. This lack of clarity is a gap.

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

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

The description is a single sentence that efficiently lists all key aspects of the return data without any filler words. Every element 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 no output schema, the description compensates by enumerating the returned fields (actions, vote tally, veto status, voter receipt). This provides sufficient context for an AI agent to understand what information the tool retrieves.

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

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

Input schema covers both parameters with descriptions (proposalId is 1-indexed, voter address for receipt). The description adds no new parameter meaning beyond what the schema already provides; baseline 3 is appropriate given 100% 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 title 'Get Single Proposal Detail' and description explicitly state the tool retrieves full state for one proposal, listing specific fields (actions, vote tally, veto status, voter receipt). This clearly distinguishes it from list_governance_proposals which likely lists proposals rather than detailing one.

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 like list_governance_proposals. The description implies it is for detailed state retrieval of a single proposal, but does not provide explicit when-not or exclusion criteria.

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

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

No annotations provided, but description compensates by comprehensively listing return fields (MegaNames, balances, burn history, reputation, etc.) revealing the full data shape. Would be 5 if it explicitly stated idempotency or caching 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?

Three sentences with zero waste: purpose declaration, return value enumeration, and architectural positioning. Front-loaded with the core function and concrete examples.

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 annotations or output schema, the description adequately compensates by detailing return fields. Complete for a single-parameter lookup tool, though an output schema would eliminate the need for the returns list in the description.

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 100% coverage with clear description. Tool description adds semantic context by framing the parameter as something to be 'resolved' into a profile, reinforcing the lookup/translation nature of the operation.

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

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

Specific verb 'Resolve' with clear resource 'MegaETH identity profile'. Distinguishes from siblings like get_wallet_info and get_portfolio by positioning as the 'unified' social identity layer rather than financial or basic wallet 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?

Provides contextual positioning as the 'social identity layer' which implicitly differentiates it from financial or stats-focused siblings, but lacks explicit when-to-use/when-not-to-use guidance or named 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, description carries the full burden. It disclose that outputs are 'pre-built calldata ready to sign', implying this is a read-only planning tool that returns unsigned transactions rather than submitting them, and reveals the 4-step internal flow. Could clarify if it performs any server-side state changes or rate limiting.

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

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

Single sentence, front-loaded with action verb. Every phrase adds value: 'complete ordered set', specific step sequence, and 'pre-built calldata ready to sign'. Zero 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?

Compensates well for missing output schema by describing the return structure (ordered steps, calldata format). Brief mention of what 'looksmaxx' prerequisites are (e.g., requiring MEGACHAD balance) would elevate this to 5, though ethAmount description partially covers this.

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 100% description coverage (wallet address format, ethAmount usage), meeting the baseline. Description mentions 'swap' which contextualizes ethAmount, but does not add syntax, validation rules, or format details beyond what the schema provides.

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

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

Description uses specific verb ('Returns') and resource ('transaction instructions'), clearly distinguishing from siblings like get_swap_quote (single-step pricing) by specifying this is the 'full looksmaxx flow' with explicit ordered steps (swap → burn → tren fund → submit).

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?

Describes the scope (full flow vs partial) through the step sequence, but lacks explicit when-to-use guidance vs alternatives (e.g., when to use get_looksmaxx_requirements first) or prerequisites for the wallet parameter.

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

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

No annotations provided, so description carries full burden. It adequately discloses return contents (step-by-step instructions, contract addresses, amounts) but fails to state whether this is a safe read-only operation or if it triggers any on-chain checks, which is relevant context for a financial/payment-adjacent 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 efficient sentences with zero waste. First states core function; second enumerates return payload. Appropriately sized for a zero-parameter lookup tool.

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

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

Adequate given zero parameters, but incomplete for the domain. Lacks output schema, and description compensates partially by listing return contents. However, given this involves payment requirements and token burning, missing safety/auth context prevents a higher score.

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?

Zero input parameters (baseline 4). Description adds value by defining domain-specific terms (x402, $MEGACHAD, looksmaxzing) that help the agent understand the tool's ecosystem 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?

Clear verb ('Returns') and specific resources (x402 payment requirements, $MEGACHAD burn requirements). However, it fails to distinguish from sibling tool 'get_looksmaxx_plan', leaving ambiguity about whether this is preparatory lookup vs. active planning.

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 invoke vs alternatives. Given sibling 'cross_chain_looksmaxx' exists, guidance on whether this applies to single-chain or all chains is absent.

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. 'Returns' implies read-only operation, but description omits auth requirements (public API vs authenticated), rate limits, data freshness/caching behavior, or error conditions. Minimal viable disclosure for a public statistics endpoint.

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 efficient sentence with colon-delimited list of return fields. Front-loaded with action verb, zero redundancy, every token 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?

No output schema exists (has_output_schema: false), so description appropriately compensates by enumerating all four return fields (supply, circulating, burned, count). Adequate for a zero-parameter read operation despite lack of annotations.

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

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

Input schema has zero parameters, which per guidelines establishes a baseline of 4. No parameter documentation needed or provided.

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

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

Description uses specific verb 'Returns' with clear resource '$MEGACHAD token statistics', and enumerates exact metrics (supply, circulating, burned, burn count). This clearly distinguishes from siblings like get_price (pricing), get_portfolio (holdings), and get_referral_stats (referral metrics).

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?

Contains no explicit when-to-use guidance, prerequisites, or pointer to alternatives (e.g., does not contrast with get_price for market data vs supply data). User must infer usage from the function name and described return values.

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 adds valuable context about the content ('curated', specific fields like contract addresses and links) but omits operational details like pagination behavior, response size limits, rate limiting, or whether the data is cached or real-time.

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 zero waste. It immediately states the action and resource, uses a colon to efficiently list categories, and front-loads the most critical information. Every word earns its place.

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

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

Given the zero-parameter complexity and lack of output schema, the description appropriately compensates by detailing what fields appear in the return value (contract addresses, features, links). It could be improved by noting if the directory is paginated or frequently updated, but covers the essentials.

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 input parameters, which according to the scoring guidelines establishes a baseline score of 4. There are no parameters requiring semantic clarification beyond what the empty schema indicates.

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

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

The description uses the specific verb 'Returns' and clearly identifies the resource as a 'curated directory of protocols on MegaETH'. It elaborates the scope by listing protocol categories (DEXes, bridges, payment infra, etc.), which implicitly distinguishes this broad directory from sibling tools like get_bridge_info or get_swap_quote that likely handle specific operations.

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

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

The description provides no guidance on when to use this tool versus its siblings. It fails to clarify whether this should be called for protocol discovery versus using get_bridge_info for specific bridge details, or whether it requires any prerequisites like a connected wallet.

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 discloses the tool returns count, boost tier, and an eligibility verdict. Also notes a behavioral implication: wallets with 0 NFTs get no rewards even when staked. Sufficient for a read 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 fluff. First sentence delivers core output, second provides actionable usage guidance. Front-loaded and efficient.

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

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

Given no output schema, the description adequately explains the return values (count, tier, verdict) and their significance for staking. Could mention edge cases like invalid address, but overall complete for a simple query.

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 fully described in the schema (100% coverage). The description adds no extra semantic meaning beyond what the schema provides.

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

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

Clearly states it retrieves MEGACHADNFT count, boost tier, and staking eligibility verdict. Differentiates from sibling tools like get_nft_metadata and get_portfolio by focusing on inventory and staking criteria.

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

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

Explicitly advises using this before building a stake transaction, explaining why zero NFTs yield zero rewards. Does not name alternative tools but provides clear context on when to invoke.

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. Adds valuable context about data sources ('IPFS or Warren on-chain') and identifies the ERC-721 standard explicitly. However, lacks disclosure on error handling (invalid tokenId), caching behavior, rate limits, or whether this requires authentication despite being a getter.

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

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

Single sentence with high information density. Front-loaded with action verb ('Returns'), immediately follows with scope (ERC-721, looksmaxxed NFT), and efficiently parenthesizes storage variants (IPFS/Warren). No redundant words or filler.

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

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

Absence of output schema is partially compensated by listing specific return fields (image URL, attributes, storage properties). For a single-parameter read operation without destructive side effects, the description provides adequate completeness, though error scenarios could be mentioned.

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 100% coverage with 'tokenId' already described as 'NFT token ID (numeric string)'. Description focuses entirely on return values rather than elaborating on the parameter (e.g., format constraints, valid ranges, where to find token IDs). With full schema coverage, baseline 3 is appropriate.

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

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

Excellent specificity: 'Returns ERC-721 metadata' identifies the exact token standard and protocol, 'looksmaxxed NFT' distinguishes from generic NFT tools (distinguishing from siblings like get_portfolio or get_gallery), and enumerates specific return components (image URL with storage locations, attributes, storage properties).

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

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

Provides no guidance on when to select this versus sibling tools like get_gallery (which likely displays NFTs visually) or get_portfolio (which may include NFT holdings). No preconditions, alternatives, or 'when-not-to-use' advice included.

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. Adds return format disclosure ('formatted balances with raw values') and scope constraints (specific 4-token list). However, omits explicit read-only/safety characteristics and rate limiting 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 concise sentences. No redundancy. Front-loaded with action and scope. Specific token list and return format efficiently communicated without waste.

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

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

Complete for a simple single-parameter read tool. Compensates for missing output schema by describing return values ('formatted balances with raw values'). Sufficient given 100% param coverage and clear scope.

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% (address param fully described). Description provides minimal additional semantic value beyond schema ('for a wallet' aligns with param description). Baseline 3 appropriate per guidelines for high-coverage schemas.

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

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

Specific verb 'Get' + specific resource 'MegaETH token balances' + explicit scope (ETH, WETH, $MEGACHAD, USDm). Distinguishes from sibling get_price (price data) and get_wallet_info (general wallet metadata) by specifying portfolio/balance retrieval.

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

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

Implies usage through specificity (lists tokens covered) but provides no explicit when-to-use guidance or comparison to alternatives like get_price or get_wallet_info.

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 disclosure burden. It successfully identifies the data source (Kumbaya DEX) and characterizes the burn cost as 'estimated' (indicating calculation behavior). It does not disclose rate limits, caching behavior, or error handling, but covers the essential behavioral traits for a simple getter.

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

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

The description is a single, information-dense sentence that front-loads the primary function (returning price) and appends the secondary data point (burn cost). Every element—including the specific DEX name, token ticker, and exact burn quantity (225,000)—serves a communicative purpose without waste.

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

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

For a zero-parameter read operation with no output schema, the description is complete. It specifies what data is returned (price in ETH and estimated burn cost), eliminating ambiguity about return values without requiring explicit output schema 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?

The input schema contains zero parameters. Per evaluation rules, 0-parameter tools receive a baseline score of 4. The description appropriately does not invent parameters that don't exist in the schema.

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

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

The description uses specific verbs ('Returns') and identifies the exact resource ($MEGACHAD price from Kumbaya DEX). It distinguishes itself from sibling get_swap_quote (which would be for trading execution) by focusing on current price data and a specific burn cost calculation.

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

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

The description implies usage context through the mention of burn costs, suggesting it's useful when evaluating token burns. However, it lacks explicit guidance on when to use this versus get_swap_quote or gasless_burn_info, and doesn't state prerequisites or 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 tool's purpose as a read-only registry lookup (implied by 'pull' and 'includes') and details the contents (addresses, ABIs, gotchas). It does not explicitly state absence of side effects, but the description strongly suggests a safe, read-only operation. No contradiction with non-existent annotations.

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

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

Two sentences, both dense with information. The first sentence enumerates covered contracts and contents; the second gives a usage directive. No fluff, perfectly front-loaded.

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

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

Given the tool has no parameters and no output schema, the description fully explains what is returned (contract list, addresses, ABIs, gotchas, agent links) and when to use it (first for any DeFi interaction). This is complete for a registry lookup tool.

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

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

The input schema has zero parameters, so the description adds all meaning. It goes beyond the schema by specifying exactly what the registry contains (list of contracts, addresses, ABIs, gotchas, links), which is essential for the agent to know what will be returned. With schema coverage at 100% (vacuously), the description fully compensates.

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

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

The description clearly states it returns a canonical machine-readable registry of every MEGA Protocol contract, listing specific contracts (tokens, AMM pair, staking, governance, emissions, safety) and what is included (addresses, ABIs, gotchas, links). It distinguishes from sibling tools like get_agent_info or get_megaeth_protocols by being the comprehensive starting point.

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 to 'Pull this FIRST for any DeFi interaction,' providing clear context on when to use. It implies it is the prerequisite for other tools. However, it does not explicitly state when not to use it or list alternatives, though the 'FIRST' guidance is strong.

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

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

No annotations provided, so description carries full burden. It clearly indicates it is a read operation returning state data. It does not mention rate limits or authentication, but for a simple getter, the behavioral traits are adequately disclosed.

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 superfluous words. Information is front-loaded: first sentence states what is returned, second sentence gives crucial usage context. Every word earns its place.

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

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

For a tool with no parameters and no output schema, the description fully covers purpose, return value, and usage context. It tells the agent exactly what the tool does and why it matters, making it complete for safe 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?

Input schema has zero parameters (100% coverage by virtue of none), so the baseline is 4. Description adds no parameter info because none exist, but that 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 the tool returns CircuitBreaker state (paused status, guardian votes, auto-unpause timer) and NFTVetoCouncil composition (seats, threshold, members). This clearly distinguishes it from sibling tools like build or other get tools, with a specific verb and resource.

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 this is critical before any write transaction, because if paused, writes revert. This gives clear when-to-use guidance. It does not mention alternatives or exclusions, but the context is strong enough for safe selection.

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

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

With no annotations provided, the description carries the full burden. It successfully discloses the specific data returned (the four statistical fields), which aids in selection. However, it lacks disclosure of error behaviors (e.g., unregistered agent), side effects, or rate limiting.

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 efficient sentence front-loaded with action and resource. The em-dash appendage listing return values earns its place by providing necessary behavioral context. Zero redundancy or filler.

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

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

Given a simple single-parameter read operation with no output schema, the description adequately compensates by enumerating the specific statistics returned. It meets the needs for tool selection despite lacking explicit error documentation.

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

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

Schema description coverage is 100% ('Agent wallet address (0x...)'), establishing a clear baseline of 3. The description implies the parameter through 'for a registered agent' but does not add semantic details beyond the schema (e.g., validation rules, format 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?

Clear verb 'Get' with specific resource 'referral statistics' and concrete data fields listed (total referrals, earnings, reward per burn, calldata). However, it does not explicitly distinguish from sibling tool 'register_referral_agent' or clarify when to use this versus 'get_agent_info'.

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. While 'registered agent' implies a prerequisite state (registration), it does not state that one must call 'register_referral_agent' first or what happens if the address is unregistered.

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?

Even without annotations, the description discloses detailed behavioral traits: included data fields (balances, allowances, earnings, NFT boost, APR, pool stats) and the difference between address-specific and global stats. No contradictions.

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

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

The description is three sentences, each adding essential information. The first sentence states the main action and resources, and the second lists included data. No extraneous 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 complexity of aggregating two staking venues and the lack of an output schema, the description is thorough. It lists all major return components and differentiates behavior by input, making it complete for 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% and the parameter is well-described in the schema. The description adds value by explaining the impact of omitting the address (returns global stats only), which clarifies optionality 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 returns combined position across two specific staking venues, with details like balances and rewards. It uses a specific verb ('Returns') and resource ('combined position across both staking venues'), and distinguishes it from sibling tools that focus on other aspects.

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

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

The description explains behavior with and without the address parameter, providing context on when to include it. However, it does not explicitly state when to prefer this tool over siblings like get_portfolio or get_megachad_stats.

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 must carry full behavioral burden. It discloses return contents (router address, calldata, slippage-adjusted output) and conditional behavior, but omits safety-critical DeFi context: whether this is read-only, what slippage percentage is applied, and reversal risks.

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

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

Three sentences, each earning its place: purpose, return values, and parameter behavior. The structure is front-loaded with the core action and specific context ($MEGACHAD, Kumbaya DEX). No redundancy or filler.

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

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

Given the DeFi complexity and lack of output schema/annotations, the description adequately covers the basic contract but leaves gaps: slippage calculationmethod is unspecified, safety warnings are absent, and the full structure of 'calldata params' is unexplained.

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

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

With 100% schema description coverage for the single parameter, the baseline is 3. The description adds that omitting ethAmount returns 'contract addresses' specifically, which elaborates on the schema's 'general info,' but does not significantly enhance parameter semantics beyond the schema.

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

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

The description identifies the specific verb (Get), resource (swap quote), token ($MEGACHAD), input currency (ETH), and platform (Kumbaya DEX on MegaETH). It distinguishes from siblings like get_price by specifying this returns router address and calldata for execution.

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 guidance on when to omit the ethAmount parameter ('for general swap info and contract addresses'), but lacks explicit comparison to sibling tools (e.g., when to use get_price vs this tool) or prerequisites like wallet connection.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It lists return data but fails to indicate whether this is read-only, rate-limited, real-time or cached data, or what happens with invalid addresses.

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

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

Single sentence with no waste. Front-loaded with the verb 'Check' and efficiently lists the specific data points retrieved. Every word earns its place.

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

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

Lists return fields in lieu of an output schema, which is helpful. However, given no annotations and no output schema, the description should provide more behavioral context (e.g., read-only nature, blockchain scope) to fully equip the agent for proper 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 has 100% description coverage for the single 'address' parameter. The description implies the address is the wallet being checked but adds no syntax details, validation rules, or format examples beyond what the schema already provides.

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

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

The description clearly specifies what data is retrieved (ETH balance, $MEGACHAD balance, NFT count, burn eligibility, early access status) using a specific verb 'Check'. However, it does not explicitly differentiate from sibling tool 'get_portfolio' which likely overlaps in functionality.

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 provided on when to use this tool versus alternatives like 'get_portfolio' or 'get_nft_metadata'. No prerequisites, conditions, or explicit exclusions 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 must cover behavioral traits. It states the output fields and notes 'recent' proposals but does not clarify if the operation is read-only, how pagination works, or the default ordering. Missing critical details for a list endpoint.

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 front-loads the verb and resource, followed by key output details. It is highly concise with 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 tool with one optional parameter and no output schema, the description covers the main output fields. However, it omits the default limit, pagination details, and explicit ordering, leaving some minor 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?

The schema has 100% description coverage for the single 'limit' parameter. The description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.

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

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

The description clearly states the verb 'list' and the resource 'Jestermogger governance proposals', and enumerates the fields included (state, vote tallies, timing, URLs). It distinguishes from sibling tools like 'get_governance_proposal' (singular) and 'build_vote_tx' (transaction building).

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 like 'get_governance_proposal'. The sibling context hints at a listing vs. single retrieval but no direct comparison or exclusion criteria are provided.

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

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

No annotations provided, so description carries full burden. It successfully discloses the on-chain eligibility check mechanism and return values (referral code and access status). Missing explicit warnings about mutation side effects or idempotency, but 'Register' implies state change.

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 efficient sentences with zero waste. First sentence establishes action and scope; second sentence covers validation logic and return values. Appropriately front-loaded.

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

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

Given no annotations and no output schema, the description adequately covers the return values (referral code, status) and eligibility prerequisites. Sufficient for a registration tool of this complexity, though gas costs or idempotency notes would improve it further.

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 100% description coverage (wallet, twitter, referralCode), establishing baseline 3. Description adds value by contextualizing wallet eligibility requirements and clarifying that referralCode relates to returned referral codes, but does not add extensive syntax or format details beyond the schema.

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

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

Clear specific verb (Register) + resource (wallet) + scope (MegaChad testnet beta access). Distinguishes from sibling register_referral_agent by specifying user 'wallet' registration for 'beta access' versus agent registration, though could explicitly name the sibling for absolute clarity.

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

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

Provides eligibility criteria ($MEGACHAD balance or looksmaxxed NFTs) which implies prerequisites for usage, but lacks explicit when-to-use guidance contrasting with register_referral_agent or other tools.

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

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

Discloses critical return values (transaction calldata and referral code) and financial incentive structure (10% earnings) necessary without output schema, but omits idempotency rules, error conditions, and explicit state-change warnings expected given no annotations.

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

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

Three efficient sentences logically structured: action statement, return value disclosure, and economic incentive. No redundancy or filler content.

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

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

Adequately compensates for missing output schema by describing return format and compensates for missing annotations by explaining the earning mechanism, though could clarify transaction execution expectations.

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

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

Input schema provides 100% description coverage; description adds no parameter-specific semantics beyond the schema but meets the baseline requirement for high-coverage schemas.

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?

Clear verb 'Register' and specific resource 'MegaChad referring agent' effectively distinguishes this from sibling tools like register_early_access through domain-specific terminology.

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 (e.g., register_early_access) or prerequisites such as checking existing registration status via get_agent_info first.

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