Ned Watch

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return contents (which substitutes for the missing output schema) and implies a read-only, account-scoped operation via 'Your balance', but says nothing about authentication requirements, rate limits, or whether the figures are real-time. Adequate but with clear gaps for a zero-annotation tool.

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

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

A single fragment that front-loads the core concept ('Your balance in cents') and lists the remaining fields compactly. Every clause earns its place, though the absence of a verb makes it read more like a label than an instruction.

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 must describe the returned data, and it does list all the expected fields. What is missing is any framing of when the result matters (e.g. checking remaining allowance before a paid call), so it is complete on surface but thin on decision context.

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

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

The tool takes zero parameters, so the baseline is 4. There are no inputs whose semantics could be clarified, and the description correctly focuses entirely on outputs instead.

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 (the account balance) and enumerates the specific values returned: balance in cents, free allowance used, burn per day, days left, and top-up routes. That is concrete enough for an agent to know what this tool yields, but it does not differentiate itself from the sibling 'pricing' tool, which an agent might reasonably confuse with billing/balance information.

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 statement, no condition that selects this tool over siblings, and no exclusion of alternatives. The presence of both 'balance' and 'pricing' in the sibling set makes this omission notable, since the agent must guess which one answers a cost/credit question.

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

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

With no annotations, the description carries the full burden and does disclose the non-obvious auth mechanics: the signing_secret is passed as `Authorization: Bearer <signing_secret>` for this call and no agent key is required. It does not say what happens when a check-in is late, whether it is idempotent, or what the response looks like, leaving some gaps for a tool whose whole purpose is timing.

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

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

Three short sentences, front-loaded with the purpose and effect before the auth detail. No wasted words and nothing buried.

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

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

With no output schema and no annotations, the description covers purpose, auth, and credential provenance, which is the core of calling this correctly. It omits failure/timing behavior and return values, but those are secondary for a check-in call.

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

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

Schema coverage is 0%, so the description must compensate, and it fully explains signing_secret's origin ('returned at registration') and transport (Bearer header). watch_id is left unexplained, but its role is obvious from the name, so the one genuinely non-obvious parameter 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?

States a specific verb and resource ('check in on a deadman watch') and the outcome ('keep it from firing'), which clearly separates it from the sibling mutation tools watch_cancel and watch_register. An agent can tell what this does without opening the schema.

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

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

The description implies recurring use ('keep it from firing') but never states when to call it versus watch_cancel, watch_get, or watch_register, nor any timing/deadline constraint that matters for a deadman switch. Usage is inferable but not explicit.

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

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

With no annotations, the description carries the full behavioral burden and does disclose two useful traits: the endpoint is public/no-auth, and it is not the payment path (mutations live at POST /v1/topup). It stops short of stating plainly that the operation is a side-effect-free read, but the content makes that evident.

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 dense sentences, front-loaded with the free-tier and rate information an agent is most likely to need, ending with the routing caveat. The parenthetical rate list is information-dense but relevant rather than 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?

No output schema, no parameters, no annotations, so the description has to carry the payload meaning — and it does convey the actual pricing facts (5 free watches at >=300s, per-day rates, prepaid balance via x402/USDC on Base). An agent has enough to answer pricing questions and to redirect payment attempts.

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

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

Zero parameters, so the baseline of 4 applies. Nothing in the schema needs elaboration and the description correctly does not invent parameter details.

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 makes clear this tool surfaces Ned Watch's pricing schedule (free tier, per-day rates) and is distinguishable from siblings like balance and watch_register. The verb is implicit (it never literally says 'returns the pricing schedule'), but the resource and scope are 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?

It states 'Public, no key needed' and explicitly routes payment actions elsewhere: 'Paying is done against POST /v1/topup/{5,20,50}, not here.' That is a genuine when-not-to-use-this signal tied to an alternative. It does not, however, describe when an agent should prefer this over the sibling 'balance' tool.

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

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

With no annotations, the description carries the full burden and does well: it discloses the failure behavior (missed check-in triggers a signed POST to callback_url), the recovery behavior ('check in again and he says it's clear'), and the sensitive return values (agent_key shown once, signing_secret). It omits error states, key-loss recovery, and any rate limits, keeping it 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-loads the value proposition, then covers mechanics, returns, and pricing. Dense but every clause carries information; only the pitch-flavored opening phrase is mildly redundant.

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 2-param, no-annotation, no-output-schema tool, it explains inputs, side effects, return values, and cost. What an agent needs to invoke it correctly is present; only failure/edge-case handling is thin.

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 compensate, and it does: it defines every_minutes with a valid range (5 to 1440) not present in the schema, and explains callback_url as the destination for the signed POST on a missed check-in. The default value of 60 is left to 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?

States a clear compound purpose: it creates an agent identity and a deadman watch in a single call, making it the 'fastest way to be watched'. That is specific and distinguishable from siblings like watch_register, though it never names an alternative explicitly to sharpen the contrast.

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 one conditional ('if you have no key yet') for the agent-creation half and states the free-tier limit, which implies this is the onboarding path. It never says when to prefer this over watch_register or deadman_checkin, so routing among siblings is left to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral consequence: cancelling frees a free-tier slot. However, it says nothing about idempotency, what happens if the watch_id does not exist, or whether the cancellation is reversible.

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, zero waste, action stated first and the side effect second. Nothing to trim.

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 tool with no output schema this covers the core action and its main side effect, but omits error behavior for an unknown or already-cancelled watch_id and gives no sense of the response.

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 watch_id parameter has no schema description. The phrase 'a watch you registered' hints that watch_id identifies a previously created watch, but no format, source, or validation guidance is given.

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 (Cancel) and resource (a watch), and adds scope ('you registered') that separates it from watch_register and watch_get. It never names a sibling, so an agent must infer the distinction from the name alone.

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 'a watch you registered' – you cancel watchers you previously set up – but there is no explicit when-to-use, when-not-to-use, or mention of watch_get/watch_register as the complementary operations. Adequate but leaves routing 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read but never states that it has no side effects, nor does it cover behavior for an unknown watch_id or any permission requirements.

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

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

One compact sentence that front-loads the resource before the field list, with no wasted words. Every listed field earns its place given there is no output schema.

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?

Enumerating return fields compensates for the missing output schema on a simple one-param read. However, with no annotations and no param documentation, error behavior and the meaning of watch_id remain unstated.

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

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

Schema description coverage is 0%, and the description adds nothing about watch_id — it doesn't say whether it's the watch's name, UUID, or a returned id. The single parameter is near self-evident from its name, but the description does not 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?

States a specific resource (one of your watches) and enumerates the returned fields, so the agent knows this is a read of watch state. It does not explicitly distinguish itself from siblings like watch_register or watch_cancel, but the 'current state' framing implies a read.

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

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

There is no guidance on when to use this versus watch_register, watch_cancel, or deadman_checkin, and no prerequisites or exclusions are mentioned. Usage is only implied by the field 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?

With no annotations, the description carries the full burden and does so well: it discloses the free-tier interval floor (interval_s >= 300), that Ned POSTs a signed test callback to callback_url within 60s, that firing happens only on change, and that the agent_key is returned once and must be stored. It stops short of describing failure modes or what happens on invalid targets.

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?

Dense and front-loaded — the operation and type enumeration come first, followed by parameter semantics and then the bootstrap flow. Telegram-style phrasing is compact without padding, though the run-on lines trade some readability for brevity.

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 5-param mutation tool with no annotations, 0% schema coverage, and no output schema, the description covers nearly everything an agent needs: types, target rules, condition shapes, interval floor, callback timing, and the agent_key bootstrap. Only callback_url expectations and error behavior are 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 0%, so the description must compensate and largely does: it maps type values to target semantics (URL for http/tls, omit for deadman), gives per-type condition examples (warn_days, grace_s, max_ms), and states the interval_s constraint. callback_url is only implied by the callback behavior rather than explained directly.

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 ('Register a watch') and immediately enumerates the supported watch types (http | tls | deadman), so the agent knows what operation this is. It does not explicitly differentiate itself from siblings like watch_get or watch_cancel, but the name and type enumeration make the distinction obvious.

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

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

Provides useful workflow context — the bootstrap sequence (call without an agent key first, store the returned agent_key, pass it as NED_AGENT_KEY next time) is clear guidance for a first-time caller. However, it never states when to prefer this tool over watch_get/watch_cancel or what prerequisites (e.g., auth) are otherwise required.

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