Diogenes Gateway

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

With no annotations and no output schema, the description carries the full burden. It usefully discloses a real cost gate ('100 sats via L402'), which is genuine behavioral context. However, it leaves a critical ambiguity unresolved: whether the tool only plans/maps sequences or actually executes the MCP calls and JSON-RPC payloads, and what the response looks like.

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 front-loaded sentence with no filler; the scoping clause and the cost parenthetical both earn their place. Slightly dense grammar (nested 'to ... and ... (cost)') costs it a point but nothing is wasted.

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 routing tool with no annotations and no output schema, the description covers purpose and cost but omits the execute-vs-plan distinction and any indication of the return payload. It is minimally adequate rather than 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 there is only one parameter ('objective', described in-schema), so the schema already does the work. The description adds no format, constraint, or example meaning beyond it, making the baseline 3 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?

States a specific verb and resource: maps agent goals to deterministic MCP tool call sequences and JSON-RPC 2.0 payloads. That is far more concrete than a tautology, but it never names or contrasts itself with near siblings like agent_schema_enforcer or eve_gate_route_planner, so an agent must infer the boundary.

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 when-to-use guidance, no when-not-to-use, and no alternative named. The agent learns what the tool produces but nothing about the conditions that should select it over the many sibling routing/planning tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose a genuine behavioral constraint that structured data lacks: the tool costs 75 sats and is paid via L402, which tells the agent an auth/payment step is required. It omits, however, what happens on validation failure (error vs. healed output), whether input is mutated, and any rate limits, leaving meaningful gaps.

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

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

One front-loaded sentence that wastes nothing: the three operations come first and the cost constraint is tucked into a parenthetical. Every clause carries 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 tool with 0% schema coverage, no annotations, no output schema, and a nested-object parameter, the single-sentence description is far too thin. It does not explain the parameters, the return value, or failure behavior, so an agent cannot reliably invoke it beyond guessing from the name.

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 two parameters (a nested object `schema` and a required string `raw_output`) are undocumented everywhere. The description's mention of 'type healing' loosely implies raw_output, and the 'schema' object implies the validation target, but it never explains the schema/raw_output relationship or what happens when `schema` is omitted.

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 three concrete operations (JSON Schema validation, type healing, hallucination pruning) on a clear resource, so the agent knows it is a schema-validation/repair tool. However, it never differentiates itself from close siblings like json_repair or guardrail_verify, which an agent could easily confuse with this 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?

There is no when-to-use guidance, no conditions selecting this tool over json_repair or guardrail_verify, and no mention of prerequisites beyond the pricing note. The agent is left to infer usage entirely.

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, and it does disclose two genuine behavioral facts: execution is sandboxed/isolated ('Secure') and each call costs $0.15 USDC on Base via MPP. That payment model is real value the schema cannot express. However, it omits execution limits (timeout, memory, network access), whether the sandbox is ephemeral, and what happens on failure — significant gaps for a code-execution 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?

A single tight sentence with the resource front-loaded and cost information parenthetically appended. Every clause earns its place, though it is arguably sparse for a tool with real runtime semantics.

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 one-parameter tool, the description is minimally adequate: it says what runs, where, and at what cost. Without annotations or an output schema, it should at least sketch what the call returns (stdout/stderr/exit status) and any timeout or isolation constraints; those are missing.

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

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

One parameter with 100% schema description coverage ('Python code to execute'), so the schema already does the work. The description adds nothing about the code argument (e.g. permitted imports, whether output is captured). Baseline 3 applies per the coverage rule.

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 specific verb and resource: executing Python code inside a sandbox. It is unambiguous and no sibling tool in the list competes with it (none are code-execution utilities). It stops short of a 5 only because it doesn't state the scope of what 'execution' means (single script, isolated runtime, no file persistence).

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 when-to-use guidance, no prerequisites, and no exclusions. The pricing hint ('$0.15 USDC via MPP on Base') implicitly signals this is a paid call to be used deliberately, but the agent is left to infer that. Nothing tells the agent when another sibling (e.g. regex_oracle, json_repair) would be the better choice.

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 behavioral burden. It does disclose a notable trait — the 250 sats L402 payment — which is genuinely useful. However, it says nothing about what happens on payment failure, latency, or the form of the audit result, leaving significant behavioral gaps.

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

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

A single tight sentence that front-loads the tool's purpose and appends the payment requirement. Nothing is wasted, though the pricing clause sits somewhat awkwardly alongside the purpose statement.

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?

Parameters are fully covered by the schema and there is no output schema to explain, but with no annotations and no return-value description, the definition is only minimally complete for a paid audit tool. Details about the audit result format or failure modes are absent.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no additional meaning about 'network' or 'code_or_address', so the baseline of 3 applies.

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 gives a specific verb (audit) and resource (smart contract) plus the exact scope of checks: honeypot, tax, and mint backdoor. This clearly differentiates it from sibling risk tools like mev_risk, solana_risk, and guardrail_verify.

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

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

There is no guidance on when to use this tool versus mev_risk or solana_risk, nor any mention of prerequisites or expected inputs beyond the schema. The audit scope implies a use case but never states it, so the agent must infer.

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 exist, so the description carries the full burden. It does disclose two genuinely useful behavioral traits: the routes are non-KYC and the call is paid (100 sats via L402), which materially affects invocation. However, it says nothing about whether the quote expires, what payment flow is required (invoice/invoice header), rate limits, or error behavior on unsupported pairs.

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 front-loaded sentence with no filler; the core action and venues come first and the payment note trails. It avoids bloat, though the brevity borders on under-specification given the undocumented parameters.

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?

Three required, zero-documented parameters, no annotations, and no output schema mean the description must do more work than it does. It never clarifies return shape (since no output schema exists, an agent cannot know if it gets a single route, a list, or a price), nor the asset/amount formats needed to 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% and all three parameters are required with no type-level documentation. The description supplies no meaning for from_asset/to_asset (ticker? chain-qualified? contract address?) or for amount (units, decimals, whether the 100 sats figure is the fee or a valid sample). This is the definition's largest gap and is not compensated anywhere.

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 gives a specific verb ("Compares") plus resource ("cross-chain settlement routes") and even names the three venues (THORChain, Blockstream Liquid, Maya), so an agent can immediately tell this is a route-comparison/quotation tool. It does not need sibling differentiation because no other tool in the list overlaps. It stops short of a 5 because it never says whether the output is a single best quote or a ranked comparison.

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 the general scenario (comparing settlement routes) but gives no when-to-use or when-not-to-use condition, no prerequisites, and names no alternative tool. The only actionable usage signal is the implicit cost (100 sats via L402), which is a hint rather than guidance.

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

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

With no annotations at all, the description carries the full burden, but it does disclose one genuinely useful behavioral trait: the call costs 100 sats via L402, so the agent knows an authorization/payment step is involved. It says nothing about caching, rate limits, or whether a failed route still incurs the charge, so the disclosure is partial.

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

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

One sentence, front-loaded with the core purpose and with the price appended as a parenthetical rather than buried mid-sentence. Slightly compressed to the point of being terse, but there is no wasted text.

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 annotations, no output schema, and a third of parameters undocumented mean the description must explain the return value (route, jump count, fuel, toll) and cost semantics. It covers neither, so an agent cannot predict what it gets back or when it is charged.

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 only 33%: optimize_for is described in the schema while origin_system and destination_system are bare strings, and the description adds nothing about expected system-name format or how the three optimization modes interact. For low coverage the description should compensate, and it does not.

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 gives a specific verb-and-resource ('routing optimizer') and scopes it to 'gate toll and fuel' across 'EVE Frontier star systems', which is enough to distinguish it from siblings like eve_network_node_gj_optimizer. It stops short of naming an alternative or clarifying how it differs from other EVE routing tools, and 'Smart' is filler.

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 statement of when to use this tool versus alternatives, no prerequisites (e.g. systems must be in EVE Frontier), and no note on what happens when origin equals destination. The only contextual cue is the price, which is not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a genuine non-obvious trait — cost and payment mechanism (200 sats via L402) — but says nothing about what the tool produces, whether code is deployed or merely returned, or any side effects of a code-synthesis 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?

A single front-loaded sentence with no filler, leading with the action and resource, with the cost caveat parenthesized at the end. Efficient, though arguably too terse for a tool that both generates and audits contracts.

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 code-synthesis tool with no output schema and no annotations, the description omits critical context: what form the output takes (source code, diff, audit report), whether it writes or deploys anything, and whether the L402 payment is required before or after the call.

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

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

Schema description coverage is 100%, so both parameters (assembly_id, contract_type with its enumerated values) are already documented in the schema. The description adds no additional parameter meaning, which is the expected baseline when the schema does the work.

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?

States specific verbs (synthesizes, audits) and a precise resource (Sui Move contract extensions for EVE Frontier Smart Assemblies). This domain specificity separates it from the generic sibling contract_audit, though the dual synthesize/audit purpose leaves some ambiguity about which mode is primary.

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 choose this over contract_audit, code_sandbox, or agent_schema_enforcer — all plausible alternatives for the same task. The 'audits' wording actively overlaps with the contract_audit sibling without resolving which to call.

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 behavioral burden, and it does disclose one genuinely useful trait: '100 sats via L402', which signals a paid/Lightning-gated operation. However, it never states whether the tool reads or writes state, what happens to existing reservations, or what permissions are needed, so the majority of the behavioral profile is missing.

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 text is short and jargon-dense, so it is not bloated, but it is a single unpunctuated fragment that leads with feature nouns instead of the tool's action. It is under-specified rather than truly concise, and nothing is front-loaded for fast selection.

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 annotations, no output schema, and 0% param coverage mean the description must be self-sufficient, yet it leaves purpose, action type, return format, and parameter meaning unresolved. For a 2-parameter tool with a required node_id, this is not enough for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. 'GJ energy reservations' loosely maps to reserve_gj, but node_id is never explained and no units, ranges, or required-vs-optional semantics are given. Two parameters remain largely undocumented across both schema and description.

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

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

The description is a noun-phrase fragment listing topics ('fuel burn, GJ energy reservations, and offline-threat windows') rather than a verb-plus-resource statement of what the tool does. The name implies an 'optimizer' role, but the text never says whether it computes, reserves, reads, or mutates anything. An agent cannot confidently tell the action apart from sibling tools.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative or sibling tool. The only routing hint is the implicit 'Lagrange Network Node' domain, which is contextual coloring rather than actionable selection guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely non-obvious trait: the call costs 100 sats via L402, which implies a payment/auth step the agent must be prepared for. However, it says nothing about the outcome semantics (does it block, warn, or return a verdict?), whether the operation is read-only, or latency/failure 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?

A single dense sentence with the function stated first and the detection targets and cost following. Every clause carries information; there is no filler or redundant restatement of the name.

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 two-parameter tool this covers purpose and cost well, but with no output schema present the description should at least characterize the return value (a verdict? a boolean? a report?) so the agent knows what to do with the result. The payment model is mentioned but recurring-per-call versus one-time is ambiguous.

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% for both parameters, so the schema already documents 'payload' and 'action_type' fully. The description adds no parameter-level detail (no examples of accepted action_type values, no size limits on the payload), so baseline 3 applies.

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 specific function (pre-execution security gate) and enumerates exactly what it detects: prompt injection, wallet drain, and key exfiltration. That is far more precise than a tautology, but it never differentiates itself from the nearby risk-oriented siblings (mev_risk, solana_risk, contract_audit), leaving an agent to infer the boundary.

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 phrase 'pre-execution security gate' clearly signals the context of use: invoke it before running a command, script, or prompt. No alternatives exist among the siblings for this kind of payload inspection, so no exclusion routing is needed, but the description stops short of explicitly stating prerequisites or when NOT to bother calling it.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the cost and payment mechanism (50 sats via L402), which is real context an agent needs before calling. However it omits what happens on unrepairable input, whether output is deterministic, and whether it truncates or errors.

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 economical sentence with no filler, and the payment clause is appended rather than buried. It is front-loaded with the core function.

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

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

There is no output schema, so the description was responsible for explaining what comes back (a repaired JSON string? a diff?), and it does not. For a sanitization tool where the caller must know the success/failure shape, this is a notable 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?

Only one parameter, and the schema already documents it at 100% coverage, so the baseline of 3 applies. The description adds no format or type detail beyond "malformed JSON string".

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?

States a specific verb+resource: repairing/healing malformed JSON. This clearly distinguishes it from siblings like regex_oracle or code_sandbox, which handle different inputs. The wording "autonomous ... healer" is slightly promotional but the function is 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?

No guidance on when to use this versus validating parsing yourself, code_sandbox, or agent_schema_enforcer. The only conditional information given is the price, not the selection 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?

With no annotations, the description carries the full behavioral burden. It discloses a real trait not in any structured field: the tool costs 150 sats via L402, so the agent knows payment/authentication is required. Beyond that it says nothing about the return format, latency, or whether it is read-only, leaving significant gaps.

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

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

A single front-loaded sentence with zero waste; the core purpose and the pricing caveat are both packed in efficiently. It is terse rather than padded, though the brevity contributes to the gaps elsewhere.

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 tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It states what the tool audits and what it costs but leaves parameters and return shape entirely 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?

Schema description coverage is 0% across 4 parameters, yet the description adds no meaning for dex, token_in, token_out, or slippage_bps. At low coverage the description is expected to compensate, and it does not, so the agent must guess at parameter formats (token addresses, dex identifiers, slippage units).

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?

States a specific verb+resource: a pre-swap auditor for MEV sandwich and frontrunning risk. An agent understands exactly what it does. It doesn't differentiate from the related sibling solana_risk, so it falls short of a 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?

"Pre-swap" implies when to call it (before executing a swap), which is useful temporal context. However, it names no alternatives and gives no explicit when-not conditions versus siblings like solana_risk or contract_audit, leaving the agent to infer routing.

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, and it does disclose a genuinely important behavioral trait: the tool costs $0.10 USDC via MPP on Base, which is critical for an agent deciding whether to invoke it. However, it says nothing about latency, depth/length of output, failure modes, or how payment is actually executed.

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

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

One sentence, front-loaded with the core capability and the cost constraint appended. No filler; every clause carries 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 one-parameter paid research tool with no annotations and no output schema, the description covers what it produces and what it costs but omits what the dossier actually contains, expected latency, and the mechanics of the USDC payment. Adequate but with clear gaps.

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

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

Schema description coverage is 100% for the single 'query' parameter, so the schema already documents it and the description adds no syntax, scoping, or format guidance. Baseline 3 applies when the schema does the heavy lifting.

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 'Deep research dossier with live citations' conveys the specific resource produced and its distinguishing quality (depth + citations), which separates it from the lighter web_brief sibling. It stops short of a clear verb (produce/generate) but the intent is 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?

There is no statement of when to choose this over web_brief or any other research sibling, nor any prerequisites (e.g., wallet/payment setup required before calling). The agent must infer usage entirely from the name and the price note.

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 does disclose real behavioral traits beyond the name: the output is ReDoS-safe, it is validated by automated tests, and invocation requires an L402 payment of 50 sats. It omits rate limits, failure behavior, and what exactly is returned (pattern only, or pattern plus tests).

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 front-loaded sentence with no filler; the core function (ReDoS-safe regex synthesis with test validation) leads and the payment clause trails. The parenthetical 'L402' is jargon but is the only term carrying the payment prerequisite.

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 annotations and no output schema, so the description is the sole source of behavior. It covers what the tool produces and that payment is required, but leaves the return shape, error behavior, and any constraints on the requirements string unspecified. Adequate but with clear gaps for a no-schema 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?

One parameter with 100% schema description coverage, so the schema already documents 'description' as 'Pattern requirements'. The description adds no syntax, format, or example for that input, so it does not go beyond structured data. Baseline 3 applies.

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?

States a specific verb+resource: it synthesizes regex patterns, with two distinguishing qualifiers (ReDoS-safe, automated test validation). An agent can tell what comes out of it. It does not, however, compare itself to any sibling (none of which overlap in domain), so it stops short of full differentiation.

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 rather than stated: you supply pattern requirements and get a regex back. There is no explicit when-to-use, when-not-to-use, or alternative named. The one prerequisite-like detail disclosed is the 50 sat / L402 payment, which is useful context but not routing guidance.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait: this is a paid call ($0.02 USDC via x402 / 100 sats via L402), which warns the agent of billing and an auth/payment flow. However, nothing is said about what kinds of risk are assessed, latency, rate limits, or failure behavior, so the disclosure is partial.

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

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

One sentence that front-loads the tool's purpose and appends the cost parenthetical; nothing is wasted. The x402/L402 pricing shorthand is dense jargon, but it is compact rather than bloated, keeping it short of a perfect score only because the payment mechanics are cryptic as written.

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 and no annotations, the description is minimally adequate: it identifies the resource and the payment model. It stops short of explaining what the risk evaluation returns or how to interpret it, leaving the agent unable to anticipate the response shape.

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% and the single parameter is well documented as 'Solana mint or wallet pubkey', so the schema already does the work. The description adds no further parameter semantics beyond confirming that both tokens and wallets are in scope, which is the expected baseline when the schema is complete.

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 specific resource — Solana SPL token and wallet risk — and implies the operation (evaluation). It is clearly distinct from generic tools like web_brief or regex_oracle, but it does nothing to separate itself from the closer siblings mev_risk and contract_audit, so an agent could not tell from the text alone which risk tool fits a given query.

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 when-to-use guidance, no stated prerequisites, and no mention of alternatives such as mev_risk or contract_audit. The only contextual information is pricing, which tells the agent the call costs money but not when the call is warranted.

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 behavioral burden, and it does disclose one meaningful trait: a 200-sat L402 payment is required to invoke it, which is genuinely useful pre-call context. However, it says nothing about latency, rate limits, failure modes, or how grounding/citations behave when the search finds nothing.

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 dense sentence that front-loads the deliverable, then citations, format, and price. Nothing is wasted, though the L402/sats jargon could obscure the core purpose for an unfamiliar agent.

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, so the description must describe returns; 'strict JSON' with citations is only a partial answer, and the concrete JSON shape is left unspecified. The payment disclosure helps, but response structure and error behavior are missing for a tool whose whole value is its structured output.

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

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

One parameter with 100% schema description coverage, so the schema already documents 'topic' as the research query. The description adds no syntax, length, or formatting constraints beyond what the schema states, so baseline 3 is correct.

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?

States a specific output ('grounded real-time market intelligence brief with live Google Search citations') and format ('strict JSON'), so the agent knows this is a research-brief generator. It does not explicitly differentiate from the closest sibling, mpp_deep_search, but the 'market intelligence brief' framing is reasonably distinctive.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as mpp_deep_search. The only usage-relevant signal is the implied cost, which is not framed as a decision criterion.

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