TrollBridge MCP

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

No annotations are present, so the description carries the full burden and does well: it discloses paid access ($0.02 USDC on Base or Solana via x402), the failure mode (402 instructions instead of data), and a 6-hour refresh cadence. Returned fields and caching semantics beyond the refresh interval are not described.

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 compact sentences, front-loaded with the resource and sources, then cost and failure behavior. A small amount of branding ('Mini's TrollBridge') is filler but does not obscure the operative 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?

With one optional parameter, no annotations, and no output schema, the description covers what an agent needs to decide and pay: coverage, cadence, cost, and the 402 fallback. It could say more about the shape of returned bounty items, but the essentials are present.

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 optional limit parameter, so the schema already documents range and default. The description's 'Optional limit 1-200' merely restates that; 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 resource (open bounties) with named sources (aibtc, Taskmarket, Superteam) and a refresh cadence. An agent can distinguish this from siblings like bridge_opportunities or bridge_deadlines without opening a schema.

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?

Clear context for when the tool is useful ('worth an agent's time') and an explicit access condition: it costs $0.02 USDC and returns 402 instructions if payment isn't possible. It does not compare itself against sibling tools, 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 the full burden, and it does deliver meaningful behavioral context: it is a paid tool ($0.02 USDC per call via x402 on Base or Solana) and it explicitly states failure behavior (returns 402 payment instructions instead of data). That is strong disclosure. It stops short of describing the return shape or ordering of results.

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 compact fragments, front-loaded with the resource, then payment terms, then the parameter. Every clause earns its place; nothing redundant or padded.

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 read tool with no output schema, the description covers purpose and payment mechanics adequately, but does not convey what a returned item looks like or how results are ordered, which matters when there is no output schema to fall back on.

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 single 'limit' parameter is fully documented in the schema (min 1, max 200, default 50). The description repeats 'Optional limit 1-200' without adding format or behavioral detail, so the 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 resource and scope: 'upcoming class-action and claim deadlines', with a clarifying gloss ('money with an expiry date'). An agent can tell it apart from siblings like bridge_bounties or bridge_opportunities, though it doesn't name those alternatives. Clear verb+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?

No when-to-use guidance and no named alternatives among the many sibling tools. The 'money with an expiry date' gloss implies the domain but doesn't tell the agent when to prefer this over bridge_opportunities or bridge_bounties. Usage must be inferred.

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 does well: it discloses the toll amount, the payment rails (Base or Solana via x402), and critically that a failed payment yields 402 instructions instead of data. It doesn't state rate limits or latency, but the cost/authorization profile is unusually well surfaced.

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 tight sentences, front-loaded with the tool's function followed by the cost model and fallback. The 'Mini's TrollBridge' branding is minor filler but costs almost nothing in length.

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, yet the description lists the returned data categories (type, balance, watchlist, risk flags) and explains the 402 failure mode, which is exactly what an agent needs before calling. Only the precise 402 payload structure and any rate limits are left unstated.

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 already documented with descriptions and an enum for network. The description merely restates 'requires address and network' without adding format, validation, or example syntax, so the schema does all 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 a specific verb+resource ('wallet address intel') and enumerates the returned fields (type, native balance, USDC watchlist, risk flags). None of the sibling tools (bounties, gas, prices, token_check, etc.) overlap this scope, so an agent can distinguish it immediately.

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?

Gives clear preconditions — both address and network are required, and payment of $0.05 USDC via x402 is mandatory — plus the fallback behavior when payment is unavailable. It does not explicitly compare against sibling intel tools, but no sibling covers this domain, so the guidance is practically complete.

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 does disclose two important behaviors: a $0.02 USDC toll per call via x402 on Base or Solana, and that failure to pay returns 402 payment instructions instead of data. This is meaningful behavioral context beyond the schema. It stops short of describing return format or pagination, keeping it at a 4.

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-loads the identity and scope before the pricing detail. Every sentence carries information, though the 'Optional limit 1-200' clause duplicates the schema and is wasted space.

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-required-parameter read tool with no output schema, the description covers purpose, cost model, and the payment-failure branch, which is what an agent most needs to avoid a broken call. Missing return-shape detail is minor given the tool's simplicity.

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 param is fully documented in the schema (range 1-200, default 50). The description's 'Optional limit 1-200' merely repeats the schema without adding semantics. 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 names a specific verb and resource ('bounties posted in the last 24 hours'), clearly distinguishing it from the generic bridge_bounties sibling. However, it never explicitly names or contrasts against bridge_bounties or other listing siblings, leaving differentiation to inference. A clear purpose, but not full sibling 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?

The 24-hour recency window implies a use case (finding fresh opportunities), and the payment prerequisite is stated. But there is no explicit when-to-use-this-vs-bridge_bounties guidance, and no mention of when the 24h window makes this the wrong choice. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses the tool is tolled ($0.02 USDC per call), the accepted payment chains and protocol (Base or Solana via x402), and crucially the failure behavior (returns 402 instructions instead of data). It stops short of rate limits, latency, or return shape.

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 tight sentences, zero waste, with the identity and the tolling/payment constraint front-loaded before the fallback behavior. 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?

For a zero-param read tool with no output schema, the description covers identity, cost, payment path, and the unpaid fallback, which is what an agent needs to invoke it correctly. Missing only minor details like return format breadth or per-chain coverage specifics.

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 parameters, so the baseline is 4. The description confirms 'No params', which is consistent with the empty schema and leaves nothing ambiguous.

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?

It states a specific verb+resource ('live gas prices per chain') and adds an audience qualifier ('for agents about to move money'). It does not explicitly name a sibling like bridge_prices, but the resource is specific enough to distinguish it from the other bridge_* 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 phrase 'for agents about to move money' implies the usage context, and the toll notice implies a payment prerequisite. However there is no explicit when-not guidance or named alternative (e.g. bridge_prices) for agents who want prices without paying.

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 usefully discloses the cost profile ('FREE', 'No toll') and roughly what the response reports, which is real behavioral value. But it says nothing about auth requirements, rate limits, latency, or failure modes, and the metaphorical phrasing leaves the actual behavior under-specified.

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 the function stated first. It is tight, though branding ('Mini's TrollBridge') and metaphoric terms ('lanes', 'toll') consume space without adding precision.

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 tool with no output schema and no annotations, the description adequately conveys what it returns and that it is free. The main missing piece is any usage routing relative to the many sibling tools, but the core completeness for calling it correctly is present.

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 takes zero parameters, so the baseline is 4. There are no arguments whose semantics could be clarified, and the description does not need to compensate for any gaps.

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 states a specific verb+resource ('health check' for 'the bridge') and enumerates what the check reports: awake status, lane count, marketplace status. This distinguishes it from data-oriented siblings like bridge_prices or bridge_markets. However, playful terminology ('Mini's TrollBridge', 'lanes', 'toll') is ambiguous and could confuse an agent about what the fields actually mean.

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 or when-not-to-use guidance is given, and no sibling is named as an alternative. The 'FREE / No toll' note hints at a cost dimension versus other tools but never states when an agent should call this versus, say, bridge_tools or bridge_fresh. Usage must be inferred 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 behavioral burden and does so unusually well: it discloses the $0.05 USDC toll, the Base/Solana rails via x402, and the critical fact that an unpaid call returns 402 payment instructions instead of data. Gaps remain around rate limits, caching/freshness of odds, and failure modes beyond non-payment.

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 key facts (what it returns, its cost, its failure behavior) are front-loaded into three compact clauses with no wasted sentences. Minor inflation comes from branding ('Mini's TrollBridge') and the redundant parameter restatement at the end.

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 with no output schema, the description adequately characterizes the return payload ('live Polymarket odds, prices, and volume') and explains the non-obvious tolling/payment contract. Only the absence of freshness or rate-limit context keeps it short of 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 description coverage is 100%, so both parameters are already fully documented with examples and defaults in the schema. The description's 'Requires q; optional limit 1-25' merely restates the schema without adding syntax or search-semantics guidance, 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 domain verb+resource: prediction-market intel, live Polymarket odds, prices, and volume. That domain framing distinguishes it from generic siblings like bridge_prices or bridge_search, though no sibling is named explicitly. The brand preamble ('Mini's TrollBridge') and 'agent-ready JSON' are filler rather than 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?

There is no explicit guidance on when to choose this tool versus alternatives such as bridge_prices or bridge_search; usage is only implied by the 'prediction markets' framing. The one strong usage-adjacent signal is the payment condition and its fallback, which tells the agent when the call will fail rather than when 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?

With no annotations, the description carries the full burden and does so well: it discloses the tolled cost ($0.02 USDC per call), the payment rails (Base or Solana via x402), and the failure mode (returns 402 payment instructions instead of data if you cannot pay). This is exactly the behavioral context an agent needs before invoking a paid 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 pricing and payment-failure information is front-loaded and every clause after the brand prefix earns its place. The only mild waste is the branding lead-in ('Mini's TrollBridge'), but the substance is dense and well-ordered.

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, the description must convey what comes back, and it does: catalog data with per-token pricing and free-model flags, or a 402 payment response. For a single-optional-param read tool with a paywall, nothing material is 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?

Schema description coverage is 100% and the single limit parameter is fully documented in the schema, including the range and default. The description's 'Optional limit 1-200' merely restates the schema, adding no syntax or meaning beyond it. 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 verb+resource: an AI model catalog with 107 models, per-million-token pricing, and free models flagged, sourced from BlockRun.AI. This is clearly distinguishable from every sibling (bounties, prices, yields, etc.), none of which return model catalogs.

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 (call it to get the model catalog) and the payment clause defines a conditional path when you cannot pay, but it never states when to use this versus the sibling bridge_* tools or any exclusions. Usage is inferable rather than explicit.

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 does well: it discloses a per-call cost ($0.05 USDC on Base or Solana via x402) and the failure mode (returns 402 payment instructions instead of data). It stops short of describing result shape, ordering, or rate limits.

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

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

Roughly three dense sentences, front-loaded with the resource and payload, then payment terms, then parameters. The TrollBridge branding is mildly expendable but does not bloat the definition.

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 carry return-value meaning; it does so at a high level (listings with rug scores). Combined with the payment and 402 behavior, an agent has enough to invoke it correctly, though pagination and exact result fields remain unspecified.

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 both parameters are already documented with ranges and a default, so the schema does the heavy lifting. The description's 'Optional limit 1-50, chain' merely restates the schema and adds no format or semantics beyond 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?

States a specific resource (newest token listings) plus the distinguishing payload (rug scores) and the workflow it serves (check-then-ape sniping). An agent can separate it from bridge_token_check or bridge_fresh, though it never names those siblings explicitly.

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 'for check-then-ape sniping' implies a use context, and the payment caveat tells the agent what happens on failure, but there is no explicit when-to-use vs. when-not, nor any routing to bridge_token_check or bridge_fresh for related checks.

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 does well: it discloses a TOLLED cost ($0.02 USDC per call), the payment rails and mechanism (Base or Solana via x402), and the failure mode (a 402 payment-instruction response instead of data). It does not discuss result freshness, caching, or rate limits, which matters for an opportunity feed driven by deadlines.

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?

Front-loaded with what the tool returns, then the payment precondition, then the parameter — three compact clauses with no filler. Every sentence earns its place and nothing important is buried at the end.

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 aggregation tool with no output schema, listing the normalized fields substitutes well for a return-value description, and the x402 payment behavior is covered. The main residual gap is ordering/freshness of results, which an agent calling an opportunity feed would reasonably want 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?

Schema description coverage is 100% on the single 'limit' parameter, so the baseline is 3. The description's 'Optional limit 1-200' merely restates the schema's minimum/maximum and default, adding no new semantics (no ordering, pagination, or filtering implications).

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 resource and scope — 'every paying opportunity in one normalized schema' — and enumerates the returned fields (title, payout amount/token, chain, URL, requirements, deadline, board). The phrase 'One call, every board' makes it clear this is the aggregate counterpart to the board-specific siblings like bridge_bounties and bridge_sweepstakes without needing to open any schema.

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?

'One call, every board' implies the aggregate use case versus per-board siblings, and the toll/precondition is stated. However, no sibling tool is named and there is no explicit when-not guidance (e.g. use bridge_bounties for a single board, or bridge_deadlines when only deadlines matter), leaving selection to inference.

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 does so well: it discloses the tolled cost ($0.02 USDC), the accepted chains/payment rail (Base or Solana via x402), and the critical failure behavior that an unpaid call returns 402 payment instructions instead of data. It stops short of describing rate limits, caching, or the exact return shape.

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?

Four short clauses, front-loaded with the resource (spot prices), then the cost, payment rail, failure mode, and arity. No sentence is wasted and the critical toll warning is prominent.

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-param tool with no output schema and no annotations, the description covers purpose, cost, payment mechanism, and failure behavior. The one gap is the shape/contents of a successful response, which would help an agent interpret results, but everything needed to invoke it correctly is present.

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 takes zero parameters and the description correctly states 'No params,' matching the empty schema. With no parameters there is nothing further to specify, so the baseline of 4 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: spot crypto prices for BTC, ETH, SOL, USDC, which an agent can distinguish from sibling price/market tools like bridge_gas and bridge_markets by the asset class covered. It is clear about what it fetches, though it does not explicitly contrast itself with any sibling by name.

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: an agent learns this is used to get spot prices, and learns the payment precondition and the 402 fallback, but there is no guidance on when to choose this over alternatives such as bridge_gas or bridge_token_check.

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 does substantial work: it discloses the tool is tolled at $0.05 USDC per call, names the payment rails (Base/Solana via x402), and — critically — states that an unpaid call returns 402 payment instructions instead of data. It omits rate limits, result counts, and pagination, so not a 5.

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?

Front-loaded with the core purpose, then the payment constraint and requirement. Almost every clause earns its place, though the branding descriptor 'Mini's TrollBridge' adds little for an 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?

There is no output schema, but the description compensates by describing the return fields and, importantly, the 402 alternative response. For a one-parameter tool this is nearly complete; only pagination/result-limit behavior is 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?

Schema coverage is 100% and the single parameter 'q' is fully documented in the schema as 'Search query.' The description only adds 'Requires q', which restates the required flag rather than adding syntax or semantics. 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?

States a clear verb+resource ('web search for agents') and even lists the return shape (title, url, snippet, JSON). This cleanly separates it from the data-feed siblings (bridge_prices, bridge_gas, bridge_markets), but it never explicitly names or contrasts an alternative, so it stops 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?

The description explains payment terms and that 'q' is required, but gives no when-to-use guidance or when-not-to-use exclusions relative to the many bridge_* siblings. An agent gets no routing help beyond inferring that 'search' means web search.

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 does a good job: it discloses the per-call cost ($0.02 USDC), the payment rails (Base or Solana via x402), and the failure mode (returns 402 payment instructions instead of data). It omits what a successful response actually contains and whether it is a safe read, which are minor residual 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?

Three short, front-loaded sentences with no filler; the paying behavior and failure mode are stated crisply. The brand preamble ('Mini's TrollBridge') is slightly wasteful but does not obscure the payload.

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 tolled tool with no output schema and one fully documented parameter, the description covers the essentials an agent needs: cost, payment method, and the 402 fallback. It stops short of describing the returned payload shape, but no output schema exists to offload that to.

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 the schema already fully documents the single optional 'limit' parameter with its 1-200 range and default of 50. The description merely restates 'Optional limit 1-200', adding no meaning beyond the schema — the 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 distinct resource ('free-to-enter sweepstakes with real prizes') that no sibling covers, so an agent can tell it apart from bridge_bounties, bridge_yields, etc. However, the operation itself is only implied by the 'Optional limit 1-200' clause — there is no explicit 'list/return sweepstakes' verb, and the branded 'Mini's TrollBridge' framing adds noise rather than 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?

There is no guidance on when to call this tool versus the many bridge_* siblings, nor prerequisites beyond the payment requirement. The description only states operational mechanics (toll, failure behavior), not usage context or alternatives.

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

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

With no annotations, the description carries the full burden and does so unusually well: it discloses a non-standard metered billing model ($0.05 USDC per call on Base or Solana via x402) and the exact failure mode — a 402 payment-instruction payload is returned instead of data when payment is unavailable. That is the single most important behavioral fact an agent needs before calling, and it is stated explicitly.

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?

Front-loaded with what the tool does, then the payment model, then the fallback behavior. Every sentence earns its place: no repetition of the tool name, no filler, and the critical cost/failure information is not buried.

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 compensates by listing the returned signals and verdict, and no annotations, so it supplies the payment and error behavior itself. Combined with the fully documented 2-parameter schema, an agent has everything required to invoke it correctly and interpret the result.

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 the schema already documents both `mint` (token contract address) and `network` (chain enum base/solana). The description only restates 'requires mint and network' and adds no format, validation, or semantic detail beyond the schema, 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?

States a specific verb+resource ('token rug scan') and enumerates the exact signals produced: liquidity, volume, buys/sells, holder concentration, a heuristic 0-100 score and a verdict. An agent can distinguish this from siblings like bridge_prices, bridge_markets, or bridge_verdicts without opening the schema.

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 context for when to use it — scanning a token for rug risk when the mint and chain are known — and states the hard prerequisite ('Requires mint and network'). It does not name an alternative tool or a when-not condition (e.g., how it differs from bridge_verdicts or bridge_enrich), so it stops short of explicit 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the free/no-toll model and that listed tools may be pay-per-use, but it does not state authentication needs, read-only status, side effects, rate limits, or return 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 definition is a single sentence and appropriately sized for a no-param directory tool. However, 'FREE' and 'No toll' are somewhat redundant, and the brand prefix 'Mini's TrollBridge' is less informative than the actual tool purpose.

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

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

For a simple, no-parameter, read-only-style directory tool, the description covers the basic domain. Without an output schema, though, it should say more about what the tool returns, such as whether it lists all tools, supports pagination, or includes sorting/filtering behavior.

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

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

The tool has zero input parameters, so there are no parameter semantics to clarify. The baseline for a no-parameter tool is 4, and the description does not need to compensate for undocumented arguments.

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 a specific resource: a directory of third-party AI tools on the TrollBridge marketplace. It distinguishes itself from most bridge_* siblings, which cover other domains such as prices, markets, and bounties, but it does not use an explicit operation verb like 'list' or 'retrieve'.

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 instead of siblings such as bridge_search, bridge_fresh, or bridge_models. The marketplace/payment context hints at its role, but no explicit when-to-use or when-not-to-use condition is 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?

With no annotations, the description carries the full burden. It does add real behavioral context: the service is free and 'traffic is small and growing' with 'exactly what the bridge has seen, nothing more', which usefully warns the agent that results may be sparse and unembellished. However it says nothing about auth requirements, call cost/latency, 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?

The metric list is front-loaded in the first sentence, which is good, but the passage is padded with branding ('Mini's TrollBridge', 'Honest day-one ledger') and idiosyncratic terms that spend words without adding usable meaning. Every sentence does carry some signal, so it is adequate rather than wasteful.

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 no-parameter tool with no output schema, the description is the only place the returned fields can be described, and it does list them (toll challenges, paid crossings, unique wallets, first/last seen). The main residual gap is that it never sketches the output shape or units, so an agent still doesn't know how these metrics are packaged.

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 takes zero parameters, so the schema cannot be misread and there is no parameter semantics to document; the baseline for 0-param tools is 4. Nothing in the description contradicts or confuses the empty 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?

It names the resource (bridge statistics) and enumerates the specific metrics returned: per-lane toll challenges vs paid crossings, unique payer wallets, first/last seen. This is concrete enough for an agent to know it is a read-only traffic-reporting tool, but the branded jargon ('lookers', 'agents through', 'TrollBridge') requires interpretation and it never distinguishes itself from siblings like bridge_health or bridge_fresh.

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 the 17 sibling bridge_* tools, and no exclusions or prerequisites. 'FREE' hints at cost but conveys no selection guidance. An agent has to infer that this is the traffic-metrics endpoint on its own.

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, and it delivers critical behavior: a $0.02 USDC toll on Base or Solana via x402, and the failure mode where an unpaid call returns 402 payment instructions instead of data. It omits what 'recently' means and the return shape, keeping it out of 5 territory.

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, each earning its place: dataset scope, payment model, and failure behavior. The most decision-relevant constraint (the toll and 402 fallback) is stated up front rather than buried.

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-param read tool with no output schema, the description covers the essentials an agent needs to call it correctly, especially the paid-access requirement and the 402 behavior. It could say more about the recency window and result shape, but nothing blocks a correct invocation.

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

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

Schema description coverage is 100% and the single limit param is documented in the schema with range and default. The description's 'Optional limit 1-200' restates the schema rather than adding syntax or semantics, 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?

States a specific resource and scope: 'recently-paid bounties: which bounties actually paid out and how much.' The 'recently-paid / actually paid out' framing is enough to separate it from the sibling bridge_bounties, though the description never names that sibling, so differentiation is inferred rather than stated.

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 only implied: 'recently-paid bounties' hints you use this for settled payouts rather than open listings, and the toll sentence tells you the precondition for calling it. There is no explicit when-to-use versus bridge_bounties or any when-not 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 does so well: it discloses the tolled pay-per-call model ($0.05 USDC on Base or Solana via x402) and the failure behavior (returns 402 payment instructions instead of data). It omits rate limits and freshness/latency characteristics, but the payment and failure semantics are exactly the kind of non-obvious behavior an agent needs.

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?

Compact and front-loaded: identity, what it returns, cost, failure mode, then params. The branding ('Mini's TrollBridge') is mildly expendable but the rest earns its place with no redundancy.

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

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

For a two-parameter, no-output-schema tool, the description covers the essentials: what it returns, the payment gate, and the no-payment fallback. The missing piece is sibling differentiation within a large bridge_* family, which matters here given 17 related tools.

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 (limit and stablecoinOnly, including ranges and defaults) are already fully documented in the schema. The description merely restates 'Optional limit 1-50, stablecoinOnly' and adds no syntax or semantic nuance beyond it, which is the baseline 3 case.

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 resource (DeFi yields: stablecoin APYs and more) with a clear scope and identifies the audience (yield-hunting agents). It does not, however, differentiate itself from plausible siblings like bridge_markets or bridge_opportunities, leaving the agent to infer which yield-adjacent endpoint to pick.

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 'for yield-hunting agents' and by the payment note ('If you cannot pay, this tool returns the 402 payment instructions instead of data'), which is genuinely useful when-planning. There is no explicit when-not guidance and no named alternative among the many bridge_* siblings.

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