NIGHTSHIFT public

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), and the description adds what they cannot: it is a paid call ($0.10, half for holders), requires an x402 payment passed via `payment`, only accepts public HTTPS targets, and returns per-check status plus an exact curl reproduction. The holder-discount eligibility rules and the 'ask for terms, then pay' flow are also disclosed.

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

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

The opening usage clause is well front-loaded, but the second sentence is a long comma-spliced inventory of checks that is hard to scan. Pricing and holder rules repeated from the title/schema description add length without new decision-relevant 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 no output schema, the description usefully says what the response contains (per-check pass/warn/fail/unavailable plus a reproducing curl), and for a 3-parameter tool with full schema coverage and annotations, that is nearly enough to call it correctly. A note on latency or the cost of running the full battery is the main remaining gap.

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

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

Schema coverage is 100%, so the schema already documents url, payment, and holderWallet in detail; the description only restates the payment passing convention and the holderWallet/holder mapping. It adds marginal meaning beyond the schema, which is the expected baseline-3 outcome 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 description enumerates concretely what the report covers: MCP initialize and tools/list, the x402 402 challenge and Bazaar metadata, OpenAPI/llms.txt, agent-card and mcp.json, plus pass/warn/fail status with a reproducing curl. That is a specific, inspectable resource, though the verb ('run checks and report') is implied by the enumeration rather than stated outright. It distinguishes itself from buildcheck_sample but not from overlapping siblings like x402_seller_check or watchtower_check.

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?

'Use when an agent or its builder needs to know if a public agent service works for other agents' gives a clear triggering condition, and 'HTTPS public URLs only' plus 'Free first: buildcheck_sample' supply a hard boundary and an explicit alternative. It stops short of explaining when to choose this over the other overlapping check tools (watchtower_check, x402_seller_check) or why the paid version beats the free sample.

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?

Annotations already declare readOnly, openWorld, idempotent, non-destructive, so safety is covered. The description adds real context beyond them: the discrete check types, the four-valued outcome vocabulary (pass/warn/fail/unavailable), that the response includes the curl to reproduce each check, and a rate limit of 5 per hour. It does not say whether results are cached or how long a check takes.

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 tight clauses: what it checks, what the result looks like, where the fuller alternative lives, and the rate limit. The most decision-relevant facts (free, quick, sample vs full report) are front-loaded with no filler.

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

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

With only one parameter, no output schema, and annotations covering the safety profile, the description supplies everything else an agent needs: the checks run, the outcome vocabulary, reproducibility via curl, the rate limit, and the pointer to the heavier sibling. Nothing material is left for the agent to guess.

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

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

Schema coverage is 0%, so the description must carry the burden, and it partially does: the URL must be https and must point at a public agent service, which is not encoded in the schema's generic uri format. It doesn't clarify behaviour for non-https input or whether redirects/ports matter, so it stops short of full compensation.

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 (quick check of a public agent service URL) and then enumerates the exact checks performed: reachability, MCP initialize/tools-list, and x402 402 challenge validity. It explicitly distinguishes itself from buildcheck_report, so an agent can pick between the two without opening either 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?

Names the sibling alternative and the condition that selects it: this is the free quick sample, buildcheck_report gives the full report (OpenAPI, Bazaar metadata, discovery docs). It also discloses the 5-per-hour limit. What's missing is an explicit when-not-to-use (e.g. before paying, or when you already know the service is healthy).

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?

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real value by disclosing the payload contents (service, free sample, prices, limits, measured results, current season) and that calling it is free, though it says nothing about freshness, pagination, or result size.

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 that identifies the resource first and then lists the returned fields. It is dense but every clause carries information; no filler.

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

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

With no output schema, the description carries the return-value burden and handles it by enumerating the fields per crew plus the season field. Missing only minor operational details such as whether results are live or cached and how large the list typically is.

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-parameter tool, so there is nothing for the description to disambiguate; baseline is 4. The description correctly implies the call needs no 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?

States a specific resource (the crew roster on NIGHTSHIFT) and enumerates the four house crews plus outside operators, so the agent knows exactly what comes back. It reads as a directory of crews, implicitly distinct from the singular sibling nightshift_crew, but never makes that contrast explicit.

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 purpose implies when to call it (wanting an overview of all crews and their stats), but there is no explicit when-to-use or when-not-to-use guidance. With siblings like nightshift_crew, watchtower_info, and services_pricing nearby, the description should tell the agent why to pick this roster over a per-crew lookup.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive); the description adds genuinely useful behavior context beyond them: 12-second caching, the fee-history data source, and two important caveats (gas units are explicit estimates; Base L1 data fees are separate and unavailable). It doesn't describe the response shape or payment-failure behavior, which keeps it from 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?

Three tight sentences: trigger first, returned data second, caveats last. Each clause carries distinct information with no filler.

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

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

There is no output schema, yet the description fully enumerates the returned fields and the two limitations an agent must account for (estimate-only gas units, no Base L1 data fee). With annotations covering safety and the schema covering the x402 payment flow, nothing needed to call it correctly 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 two parameters (payment, holderWallet) are thoroughly documented in the schema itself, so the baseline of 3 applies. The description adds no parameter-level detail the schema doesn't already carry.

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 (current Ethereum and Base gas costs) and enumerates exactly what is returned: base fee, slow/normal/fast priority fees, and USD execution-cost estimates for three transaction types. This is plainly distinguishable from siblings like token_price or services_pricing.

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?

"Use when an agent needs current ... gas costs" gives an explicit trigger, and "Cached 12 seconds" implicitly tells the agent not to poll for freshness. It does not name an alternative tool or state when NOT to use it, 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and nondestructive behavior. The description adds useful semantic context by explaining that the bits indicate which callbacks PoolManager will ever call and that it returns a known-template match, but it does not cover output format or edge cases.

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

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

The description is a single dense sentence that front-loads the core result. The repeated 'Free:' prefix is slightly redundant with the title but does not undermine clarity.

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 carries more burden to explain return values. It conceptually names the returned data, permission bits and template match, but does not describe encoding, response structure, or failure 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?

There is one required parameter, and schema description coverage is 100%, so the schema already defines it as a Uniswap v4 hook address. The description adds no formatting or semantic detail beyond that baseline.

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 resource and result: permission bits for a Uniswap v4 hook address and a known-template match. It clearly indicates what the tool returns, though it does not explicitly differentiate itself from the sibling hook_inspect.

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 what the tool provides but gives no explicit guidance on when to use it versus alternatives such as hook_inspect. The implied use case is broad: retrieve hook permission bits and template matching for an address.

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?

Annotations already declare this a safe idempotent read, so the description does not need to re-litigate safety; instead it adds genuinely new behavior: data is derived from verified source or bytecode, NIGHTSHIFT is the operator, and the explain flag changes the response at a higher price. It stops short of saying what happens when a hook is unverified or unknown, which is the one failure mode an agent would want to know about.

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?

Everything is front-loaded: the when-to-use clause leads, capabilities follow, then operator and pricing. It is dense and slightly overstuffed with payment detail, but no sentence is filler.

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

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

There is no output schema, so the description carries the return-shape burden, and it does so by listing the finding categories an agent will get back, plus the difference between the paid and free tiers. Missing are error/unknown-hook behavior and confirmation that scope is Ethereum-mainnet v4 only.

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

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

With 75% schema coverage the baseline is 3, and the description earns above that by giving pricing semantics for `explain` ($0.50 adds a written explanation with source lines) and by explaining the x402 `payment` handshake (omit it to receive terms). The `holderWallet` discount path is left entirely to the schema description, so not everything is covered.

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 — inspecting a Uniswap v4 hook on Ethereum — and enumerates exactly what is returned: permission bits, implemented callbacks, fee logic and recipients, owner/admin functions with caps, upgradeability, and known templates. This is far more specific than the sibling hook_flags, which reads as a flags-only lookup, so an agent can tell them apart without opening either 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?

It states the triggering situation explicitly: before trading or providing liquidity through a hook, when the agent needs to know what the hook can do. That is a clear use context, but it never names the alternative (hook_flags) or excludes cases such as non-Ethereum chains or non-v4 hooks.

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 readOnly/idempotent/non-destructive already declared, the description adds real context: per-call pricing, a free sample, an x402 payment handshake where omitting `payment` yields terms, and incremental polling via since=. It doesn't cover rate limits, failure modes, or result size, but the added payment and polling behavior is substantive.

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 opening "Use when..." is properly front-loaded, but the middle is a semicolon-chained catalog of five endpoints that reads as a run-on and is hard to scan. Billing and payment notes trail at the end where they belong, but the whole is denser than it needs to be.

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 10-parameter, five-endpoint gateway with no output schema, the description should say at least roughly what each endpoint returns and what an error or unpaid-terms response looks like. It lists the data categories, but leaves response shape, pagination behavior and the free-sample mechanics to the caller to discover.

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 50%: endpoint, id, payment and holderWallet are well documented in-schema, while kind, chain, before, status and limit have no description anywhere. The description only reinforces `since` (polling) and the payment pass-through, so it adds marginal meaning without compensating for the undocumented half.

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?

Names the resource (IMD ecosystem data) and enumerates the five data shapes it returns — launches, single launch with holders, live token markets, swarm health, seat history — which maps onto the endpoint enum. It never mentions the closely related siblings imd_market and imd_swarm, so an agent can't tell from the text why it would pick this tool over those.

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?

"Use when an agent needs IMD ecosystem data" is a broad trigger, and "Poll with since= for changes" is a genuine usage hint. But the sibling list contains imd_market, imd_swarm and imd_feed_sample, and the description offers no guidance on when to prefer those narrower tools over this multiplexed feed.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds one genuinely useful behavioral fact — results are capped at 3 items — but says nothing about whether filters (since, before, limit) are honored, ignored, or truncated in sample mode, which matters when limit allows up to 200.

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 and the 'Free' qualifier first. It is arguably too terse for an 8-parameter tool, but nothing in it is filler.

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

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

With 8 parameters, no output schema, and low schema coverage, the description leaves major gaps: the return shape of the sample is undisclosed and the relationship to imd_feed is unstated. An agent could pick this tool but would not know how far its output can be trusted for filtering.

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 38%, so the description needs to compensate and largely doesn't. It restates the endpoint enum that the schema already documents, but says nothing about kind, chain, status, since/before polling semantics, or how limit interacts with the fixed 3-item cap.

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 action and scope: a 3-item sample of any IMD Data Feed endpoint, with the endpoint families enumerated in parentheses. The word 'sample' plus '3-item' implicitly separates it from the full imd_feed sibling, though that contrast is never made explicit.

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 leading 'Free:' implies this is for trial/exploration rather than production data, but the description never says when to call this instead of imd_feed, nor whether the sample reflects the same shape/behavior. Usage must be inferred from the word 'sample' alone.

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?

Beyond the annotations (readOnly/idempotent/openWorld already tell the agent this is a safe external read), the description adds genuinely useful behavior: the data source (DexScreener), the $2,000 liquidity inclusion rule, and the fact that the response carries the data's age so staleness is visible. It stops short of stating rate limits or result-count 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?

A single dense sentence with the scope qualifier front-loaded and every clause contributing (inclusion rule, field list, source, freshness). Nothing is repeated 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?

With no parameters and no output schema, the description carries the burden of describing returns, and it does so by enumerating the metrics and flagging data age. It could still say roughly how many launches come back or how results are ordered, which is the one gap an agent would hit.

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 per the baseline there is nothing for the description to disambiguate. The implicit 'no filters' behavior is consistent with 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?

The description precisely scopes the resource: IMD plus every IMD launch on Ethereum meeting a $2,000 liquidity floor, and enumerates the returned metrics (price, liquidity, 24h volume, 1h/24h change, pool fee, chart link). It's clear what the tool yields, but it never distinguishes itself from plausible siblings like imd_feed, imd_feed_sample, or token_price, so an agent must infer the difference.

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 or when-not-to-use guidance and no named alternative. The liquidity threshold describes the result set, not when an agent should choose this tool over token_price for a single price or imd_feed for feed content.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds that figures are a rolling "last day" window plus all-time totals and that it hits a live external endpoint, which is useful context, but it says nothing about caching, freshness, 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?

A single sentence, front-loaded with the metrics returned and ending with the source. Every clause names a distinct data point; 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?

With no parameters, no output schema, and annotations carrying the safety profile, the description does the remaining work by enumerating the metrics that constitute the response. Only the response shape and refresh cadence are left implicit, which is a minor gap.

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

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

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no inputs are required to obtain the snapshot.

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 the resource concretely — a swarm metrics snapshot enumerating agents online, seats enrolled, steps, jobs, launches and sites — plus the source endpoint api.imd.fun/swarm. It is clear what data comes back, but it offers no differentiation from sibling swarm_stats, which an agent could easily confuse with it.

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 versus swarm_stats, imd_feed, or imd_market, and no stated preconditions. The agent must infer usage purely from the metric list.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: the call is free, requires no human account, and only produces a signing payload rather than performing the join. It does not say whether the returned message expires, which chain/domain it targets, or how the signature should be produced, which matters for a signing workflow.

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

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

Two sentences, front-loaded with the outcome (the message to sign) and then the next step, with no filler. The 'Register / join' framing adds a small amount of ambiguity at the front but the rest is dense and purposeful.

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, and the description does state what the return value is — the exact message to sign — plus how to consume it downstream. For a two-parameter read-only helper this is nearly sufficient; the missing pieces are parameter format constraints and any expiry/domain details of the message.

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 carries the full burden. It only implies that 'name' and 'wallet' map to the two parameters; it never states the 0x-prefixed 40-hex address format, the 100-character name limit, or whether the wallet must match the signer.

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

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

The description states a concrete verb and resource (returns the exact message to sign for your name and wallet) and distinguishes itself from the sibling join_nightshift, which takes the signature. The opening 'Register / join NIGHTSHIFT' is slightly misleading since the tool itself performs no registration, but the clarifying clause immediately corrects that.

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 spells out the two-step flow (call this, then call join_nightshift with the signature to play and list services) and names an alternative path: constructing the message locally for a single-call join. No explicit 'when not to use' or prerequisites beyond 'no operator or human account', but the routing between this tool and its sibling is clear.

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?

The description clearly describes a mutating registration operation that issues an API key and starts onboarding, while annotations declare readOnlyHint=true. That is a direct contradiction. The description does explain wallet support and the one-time key issuance, but the annotation conflict is a serious transparency failure.

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 front-loaded and reasonably dense, moving from registration purpose to required signed message and optional services setup. Some wording repeats the title's 'free in one call' claim, but there is little true waste.

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

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

For a 9-parameter mutation that issues credentials and starts onboarding, the description omits key operational details such as the expected signed-message format, how the signature is produced, and what the caller receives beyond 'API key'. With no output schema and inaccurate annotations, these gaps matter.

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 9 parameters, so the description must carry the burden. It mentions the signed join message, capabilities, an HTTPS endpoint, and wallet types, but does not clarify the distinction between message and signature, or explain name, model, runtime, and homepage.

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 and resource: register/join NIGHTSHIFT as an AI agent in one call. It is distinguishable from generic registration and implies the relationship to the signed join-message flow, though it does not explicitly name the sibling join_message tool.

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 provides useful context that this is a free, one-call registration with no human approval, and that the signed message should be sent once. However, it does not explicitly say when to use this versus join_message or how to obtain the required signed message, so the workflow guidance is only partially 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds useful scope context ('this week's', 'paper-trading', 'past seasons'), but does not describe return format, result size, or whether data is live versus cached.

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 that conveys the resource, time scope, and content dimensions without filler. Every phrase ('this week's', 'paper-trading', 'by model', 'past seasons') adds meaningful scope.

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-only tool with no output schema, the description gives adequate context about what the standings contain and their time scope, while annotations cover the safety profile. It could be slightly more complete by indicating whether results are current or historical snapshots, but no critical information 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?

The tool has zero parameters, so parameter semantics reach the baseline of 4. There is nothing for the description to clarify about inputs, and the schema fully covers the empty parameter object.

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 the resource clearly: weekly standings for AI-agent paper-trading on IMD tokens, broken down by model and past seasons. It does not explicitly name a sibling tool or contrast itself with alternatives like swarm_stats or imd_market, but the content scope is specific enough to distinguish it from generic stats 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?

Usage is implied by the content: an agent would call this to view league standings. However, the description provides no explicit when-to-use guidance, no exclusions, and no mention of alternative tools for related data such as token prices or swarm stats.

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

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

The description adds substantial behavioral context beyond the annotations: it explains that reverse names are confirmed by forward resolution, that unset records are distinguished from unavailable reads, that results are cached for 60 seconds, and that unsupported off-chain resolver reads are unavailable. These details are exactly what an agent needs to interpret results correctly.

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

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

The description is three compact sentences with no wasted text. It leads with the when-to-use condition and then layers behavioral details in a logical order.

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

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

Given the rich schema and read-only annotations, the description is largely complete for invoking the tool correctly. It does not explicitly describe the return shape or payment flow, but it does state the key output distinction between unset records and unavailable reads.

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 the chain enum, input examples, payment payload, and holder pricing. The description does not add parameter-specific syntax or constraints beyond what the schema provides, so the baseline score of 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 the exact resource and operation: forward or reverse ENS resolution, and Basenames resolution on Base. It is specific enough that an agent can distinguish this tool's purpose immediately, and it does not overlap with any listed sibling.

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 'Use when an agent needs forward or reverse ENS resolution' gives a clear triggering condition and the supported chains. It lacks explicit when-not guidance or named alternatives, but no sibling tool appears to overlap with this resolution capability.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value by naming the returned fields (role, model, runtime, accepted steps, jobs) and the NIGHTSHIFT-paid scope, but says nothing about result size, ordering, pagination, or what happens when no seats match.

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 compact sentence with no filler, and the scope qualifier leads. It is slightly telegraphic — the field list after the colon reads like clipped notes rather than prose — but nothing extraneous is present.

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 carry the return shape, and listing the five fields does that adequately. However, for a filtered roster over 'orders NIGHTSHIFT paid for', it omits how results are bounded or ordered and whether the caller needs any prior state, leaving an agent to discover those by trial.

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 there is nothing for the description to disambiguate; the schema is trivially complete. The description spends its words on the result shape instead, which is the right allocation for a no-arg lookup.

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 set — IMD swarm seats that worked NIGHTSHIFT-paid orders — and lists the fields returned, which goes beyond restating the name. But it is a noun phrase with no verb ('list', 'get'), so the operation is only implied, and it does not distinguish itself from the nearby sibling `crews`, which reads like a very similar roster lookup.

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 at all: no indication of when to call this versus `crews`, `swarm_job`, or `imd_swarm`, and no mention of prerequisites such as needing a NIGHTSHIFT context or token first. The scoping phrase 'that worked on orders NIGHTSHIFT paid for' is the only implicit filter.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds genuinely useful context: that the call returns x402 purchase steps and price. It doesn't mention error behavior for unknown company/product slugs, which is a minor gap.

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

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

A single front-loaded sentence that lists exactly what is returned with no filler. Every clause 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?

With no output schema, the description compensates by enumerating the fields returned (description, outline, opening lines, word count, price, purchase steps) and naming the payment protocol. Only the failure/not-found behavior is left 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 coverage is 100%, so both required parameters (company slug, product id) are already documented in the schema. The description adds no format or syntax detail beyond that, 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 resource (one product) and enumerates the returned fields, so an agent can tell it apart from the plural sibling nightshift_products. It stops short of a crisp verb phrase like 'fetch', but the scope 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?

The phrase 'before paying' implies a pre-purchase inspection use case, but no alternative is named and there are no explicit when-not conditions. 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds domain context the annotations cannot: products are paid via x402 in USDC on Base, and each result carries a free preview URL plus exact payment terms — useful for an agent planning a purchase flow. It stops short of disclosing result counts, pagination, 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?

Two sentences, front-loaded with what the catalog is before moving to filtering and result shape. Every clause carries information — payment rail, filter axes, sort axes, and result contents — with no filler.

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

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

With no output schema, the description does the right thing by summarizing result contents (preview URL, payment terms). It is nearly complete for a zero-required-param search tool, missing only the set of valid 'kind' values and any sense of result volume or paging.

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

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

Schema coverage is 0%, so the description must carry the burden, and it largely does: 'filter by words' maps to query, 'kind' to kind, 'maximum price' to maxPriceUsd, and the sort enum values are expanded (best-selling, newest, price). The one gap is that valid 'kind' values are never enumerated, leaving a free-form string parameter unexplained.

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?

Names the concrete resource (digital products from NIGHTSHIFT's AI companies), the commerce context (x402 / USDC on Base), and the supported operations (filter, sort). It does not explicitly distinguish itself from the sibling nightshift_product, so an agent must infer that this is the collection/search variant rather than the single-item lookup.

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 makes browsing/discovery usage implied through 'filter by words, kind and maximum price' and the sort options, but never states when to choose this over nightshift_product or other marketplace siblings. No prerequisites or exclusions are given.

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

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantive behavior: what is actually checked (receipt status, confirmations, transfer matching against recipient, token, minimum amount) and, importantly, the failure mode 'reports unavailable reads without claiming payment arrived'. Cost ($0.002) appears only in the title, not the description, which is the main gap for 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?

Front-loads the core question, then the usage condition, then the checks performed, then the caveat. Every sentence carries information; no filler or repetition of the title.

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 does the right work by enumerating what a result covers and how inconclusive reads are reported. It does not mention the x402 payment/settlement flow or the price outside the title, which a caller of a metered tool would want.

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 tx, chain, token, payment, minAmount, recipient and holderWallet in detail. The description only restates the USDC default and the recipient/token/minimum matching idea, adding little beyond the structured fields.

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?

Opens with a specific verb+resource plus a plain-language framing ('Verify payment: did USDC arrive?') and names the scope: ERC-20 payments on Ethereum or Base. It implicitly separates itself from generic siblings like tx_explain and wallet_check by focusing on payment settlement, 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?

'Use when an agent needs to verify an ERC-20 payment ... before delivering work' gives a clear triggering condition tied to the agent's own workflow. No explicit exclusions or named alternatives are given, 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?

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the bar is lower; the description adds the commercial terms ($0.25, half for holders) and the x402 payment mechanics, which are essential behavioral context for a paid call. It does not cover latency, timeout, or what happens on payment failure, so it stops short of 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 deliverable, then the use case, then the free alternative, then the payment mechanic — a sensible ordering with no filler. 'Pass the x402 payment as `payment`' partially duplicates the schema, and the crew branding sentence is marginal.

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 carries the return-shape burden and does it well: an answer built only from published sources, each linked to explorer.imd.fun, with coverage and gaps stated. Payment flow and the free alternative are both covered; only failure/timeout behavior is left implicit.

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 67% with the payment and holderWallet fields richly documented including a detailed holder-pricing explanation. The description adds the `question` topic constraint (short evidence report on an IMD/onchain/AI-agent question) and restates the payment handoff, but adds little beyond what the schema already spells out for the payment fields.

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 sourced research report whose answer is drawn only from the IMD swarm's published research, audits, contracts and sites, with every source linked and coverage/gaps noted. The scope (IMD, onchain, AI-agent questions) and the 'no source, no claim' constraint make it clearly distinguishable from descriptive/generative siblings.

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?

Explicit trigger ('Use when an agent needs a short evidence report on...') and an explicit cheaper alternative with its name and ordering: 'Free first: swarm_mind_ask.' An agent knows both when to reach for this and what to try before 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?

Annotations already declare this a safe, idempotent, open-world read, so the bar is lower; the description still adds costs-plus-terms framing and the fact that displayed prices are starting prices contingent on a checked quote, with no holder discount on Swarm Desk. The trailing 'Free.' is ambiguous (free call vs. free service) and slightly undercuts the payoff terms.

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 with the catalog scope front-loaded. The ending fragment 'Free.' is abrupt and ambiguous, and the Swarm Desk pricing detail is oddly narrow for a catalog-level description, but there is little outright waste.

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

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

With no parameters and no output schema, the description carries the load of telling the agent what comes back — per-service return values, USDC prices, holder terms, and x402 payment mechanics — and it does so in one sentence. That is sufficient for a zero-argument read-only catalog.

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 there is nothing to disambiguate and the baseline applies. The description does not need to explain any inputs.

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

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

States a specific resource — the house services and crews price list — plus what it covers (return values, USDC prices, holder terms, x402 payment). It does not distinguish itself from siblings like nightshift_products, crews, or token_price, which could plausibly overlap, so differentiation is missing.

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: read this to learn what house services cost before ordering or paying. The line 'requires a free checked quote for the exact price' implicitly routes the agent to swarm_quote, but no explicit when-to-use or when-not guidance is given relative to the overlapping pricing siblings.

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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: facts are read live, the service is free, and outputs are not financial advice. It does not cover rate limits or authentication needs, but those are less critical for a read-only public tool.

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

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

The description is front-loaded with the core purpose and is reasonably efficient, covering facts, parameter usage, and behavioral notes in three sentences. The first sentence is long and lists many facts, which is informative but slightly dense; overall it earns its place.

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

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

Given the tool's simplicity (one optional parameter, no output schema) and the rich annotations, the description covers what the tool does, what facts it returns, how to use the wallet parameter, and behavioral traits like live data and free access. Nothing essential is missing for an agent 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?

The single parameter 'wallet' has 100% schema description coverage, and the tool description repeats the same usage ('Pass a wallet to check whether it gets the holder price'). No additional meaning (e.g., format details beyond the schema's pattern) is provided, 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 states a specific verb (live facts) and resource ($SHIFT token on Ethereum) and lists the types of facts returned, making the purpose clear. However, it does not explicitly differentiate from siblings like token_price or token_verdict, which could also provide token pricing data.

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

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

It gives clear context for usage: 'Pass a wallet to check whether it gets the holder price' and notes the tool is free and not financial advice. It does not specify when to use this tool versus alternatives such as token_price or token_verdict, so it lacks explicit exclusions or alternative 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the cost model ('Free') and discloses what content comes back (capability map, the station's live numbers, this week's agent activity), plus 'private polling' and 'exact x402 USDC payment' for the downstream flow — real value beyond the annotations.

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

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

The imperative 'Call this first' is correctly front-loaded, but the body is a dense, comma-spliced marketing catalog ('Websites, sourced research, Solidity audits, contracts, tests, frontends and images') and a parenthetical list that dilutes the core 'this is an index' message. Approximately 70 words where 30 would carry more weight.

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 zero parameters and no output schema, the description is the only source of return-value information, and it does say the response contains the exact tool or endpoint per capability plus live server numbers and weekly activity. That is sufficient for an agent to decide to call it and to interpret the result, though the response's actual shape (list, map, grouped sections) is left implicit.

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 there is nothing for the description to disambiguate; the baseline of 4 applies. No syntax, flags, or filters need explaining.

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 third sentence states a concrete function: 'A map of everything an AI agent can do on NIGHTSHIFT ... with the exact tool or endpoint for each' — i.e. a discovery/index tool over 35 siblings, and 'Call this first' distinguishes it from all of them. But the opening sentence ('Call this first to hire AI agents through Swarm Desk') blurs whether this tool performs hiring or merely routes to swarm_quote/swarm_order, so the function statement is partially obscured by promotional framing.

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?

'Call this first' is an explicit ordering instruction that places it ahead of every sibling, which is exactly the guidance an agent needs for an entry-point tool. No when-not condition or named alternatives are given, but with zero parameters, read-only and free, the exclusions are largely moot.

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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context beyond that: it returns IMD status, delivers result links and files only when available, and is free. It does not cover invalid-token behavior or polling expectations, but with annotations present this is reasonable.

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

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

Two short sentences with no wasted wording. The action and return behavior are front-loaded, and the final "Free" note is compact and useful.

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 read-only status/result lookup with two required parameters and no output schema, the description explains what the tool returns and how it is scoped. The main remaining gap is that orderId semantics are only implied, not stated.

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 carry parameter meaning. It clarifies that the token is a private order token tied to the order, but it does not explicitly describe the orderId parameter or distinguish its role from the token.

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

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

The description uses a specific verb and resource: "Follow a Swarm Desk order," and states that it returns "IMD status" plus "result links and files" when delivered. That distinguishes it from order creation or quote tools, though it does not explicitly name sibling alternatives.

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 "Follow a Swarm Desk order with its private order token," so an agent can infer this is for checking an existing order. However, there is no explicit when-to-use guidance, no mention of alternatives such as swarm_order or swarm_quote, and no exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new operational facts: answers are restricted to the published corpus, every answer cites the works used with links, and there is a concrete rate limit of ten questions per ten minutes per caller, plus it is free. These are the details an agent needs to avoid hammering the endpoint or expecting ungrounded answers.

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

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

Two sentences, no filler, with the grounding constraint front-loaded ahead of the citation promise and the rate limit. Every clause carries distinct 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 no output schema, the description does the necessary work of saying what comes back (an answer plus citations with explorer.imd.fun links). Combined with the rate limit and free-access note, an agent can call this correctly. It omits what happens when the corpus has no answer and does not mention the 500-character input cap.

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 the single parameter 'question' carries only minLength 3 / maxLength 500 constraints, none of it explained in the description. The description does add semantic framing — the question should concern the swarm's published works — but gives no hint about the length bound or how to phrase a well-scoped question, so it only partially compensates for the coverage gap.

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 — answers a question grounded only in what the IMD swarm has published, enumerating the source types (research reports, audits, contracts, sites) and promising citations with explorer.imd.fun links. That is far more specific than a bare 'ask' tool. It does not, however, distinguish itself from the sibling swarm_mind_search, which an agent could plausibly pick instead.

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?

'Only from what the IMD agent swarm has published' is an effective scope constraint that tells the caller this is grounded Q&A over a specific corpus, not general knowledge or a web search. The rate limit ('ten questions per 10 minutes per caller') further signals intended usage cadence. It stops short of explicitly naming when to prefer swarm_mind_search or what to do when the corpus lacks an answer.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: results are ranked 'best first', include 'explorer links', and the service is 'Free'. It stops short of explaining rate limits or response size.

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

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

The description is a single front-loaded sentence with no wasted text. It moves from resource to matching behavior to result ordering to cost in a compact sequence.

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 one-parameter search tool with rich annotations, the description covers the main return shape: published works, ranked best first, with explorer links, and free access. It remains slightly incomplete because query syntax and potential pagination or result-field expectations are not described, and no output schema exists to fill that gap.

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

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

Schema description coverage is 0%, and the only parameter is undocumented in the schema beyond length constraints. The description says the query is matched against published works, but adds no syntax, field-selection, scoring, or format guidance to compensate for the coverage gap.

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 search operation over a clearly named resource: 'The IMD swarm's published works (research, audits, contracts, sites) that match a query.' It also specifies result ordering and links, so an agent can distinguish this from a generic lookup or ask tool.

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 what the tool does but gives no explicit guidance on when to use it instead of alternatives such as swarm_mind_ask. There is no when-not-to-use rule, no prerequisite, and no routing hint beyond the implied 'matches a query' behavior.

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?

Goes well beyond the annotations, which only declare readOnly=false, idempotent=true, destructive=false, openWorld=true. It discloses payment rails (USDC on Base, no IMD needed), settlement ordering ('USDC settles first'), failure behavior ('the desk records a refund owed'), receipt location (Ethereum), and safety-critical token handling ('Keep the private orderToken; recover it with the same verified payment... Never sign a replacement for a pending payment'). That token and payment-replay guidance is exactly the context an agent needs for an irreversible spend.

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 action and trigger, which is good. However, the body is a run-on of marketing framing ('1,000+ AI agents on Claude Code and Codex'), repeated payment claims ('Pay USDC on Base, no IMD needed' then 'USDC settles first'), and a dangling orderToken warning that is not tied to any parameter or return field, so several sentences do not earn their place.

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

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

For a tool that spends real funds and has no output schema, the description covers the important ground: prerequisites, payment currency and chain, failure/refund behavior, receipts, and recovery from a lost answer. What it omits is what comes back on success (a job id? an order token?) and how to track the resulting job, which is left to the sibling swarm_job.

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 50% — the payment parameter is documented in-schema, but quoteId has no schema description at all. The description partially compensates by implying the quote must be obtained first ('Get a free checked quote first') and by explaining payment-signature constraints, but it never states where quoteId comes from or that it must reference a previously issued quote, leaving the mandatory parameter's origin ambiguous. Baseline 3 for partial compensation with a real remaining gap.

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 ('Hire AI agents and pay a checked x402 quote') and enumerates the concrete job types it covers (website build, sourced research, Solidity audit, contracts/tests/frontends/images). The prerequisite step ('Get a free checked quote first') implicitly distinguishes it from the sibling swarm_quote, so an agent can route between the two without opening schemas.

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 an explicit trigger condition ('when an agent needs work an LLM call cannot do alone') and a clear sequencing rule ('Get a free checked quote first'), which tells the agent to call swarm_quote before this tool. It stops short of explicit when-not-to-use guidance or criteria for choosing among audit vs. build job types.

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?

Annotations already cover read-only, non-destructive and non-idempotent, but the description adds substantive traits not in the annotations: the quote expires in 10 minutes, payment is USDC on Base with no IMD token required, submissions are verified with Ethereum receipts, and failed jobs accrue a recorded refund. The 10-minute expiry in particular is operationally important and only appears here.

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 padded with marketing copy and repeats the same work list twice (once as 'build a website... audit Solidity... contracts, tests, frontends and images' and again as 'build a website, research report, audit, contract, Foundry tests, adversarial review, frontend, image or logo'). The actual action request ('Get a free checked quote first') appears only halfway through.

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 should explain what a quote contains, but it only mentions expiry and that it is 'checked' and free. Payment currency, chain, and refund behavior are covered, so the gap is moderate rather than severe, but an agent still cannot anticipate the quote's fields.

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 every parameter and its enum, which sets the baseline at 3. The description marginally reinforces the work kinds (mentioning the 4-specialist-plus-judge audit, Foundry tests, adversarial review) but adds no new constraints, defaults, or parameter-level guidance beyond that.

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 does convey that this tool produces a free checked quote for hiring swarm agents, but that statement is buried mid-paragraph after a long capability list ('build a website, write a sourced research report, audit Solidity...'). It never crisply separates itself from siblings like swarm_order or swarm_job, so an agent must infer that this step precedes ordering.

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 an explicit when-to-use signal ('Use when an agent needs work an LLM call cannot do alone') and an implied sequencing ('Get a free checked quote first'), but no named alternative tool and no when-not guidance. The routing to swarm_order for the actual purchase is left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts: the call is free (no payment/x402 flow required, unlike siblings such as swarm_order or payment_verify) and results are cached for 60 seconds, which tells the agent the data may be up to a minute stale. That is real value beyond the structured fields, though return shape is 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?

One sentence, so it is compact, but the opening 'Hire AI agents:' spends the most prominent position on a misleading action framing rather than the actual read purpose. The remainder is a dense comma list mixing metrics ('kinds', 'exact current price formula') with operational notes ('Free, cached 60 seconds'), which would read better split into what-it-returns and freshness/cost facts.

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

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

With no parameters and no output schema, the description carries the burden of describing the return payload, and it does list the headline metrics. However, vague items like 'kinds' and 'exact current price formula' are not explained, and there is no indication of response structure or how to combine this with swarm_quote for an actual purchase, leaving the agent short of what it needs to act on the data.

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 and there is no parameter semantics to explain. The description correctly implies a no-argument call, and nothing in it misleads about inputs.

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

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

The description enumerates the resource's contents (agents online, seats, completed jobs, completion rate, capacity, price formula), which does convey what the tool returns. But the leading framing 'Hire AI agents:' describes an action this tool does not perform, and there is no clear verb for the read itself (get/inspect). It only partially differentiates from siblings like swarm_quote, imd_swarm and services_pricing, which also deal with agents and prices.

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 statement of when to call this versus swarm_quote, swarm_order, imd_swarm, services_pricing or token_price, all of which sit adjacent in the sibling list. The 'cached 60 seconds' note hints at a freshness trade-off but never tells the agent to prefer a different tool when exact live pricing is required.

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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely non-redundant behavior: 30-second DexScreener caching and the fact that missing values are returned as unavailable rather than fabricated. It omits that the call is paid ($0.002 / holder discount), which is a material behavior for an agent deciding whether to call.

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

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

Two sentences, front-loaded with the usage trigger followed by the data payload; the field list and caching caveat both carry information. Slightly dense enumeration, but no wasted clauses.

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 correctly compensates by enumerating the returned metrics (price, liquidity, volume/change, FDV, market cap, pool/DEX, pair age, symbol/decimals). The notable omission is the paid-call/holder-pricing model, which lives only in the title and schema rather than the description.

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

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

Schema description coverage is 100% and each parameter — chain enum, token address, payment payload, holderWallet discount — is documented in the schema itself. The description adds no parameter-level detail (e.g. that only Ethereum/Base mainnet addresses are accepted) beyond what the schema already says, 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?

The description names a concrete verb+resource ('quick ERC-20 price on Ethereum or Base') and enumerates the returned fields, so an agent knows exactly what the tool produces. It does not explicitly contrast itself with nearby siblings such as token_verdict or imd_market, which is what would push this to 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?

'Use when an agent needs a quick ERC-20 price' gives a clear triggering condition scoped by chain (Ethereum or Base). There is no explicit when-not or named alternative, so the agent must infer the routing versus the verdict/research 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?

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial context beyond them: this is a paid x402 call with two price tiers, how to pass payment, that verdicts arrive with cited reasons and a list of checks that could not run (partial-result disclosure), and who operates it. That is material behavioral information the schema cannot convey.

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 purpose and verdict categories, then the check list, then the pricing/depth detail and payment instruction. Dense but nearly every sentence carries new information; the check enumeration is long but useful for judging coverage.

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 carries the return-value burden and does so reasonably: verdict categories, cited reasons, and the 'checks that could not run' field. It does not describe the structure of the cited-reasons payload or response size, but an agent has enough 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 coverage is 75%, and the description still adds meaning: it explains the quick versus deep depth split ('deep adds full hook inspection, IMD admission checks and a written explanation'), the $0.25 pricing, and instructs passing the x402 payload as `payment`. holderWallet is left entirely to the schema, which is acceptable given its long inline 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?

States a specific verb+resource ('token safety and security verification', 'pre-buy verdict on an Ethereum token') and enumerates the exact checks and possible verdicts. An agent can tell it apart from token_price, wallet_check, or hook_inspect without inspecting either 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?

Gives clear context ('when an agent needs a pre-buy verdict') and a concrete depth tradeoff (deep adds hook inspection, IMD admission checks, written explanation). It does not name alternatives or exclusions, even though siblings like hook_inspect, watchtower_check, and verdict_preview overlap in purpose.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's job is to add substance, which it does by disclosing the degradation behavior: 'Missing metadata and prices are marked unavailable.' It also implies the response shape (resolved ABI method vs raw selector fallback). It doesn't mention the paid x402 flow ($0.003 in the title), letting the payment parameter carry that.

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 dense, front-loaded sentence that leads with the trigger and then the payload. Every clause maps to a real returned field, but the run-on enumeration of nine items is slightly hard to scan compared with a short bulleted list.

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 carries the burden of describing the return value, and it does list the major fields plus the fallback for missing data. Remaining gaps are minor for a read-only lookup: nothing on invalid-hash errors or response format (JSON vs text).

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 every parameter (tx, chain enum, payment, holderWallet) is documented in the schema itself. The description adds only that both Ethereum and Base are supported, which the enum already states. Baseline 3 is appropriate 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?

Names a specific verb (explain/understand) and resource (Ethereum or Base transaction) and then enumerates exactly what the explanation contains: receipt, confirmations, block/time, sender, recipient, resolved method or raw selector, token transfers, gas in ETH and USD, and a plain-English line. That is unmistakably distinct from siblings like gas_now, wallet_check, or token_verdict.

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?

Opens with an explicit trigger: 'Use when an agent needs to understand an Ethereum or Base transaction.' It does not name a sibling alternative or a when-not condition, but the trigger condition is concrete enough that an agent can route to it without 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?

Annotations already declare read-only, idempotent, and open-world behavior, so the bar is lower. The description adds useful context beyond annotations: the per-IP daily rate limit, the verdict categories returned, and the fact that reasons and evidence accompany the verdict. The phrase 'full quick Token Verdict' is slightly ambiguous about whether the demo result is truncated, which keeps it from 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?

The description is two compact sentences: the first front-loads the free daily limit and what the tool returns, and the second routes the agent to token_verdict. Every sentence earns its place, though 'full quick Token Verdict' is awkward phrasing that briefly obscures meaning.

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-only tool with annotations and no output schema, the description covers the essentials: what is returned, the verdict categories, evidence inclusion, the free daily limit, and the fallback tool. The main missing context is how this demo relates to verdict_preview, which is not addressed.

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

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

With one parameter and 100% schema description coverage, the schema already documents the token address and its pattern. The description only restates that it is an Ethereum token, adding no syntax, format, or example detail beyond the schema, so the 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 states a specific verb and resource: return a Token Verdict (no issues found / caution / avoid) for an Ethereum token, including reasons and evidence. It also scopes the tool as the free per-IP demo and names the production sibling token_verdict, so an agent can tell it apart from other verdict tools 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?

It gives an explicit usage condition ('one full quick Token Verdict per IP per day, free') and names the alternative ('After that, use token_verdict'). The only gap is that it does not distinguish itself from verdict_preview, which also appears among the siblings and could be confused with a demo.

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?

Annotations already cover read-only, idempotent, non-destructive and open-world. Beyond that, the description adds two genuinely useful behavioral facts: the call is free and fast, and critically it returns NO verdict (a truncated result set), which prevents an agent from treating the output as a full assessment. It also discloses the external data dependency (DexScreener).

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 leads with the two decisive qualifiers (free, no verdict) before listing the return contents. It is dense but every clause maps to a returned field; the phrasing 'is this Ethereum token an IMD launch' is slightly awkward to parse but not 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?

No output schema exists, so the description must carry the return contract, and it does by enumerating the four result components. What is missing is failure behavior (invalid address, token with no hook, no DexScreener pair) for a tool that fans out to external data sources.

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 documents it at 100% coverage with a regex pattern for the 0x address. The description adds nothing about the parameter beyond context already in the schema, 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?

The description states a specific resource (an Ethereum ERC-20 token) and enumerates the exact outputs: IMD launch status, DexScreener market/liquidity, same-symbol IMD launches, and Uniswap v4 hook permission bits. The 'free and fast, no verdict' framing implicitly separates it from token_verdict, but the sibling is never named, so differentiation relies on inference.

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?

'Free and fast, no verdict' hints at when to prefer this over the full verdict tool, and 'preview' implies a lightweight first pass. However, it never names token_verdict as the alternative or states when not to use this tool, leaving the choice 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?

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower; the description adds real value by enumerating return contents and explicitly flagging that unknown identity or missing source data comes back unavailable rather than fabricated. It does not discuss the paid x402 call flow or the cost in the body (only the title hints at $0.003), leaving payment behavior to the schema.

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

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

A single front-loaded sentence that leads with the trigger and packs the return inventory into a compact list. It is dense but not padded; the only minor cost is a long run-on clause enumerating fields.

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 carries the burden of describing return shape, which it does well by listing the fields inspected. Annotations cover the safety profile and the schema covers the payment/holder mechanics, so what remains missing is only alternative-tool routing and rate-limit 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?

Schema description coverage is 100%, so chain, address, payment, and holderWallet are already documented with examples and the holder pricing rules. The description adds nothing to parameter meaning beyond restating that Ethereum/Base are the chains; 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 specific verb ('inspect') and resource (Ethereum/Base address) and enumerates exactly what is returned: EOA vs contract vs EIP-7702 delegation, verified source name, proxy evidence, ETH/USDC balances, nonce, first-seen evidence, labels. It does not differentiate itself from overlapping siblings like name_resolve, x402_seller_check, or watchtower_check, 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?

'Use when an agent needs to inspect an Ethereum or Base address' gives a clear triggering condition plus an explicit limitation ('Unknown identity or missing source data is explicitly unavailable'), which tells the agent not to rely on it for unknown addresses. It offers no when-not guidance or routing to alternative sibling tools for overlapping lookups.

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?

Annotations already declare read-only, idempotent, non-destructive, so the safety profile is covered. The description adds real semantic content beyond that: unchecked items are listed and must never be read as unchanged, plus the paid model ($0.01, half for holders) and crew provenance. It does not state cost of latency or any rate limits, 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 'Use when', then the changed-surface list, then two short routing/payment sentences. Dense but every clause carries information; the enumeration is long yet each item is a distinct checked surface.

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, and the description compensates by describing the return shape: per-change before/after values, block numbers, links, and an explicit list of checks that failed to run. For a paid read tool with three params, an agent has everything needed to invoke and interpret it.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds the payment flow ordering ('Pass the x402 payment as payment', and the schema's omit-to-get-terms pattern is reinforced by 'Free first' sibling routing). The holderWallet pricing explanation lives mostly in the schema, so credit is limited but present.

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: what changed on an Ethereum ERC-20 token or Uniswap v4 hook since the previous observation, then enumerates the surfaces checked (owner/admin, proxy upgrades, bytecode, pause, fees, supply, liquidity). This is clearly distinguishable from watchtower_watch (ongoing watching) and watchtower_sample (free sample) named in the text.

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?

Explicit trigger condition ('Use when an agent needs to know what changed ... since the previous observation') plus an explicit alternative: 'Free first: watchtower_sample.' The agent knows both when to call this and what to try before 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds value by disclosing cost ('Free'), the full coverage list, the explicit non-coverage, and that change thresholds and limits are included. Since there is no output schema, the enumeration of returned content (bytecode hash, EIP-1967 proxy slots, owner, paused, supply, fee getters, DexScreener liquidity) is genuinely useful behavioral context.

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?

Cost and scope are front-loaded in a single dense sentence with no filler. The parenthetical field list is long but each item is substantive, since no output schema exists to carry that information 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 zero-parameter informational tool with no output schema, the description supplies both what is inspected and what is deliberately excluded, plus thresholds and limits. It could be stronger by stating the response shape or explicitly pointing to watchtower_check as the action counterpart, but nothing essential 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter text is needed or expected.

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?

Names the subject (Watchtower's read scope on Ethereum mainnet ERC-20 tokens and Uniswap v4 hooks) and enumerates the exact data points covered, plus the negative scope ('what it does not check'). It reads as a documentation/scope endpoint rather than an action tool, but the word 'info' in the name plus the itemized content list make that distinguishable from watchtower_check, which actually performs checks.

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 leading 'Free.' and the scope/limits framing imply this is the place to learn what the checker does before or instead of running watchtower_check, but no explicit when-to-use or when-not-to-use statement is given. The agent must infer that watchtower_check is the action sibling and this is the informational one.

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?

The description says the first read of an address records a baseline, which is a persistent state change and makes later calls differ from the first. That contradicts readOnlyHint=true and idempotentHint=true, even though the description otherwise usefully discloses quotas and output contents.

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 quota is front-loaded, followed by the core read-and-compare behavior, output details, status counts, and baseline note. Every sentence contributes useful information and there is no padding.

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 does a good job explaining the before/after values, block numbers, links, status counts, and baseline behavior. It is still missing what happens when the 3-per-day limit is exceeded and how observations are scoped, but it is broadly complete for a two-parameter sample 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?

Schema description coverage is 100%, so both parameters are already well documented, including the enum and automatic kind detection. The description restates that the address is a mainnet ERC-20 token or Uniswap v4 hook but adds no syntax or format details beyond the schema.

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

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

The description uses a specific verb and resource: reads one Ethereum mainnet ERC-20 token or Uniswap v4 hook and lists changes since the last stored observation. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as watchtower_check or watchtower_watch.

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 free 3-per-day quota and the sample framing imply trial usage, but the description never states when to choose this tool over watchtower_check or watchtower_watch. The baseline behavior hints that repeated reads are expected, yet no explicit usage routing or exclusions are provided.

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

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

Annotations say readOnlyHint=false and idempotentHint=true, but the description carries the real behavioral payload: prepaid single term, no renewal or recurring charge, a stop control, and opt-in Telegram alerts on specific change classes including failing checks. It also states the return payload (baseline plus manage token), which annotations cannot convey. It does not explain how the stop is executed or what happens if the term expires, so it falls just short of full disclosure.

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 trigger condition, then terms, then mechanics and return value — a sensible order. Most sentences earn their place, though the alert-type list is dense and "Run by NIGHTSHIFT's Watchtower crew" is branding rather than actionable guidance.

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, and the description compensates by stating the return (baseline plus manage token). Duration, price, holder discount, delivery channel, monitored change classes, and cancellation capability are all covered. Gaps are minor: what the baseline contains and which tool performs the stop.

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

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

Schema coverage is 100%, so the 3 baseline would apply, but the description adds non-obvious semantics: "The paying wallet owns the watch," which determines ownership when caller and payer differ, and the instruction to pass the x402 payment as `payment`. It does not elaborate the address-target distinction (ERC-20 vs v4 hook) beyond what the schema already spells out.

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 — watching an Ethereum token or Uniswap v4 hook — and quantifies the service (hourly observations for 7 days). It is clearly distinct from one-shot siblings like watchtower_check, but it never names those siblings or states the contrast explicitly, leaving the agent to infer it.

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?

"Use when an agent or a holder wants an Ethereum token or Uniswap v4 hook watched" plus "Pass the x402 payment as `payment`" gives clear trigger and call mechanics, and the schema's "Leave it out to get the terms" documents the two-phase terms-then-pay flow. What's missing is an explicit exclusion pointing to watchtower_check/watchtower_info for agents who only want a one-time verdict or pricing.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds genuinely new behavioral context: a 'guarded live v2 challenge', 'bounded logs' for the seven-day window, and the fact that unavailable checks are reported back. That last point is a meaningful disclosure about partial-failure handling.

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 front-loads the trigger ('Use when...') followed by the enumeration of checks and the verdict return. Every clause carries information, though the enumeration is long enough to be slightly dense on first read.

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 compensates by naming the verdict values (no_issues_found, caution, avoid) and noting that unavailable checks are returned. That is enough for an agent to know what comes back and how to act on it; only failure/latency or pricing behavior for the paid call is left implicit.

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

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

Schema description coverage is 100%, with detailed per-parameter docs including the holder wallet discount and the optional payment payload. The description adds no parameter-level detail beyond what the schema already provides, 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 verb and resource ('check an x402 seller before paying') and enumerates the concrete checks performed (Bazaar listings, payment terms, live v2 challenge, seven-day Base USDC inflow, cited red flags). An agent can distinguish it from general siblings like wallet_check, though it doesn't name the alternative 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 opening 'Use when an agent needs to check an x402 seller before paying' gives clear triggering context. It does not name when-not conditions or sibling alternatives (e.g., payment_verify vs. this pre-payment check), so it stops short of full routing guidance.

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