Autosophia Base Lens

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 per-call cost, typical latency, and a detailed breakdown of the response content, which is more transparent than most definitions. This is particularly valuable for an agent estimating cost and runtime before invocation.

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 short sentences front-load the core purpose, then add cost and latency context, then enumerate return data. There is no filler or redundancy; every sentence contributes necessary 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?

For a parameterless query tool without an output schema, the description supplies essential behavioral and output information: pricing, latency, and the specific fields returned. Minor omissions like units (e.g., Gwei) and response format prevent a perfect score, but the tool remains fully understandable.

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 100% schema coverage, so there are no parameter semantics to explain. The description appropriately focuses on output behavior rather than parameters, matching the baseline of 4 for parameterless tools.

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 tool as returning the current Base network gas price and enumerates the specific data returned (base fee, priority fee percentiles, congestion read, fee tiers). It is clearly distinct from sibling tools targeting wallets, payments, tokens, services, or transaction simulation, though it lacks an explicit verb.

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 use case is implied: obtain the current gas price on Base. However, there is no explicit guidance on when to prefer this tool over alternatives or any exclusions, though the sibling tools are unrelated enough that ambiguity is low.

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 full responsibility for behavioral disclosure. It states the per-call cost, confirms read-only semantics, and clarifies the curated token list limitation, which is meaningful beyond the basic 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?

The description is compact and front-loaded with the most important facts: what it is, cost, and read-only nature. It then provides return details and the only parameter definition without 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?

For a single-parameter read-only inspection tool with no output schema, the description sufficiently explains the return values, scope, limitations, cost, and required input format. Nothing critical is missing for an agent to select and call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does so by specifying that address must be a 0x-prefixed EVM address on Base, which adds the necessary format and chain context that the input schema lacks.

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 inspecting a wallet profile on Base, listing the specific return fields (ETH balance, nonce, contract/EOA status, curated token balances). It also differentiates itself from full portfolio enumeration by noting that requires an indexer on EVM, which helps distinguish it from broader lookup 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?

It implies when to use this tool for a quick, read-only wallet profile and explicitly excludes full portfolio enumeration. However, it does not directly reference sibling tools like screen_token or simulate_transaction, leaving the comparison to alternatives somewhat implicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only implies that the tool returns step-by-step instructions, but it does not explicitly state whether it only provides information, whether it performs any side effects, or how it behaves at runtime.

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

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

The description is very brief and front-loaded, which is good, but it is an incomplete sentence fragment. Brevity is achieved at the expense of clarity and completeness.

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 annotations and no output schema, the description should clarify the tool's scope and expected return content. 'How to pay, step by step' leaves the subject ambiguous and does not explicitly state what output the agent will receive.

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 100% schema description coverage, so there are no parameter details for the description to add. Baseline 4 applies because no parameter documentation is needed.

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

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

The description reads as a fragment: 'How to pay, step by step.' It conveys that the tool provides payment instructions, but it does not explicitly state what is being paid or what the tool does in a complete verb+resource form. It also does not distinguish itself from siblings like simulate_transaction or service_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?

There is no guidance about when to use this tool versus its alternatives. The description does not mention use cases, exclusions, or sibling tools, so an agent must infer when 'how to pay' maps to this tool.

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

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

With no annotations, the description carries the full burden. It discloses pricing, authentication requirements, output contents, and explicitly flags unavailable fields, noting they are marked 'not_available' and never guessed. It does not explicitly state that the tool is read-only, but 'screen' and 'returns' strongly imply it.

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 compact and well-structured with line breaks separating purpose/cost, outputs, limitations, and parameter guidance. Every sentence contributes unique information, with no filler 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?

For a single-parameter tool with no output schema, the description is nearly complete: it covers the input, network, return contents, limitations, and authentication. It lacks explicit error-handling details, such as behavior for invalid or non-ERC-20 addresses, which is a minor gap.

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

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

Schema coverage is 0%, yet the description fully compensates: 'address: 0x-prefixed ERC-20 contract address on Base' adds the required prefix format, contract type, and network. This is exactly the detail an agent needs beyond the bare 'string' 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 opens with 'ERC-20 token risk screen on Base,' naming a specific verb, resource, and network. It also enumerates concrete outputs (risk_score, signals, token metadata, slippage curve), making the tool's function unmistakable and clearly distinct from siblings like gas_price or inspect_wallet.

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 an ERC-20 token risk screening on Base is needed. It also states the lack of account/API-key requirements and the $0.01 cost. It does not explicitly name alternative tools or when-not-to-use conditions, so it stops short of a 5.

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 responsibility for behavioral transparency, yet it only describes the content ('what this server sells and its current limits') and not side effects, auth, or whether the call is read-only. The name hints at info, but the description itself offers no behavioral guidance.

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?

At two short sentences—'Start here. What this server sells and its current limits.'—the description is front-loaded with intent and contains zero 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?

For a zero-parameter overview tool, the description tells the agent where to start and what it will learn, which is adequate for calling it. It could be more complete by detailing the output contents, but the generic nature of 'what the server sells and its current limits' makes that less critical.

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 there is nothing for the description to add beyond the schema. Per the baseline for 0-parameter tools, this is adequately handled.

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 phrase 'Start here' combined with 'What this server sells and its current limits' clearly identifies this as an entry-point overview tool for service capabilities, distinguishing it from siblings like gas_price that target specific data. It lacks an explicit verb like 'get' but conveys the resource clearly.

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 'Start here' explicitly directs the agent to invoke this first, providing clear usage context. It does not mention when to avoid it or list alternatives, so it stops short of a full 5.

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 full responsibility for behavioral disclosure. It does an excellent job: it reveals the operation is non-mutating ('Never sends — simulation only'), explains the underlying mechanics (eth_call + eth_estimateGas), mentions the cost ($0.01 per call), and describes revert reason decoding. This goes far beyond a minimal description and fully informs the agent about side effects and behavior.

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

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

The description is compact and well organized. The first line front-loads the core purpose and safety guarantee, followed by cost, then mechanics, and then a clear parameter list. Every sentence contributes useful information; there is no fluff or redundancy. The structure makes it easy for an agent to quickly parse the essential facts.

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

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

Given the tool has no output schema, the description does not explicitly state the exact shape or fields of the return value, which is a minor gap. However, it does convey that the tool returns simulation outcomes and decoded revert reasons, which is the key information an agent needs to interpret results. The parameter documentation and behavioral notes are complete, so overall it is nearly comprehensive.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter is individually documented with data format expectations ('hex string starting with 0x', 'default empty call', 'ETH to send along, hex wei string', 'address to simulate as sender') and mentions defaults. This adds significant meaning beyond the bare schema property names and titles.

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: 'Preview a Base call before sending' with a strong disclaimer 'Never sends — simulation only.' It specifies the mechanism ('Runs eth_call + eth_estimateGas') and differentiates itself from any sending or read-only sibling by emphasizing simulation-only behavior. There is no ambiguity about what the tool does or where it fits among the sibling tools.

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

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

The description clearly establishes when to use it: before sending a transaction, to preview the result. It also explicitly states what it does not do ('Never sends'), which serves as a strong exclusion. While it does not explicitly name alternative sibling tools, none of the listed siblings perform simulation or anything similar, so the usage context is sufficiently clear without naming alternatives.

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