baseoracle

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

With no annotations, the description carries the full burden. It does disclose that the tool verifies source code, ABI, and proxy detection via BaseScan, giving some behavioral detail. However, it does not explicitly state that it is read-only, what happens if the contract is not verified, or whether network access is involved.

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?

A single, concise sentence that front-loads the action and scope. Every phrase adds meaning, leaving no redundant or vague language.

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

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

The tool is simple (one param, no output schema), but the description omits what the agent should expect as a result (e.g., boolean, detailed report, or error if unverified). It covers the input scope but not the output contract, which is a gap given the absence of an output schema.

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

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

The only parameter, contract_address, is implicitly explained by the description ('Verify Base smart contract'), and its role as an address is self-evident. There is no schema description coverage, but the tool name and description ensure basic understanding. Details like address format or chain constraints are not provided.

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

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

The description clearly states the verb 'Verify' and the resource 'Base smart contract', and it enumerates specific aspects (source code, ABI, proxy detection) that distinguish it from the sibling tools, which focus on yields, gas, and other chain 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?

The tool's purpose is immediately clear from the description: it is for verifying contracts on BaseScan, which is a distinct use case from the DeFi and analytics tools listed as siblings. No explicit exclusions are given, but the context alone provides sufficient guidance.

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

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

There are no annotations, so the description carries the full burden for behavioral disclosure. It does not mention whether the operation is read-only, how results are sorted or paginated, what 'top' means (e.g., by yield vs. TVL), or any defaults for the parameters. The description is too minimal to convey these important behavioral traits.

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

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

The description is a single concise sentence with no fluff. It is front-loaded with the key purpose. However, it is slightly under-specified, lacking detail that could easily be added without making the description bloated, so it earns a 4 rather than a 5.

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

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

With no output schema and no annotations, the description should explain return values, sorting, and possibly differentiate from siblings like base_protocol_tvl. It does none of this. The tool has only two parameters, but the lack of return format and selection criteria makes it incomplete for an agent to fully understand what it will get.

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

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

Schema coverage is 0%, so the description must explain the parameters. It only addresses 'min_tvl_usd' implicitly through 'filtered by TVL' but does not explain 'limit' or its default behavior. The parameter meanings are not fully clarified beyond what the schema already shows (e.g., default values).

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

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

The description clearly states the tool lists top DeFi yield opportunities on Base, filtered by TVL. It is specific about the resource (DeFi yields on Base) and the action (listing top opportunities), and it distinguishes itself from sibling tools like base_gas or base_overview.

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

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

The description provides clear context for when to use this tool: when the user needs top DeFi yield opportunities on Base. It does not explicitly mention alternatives or exclusions, but the purpose is distinct enough from siblings that the context is clear without needing to name them.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states that the tool provides USD cost estimates, indicating a read-only reporting behavior. However, it doesn't detail the response structure, whether it gives real-time or historical data, or any side effects. For a simple tracker, this is adequate but not rich.

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, concise sentence that front-loads the main purpose ('Base network gas tracker') and adds a useful comparison ('much cheaper than Ethereum mainnet'). Every word contributes value, and there's no fluff.

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

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

For a zero-parameter tool with no output schema or annotations, the description is reasonably complete. It tells what the tool does and what it provides (USD cost estimates), which implies the response will include gas price and cost. It could be more explicit about the exact return fields, but for the tool's simplicity, this is sufficient.

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

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

The tool has zero parameters, so the description doesn't need to explain input semantics. The baseline for no parameters is 4, and the description adds context about what the tool does, which is sufficient for a no-input tool.

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

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

The description clearly states the tool's function: 'Base network gas tracker with USD cost estimates'. It identifies the specific resource (Base network gas) and the action (tracking with cost estimates), distinguishing it from sibling tools like base_contract_verify or base_protocol_tvl which serve different purposes.

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

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

The description implies usage for tracking gas fees on Base network, and the note 'much cheaper than Ethereum mainnet' provides context for network choice. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is inferred but not openly guided.

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 burden of behavioral disclosure. It lists the data fields included (ETH price, cbETH, gas, TVL, OP Stack info), which implies a read-only aggregation, but it does not explicitly state that it is read-only, nor does it disclose any potential latency, data source mixing, or limitations. It is adequate but not detailed beyond the content list.

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, concise sentence that immediately states the tool's purpose and lists key data categories. There is no wasted wording, and the structure is front-loaded with the primary action ('Base L2 ecosystem overview') followed by specifics.

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

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

For a simple, no-parameter overview tool, the description provides adequate context about the data covered. However, 'OP Stack info' is somewhat vague, and there is no explicit mention of the output format or how the data is aggregated. Still, the tool's simplicity means the description is reasonably complete without an output schema.

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

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

The tool has zero parameters and the schema is trivially covered by the existing empty properties object. According to the rubric, a 0-parameter tool earns a baseline of 4; the description adds context about the scope of the output, which is helpful but not required for parameter semantics.

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

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

The description clearly states the tool's purpose: it provides a Base L2 ecosystem overview including ETH price, cbETH, gas, TVL, and OP Stack info. The verb 'overview' and the specific resource 'Base L2 ecosystem' distinguish it from sibling tools that focus on individual metrics like gas or TVL.

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

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

The description implies usage for a high-level overview of the Base L2 ecosystem, but it does not explicitly state when to use this tool versus the more specialized sibling tools (e.g., base_gas, base_protocol_tvl). There are no exclusions or alternative recommendations, leaving the decision to the agent based on the overview nature.

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

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

With no annotations provided, the description must fully disclose behavior. It reveals one key behavioral rule (empty param returns top-20 list), but omits other important traits such as whether this is a read-only operation, what happens when an invalid protocol is specified, or any rate limits. Given the absence of annotations, this is insufficient for full transparency.

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

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

The description is a single, two-clause sentence that immediately states the tool's purpose and then gives a crucial usage hint. No redundant words, no restating of the tool name. It is optimally front-loaded and 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 tool's simplicity (one optional parameter, no output schema), the description covers the essential behavior: what it does and the empty-parameter special case. However, it could be more complete by mentioning the output format (e.g., a number, an array) or handling of unknown protocols, but these are minor for a tool this straightforward.

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 provides no description for the 'protocol' parameter (0% coverage), so the description compensates by explaining that leaving it empty yields a top-20 list. This clarifies the parameter's optionality and default behavior, which is the critical semantic detail. However, it doesn't specify the expected format (e.g., name vs. slug), leaving some ambiguity.

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 this tool provides TVL data for Base DeFi protocols, with 'Leave protocol empty for top-20 list' specifying special behavior. However, it lacks an explicit verb like 'get' or 'fetch', and it doesn't explicitly distinguish from the sibling base_defi_yields beyond the name and TVL mention.

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 instruction 'Leave protocol empty for top-20 list' gives clear guidance for the optional parameter, but there is no explicit statement about when to use this tool over alternatives like base_defi_yields or base_overview. Usage context is implied through the tool name and TVL focus, but no exclusions or alternatives are named.

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?

There are no annotations, so the description carries the full burden of exposing behavior. It merely states a topic and provides no information about whether this is a read operation, what output to expect, or any side effects.

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

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

The description is a single sentence with no filler, but its structure as a noun phrase rather than a functional statement limits its usefulness. It is concise, though the content could be more action-oriented.

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

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

Given no output schema and no annotations, the description should explain what the tool returns and how to use it. It does neither, leaving the agent with only a vague topic label and a hint at protocol values. This is inadequate for a tool with one optional parameter.

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

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

The schema's single 'protocol' parameter has no description (0% coverage). The description lists Moonwell, Aave, Compound, and 'RWA protocols', which hints at possible parameter values, but it does not explicitly connect these to the protocol parameter or explain how the parameter controls behavior.

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 names a resource area ('Real-world assets and institutional lending on Base') and lists associated protocols, but it lacks an action verb or explicit statement of what the tool does. It vaguely distinguishes from siblings by topic, but not by function.

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

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

No guidance is provided on when to use this tool versus alternatives like base_defi_yields or base_protocol_tvl. There is no mention of conditions, exclusions, or preferred contexts.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Peg check' is vague: it does not specify what the tool returns (e.g., price, deviation percentage), whether it reads live on-chain data, or how it handles invalid symbols or missing parameters. This is a significant transparency 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, front-loaded sentence that immediately identifies the tool's purpose. Apart from minor redundancy ('Base' and 'Base L2'), every word contributes value and the length is appropriate for the tool's simplicity.

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

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

Given no output schema and no annotations, the description should at minimum state what the peg check returns and clarify the role of contract_address. It does not, making the tool under-specified for an agent to invoke confidently.

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

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

Schema description coverage is 50% (only 'symbol' has a description). The tool description repeats the allowed symbols but adds little context about 'USDbC' vs 'USDBC' and completely ignores 'contract_address', whose purpose remains unexplained. The description does not compensate for the missing parameter semantics.

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

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

The description clearly states the tool performs a 'peg check' for stablecoins (USDC, USDbC, DAI) on Base L2. This specific verb and resource distinguish it from sibling tools like base_contract_verify, base_defi_yields, and base_rwa.

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 this tool should be used when checking whether stablecoins on Base L2 maintain their peg, but it offers no explicit guidance on when to choose it over alternatives or when not to use it. Context is clear but exclusions are 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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the outputs (ETH balance, recent transactions) but does not explicitly confirm that the tool performs a read-only operation, nor does it mention any limitations like data freshness, pagination, or address validation requirements.

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

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

The description is a single concise sentence that front-loads the essential information: wallet intelligence, ETH balance, and recent transactions on Base L2. There is no wasted wording.

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

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

The tool is simple with one parameter and no output schema, but the description still leaves important gaps: the address format is unspecified, 'recent transactions' is ambiguous regarding depth or time range, and no usage context is provided. For a wallet tool, users would expect more detail about the return structure or limitations.

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 a single 'address' parameter with no description (0% coverage). The description does not explain expected format (e.g., 0x-prefixed, checksummed) or any constraints. This is a critical gap since the description must compensate for the lack of schema detail.

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

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

The description clearly identifies the tool as providing wallet intelligence for Base L2, specifically ETH balance and recent transactions. It distinguishes itself from sibling tools like base_gas or base_protocol_tvl by focusing on wallet data. However, it lacks an explicit verb like 'get' or 'fetch', so it's not a perfect 5.

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

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

The description gives no guidance on when to use this tool versus alternatives. The sibling tools are contextually related but no exclusions or preferred use cases are mentioned, leaving the agent to infer.

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