Wake me when my agent misses its heartbeat. Deadman, overrun, HTTP, TLS, content; US+EU nodes.
Scored across 12 tools
Most tools have clearly distinct roles, but watch_register (types deadman|http|tls), content_watch, overrun_watch, and quickstart all register monitoring, which creates some overlap. The descriptions explicitly route users ('for overrun and content use overrun_watch / content_watch'), which keeps selection tractable but not perfectly clean.
Eight of twelve tools follow a consistent resource_action pattern (watch_get, watch_cancel, watch_register, overrun_start, overrun_finish, content_watch, deadman_checkin), which is predictable. The outliers (balance, pricing, quickstart, is_up) are simple nouns/predicates and still readable, so only a minor deviation.
Twelve tools is within a reasonable scope for a monitoring service with several watch types and an overrun lifecycle. Slight redundancy exists since three separate registration tools plus quickstart all create watches, but each still earns its place.
Core lifecycle is well covered: register (watch_register/content_watch/overrun_watch/quickstart), inspect (watch_get), cancel (watch_cancel), check-in, run start/finish, and billing (balance/pricing). The notable gap is a list-all-watches operation, forcing agents to track watch IDs themselves, but this is workaroundable.
Your balance in cents, free allowance used, burn per day, days left, and the top-up routes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Fire when a URL answers but says the wrong thing. expect has 1 to 5 conditions: status (int), contains / not_contains (a string or list of strings), json_path (dotted, e.g. "data.items.0.state") with equals (a JSON scalar) or exists (true/false). No regex. Pages over 256 KB fail as 'size'. The callback names the condition that failed, never the page's content. 2c/day at >= 60s, 7c at >= 30s; free within the first 5 at >= 300s. Example: expect={"status": 200, "json_path": "status", "equals": "ok"}
| Name | Required | Description | Default |
|---|---|---|---|
| expect | Yes | ||
| target | Yes | ||
| interval_s | No | ||
| callback_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: no regex support, pages over 256 KB fail as 'size', the callback reports only the failing condition name and never page content, plus concrete rate/cost tiers. It omits auth requirements, retry/failure behavior, and lifecycle (how the watch is cancelled or inspected, despite a watch_cancel sibling), which keeps 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?
Everything is front-loaded: trigger semantics first, then expect grammar, then failure modes, then cost, then a concrete example. The telegraphic style ('No regex.', '2c/day at >= 60s') is dense but each fragment carries unique 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?
For a tool with a nested free-form object parameter, no output schema, and no annotations, the description supplies the assertion grammar, the size failure mode, the callback payload contract, and pricing. What is missing is the target/callback_url contract (URL format, HTTP method/payload shape) and the watch lifecycle, which siblings like watch_cancel/watch_get presumably handle.
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% and the key parameter is an opaque nested object with additionalProperties:true, yet the description fully specifies its grammar: 1-5 conditions of status (int), contains/not_contains (string or list), and json_path (dotted, e.g. "data.items.0.state") with equals (JSON scalar) or exists (bool). interval_s is only implied via the pricing thresholds, and target/callback_url are left as bare names.
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 opening line states a specific trigger condition for a content-based watcher ('Fire when a URL answers but says the wrong thing'), which is far more informative than a name restatement. It never names a sibling (watch_register, overrun_watch, deadman_checkin) to distinguish this content-checking watch from the other watch tools, so the reader must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the expect grammar and the pricing tiers (2c/day at >=60s, free within the first 5 at >=300s) tell the agent this is for recurring content assertions, but there is no explicit when-to-use/when-not or pointer to an alternative watch tool. The worked example is the only concrete invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check in on a deadman watch to keep it from firing. Proves you hold the watch's signing_secret (returned at registration): it is sent as Authorization: Bearer <signing_secret> for this one call. No agent key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| watch_id | Yes | ||
| signing_secret | Yes |
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.
Ask before you call. No key needed. Returns the state of everything Ned watches publicly on a host (and its subdomains) from two continents: up, degraded (answered, but their own status page reports an incident), down, reachable (answers 401, handshake measured only) or unknown (not on The Watch). Also since when, the last change seen (tool list, version, auth) and how soon to ask again. Try api.openai.com, api.anthropic.com, mcp.context7.com, status.github.com. If unknown, the answer says how to add it (first five watches free).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes |
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 that no API key is required, defines each possible state (e.g. 'degraded' = answered but the status page reports an incident, 'reachable' = answers 401, handshake only), and notes additional returns (since when, last change seen, when to ask again). It omits error behavior for malformed hosts and any concrete 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?
It front-loads the key facts, but the second sentence is a long run-on carrying multiple parenthetical definitions, and the tagline 'Ask before you call' is more marketing than instruction. Content mostly earns its place, yet the delivery is denser and less scannable than it should 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?
There is no output schema and no annotations, and the description covers the state vocabulary, extra returned fields (since when, last change, next ask time), and the unknown-host workflow, which is nearly everything an agent needs. It stops short of specifying error cases or a precise polling interval.
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 required 'host' parameter is undocumented in the schema, so the description must compensate. It does so with four concrete example hostnames, which make the expected format (bare domain, subdomains included) clear, though it never explicitly states the required format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It states a concrete verb and resource: it returns the live state of a host (and its subdomains) that the service monitors. The enumerated state vocabulary (up, degraded, down, reachable, unknown) makes the purpose precise, but it never references or differentiates itself from sibling tools such as watch_get or watch_register.
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 a clear use context ('Ask before you call. No key needed') and concrete example hosts (api.openai.com, api.anthropic.com, mcp.context7.com) that show the intended pre-flight check scenario. It also covers the unknown case and how to register a host, but names no alternative tool, so there is no explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The run ended. Returns runtime_s and late. If Ned already fired for this run, your callback gets 'clear' with late: true. Finishing with no run open is an error (409). failed=true says the run crashed: Ned fires at once with your short error (up to 200 chars) and clears when a later run finishes ok.
| Name | Required | Description | Default |
|---|---|---|---|
| error | No | ||
| failed | No | ||
| run_id | No | ||
| watch_id | Yes | ||
| signing_secret | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does meaningful work: it discloses the 409 error on an open-run mismatch, the 'clear'/late:true callback behavior when Ned has already fired, and that failed=true triggers immediate Ned firing with a 200-char error bounded message. The unexplained jargon 'Ned' and omission of any auth/permission model keep it from being fully transparent.
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 state change and reasonably sized at four sentences, but it leans on undefined jargon ('Ned', 'clear') and packs several distinct behaviors into dense run-on clauses, reducing immediate 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, no annotations, and five parameters at 0% coverage, the description should do more. It does describe return fields and key failure modes, but omits auth/secret handling and the meaning of watch_id/run_id, leaving an agent with gaps for a multi-parameter mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain error (up to 200 chars) and the semantics of failed=true, but says nothing about watch_id, signing_secret, or run_id, leaving half the parameters semantically opaque.
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 opening 'The run ended' identifies the resource (a run) and implies the completing action, and it names return fields (runtime_s, late). It stops short of an explicit verb+resource phrasing ('finish/end a run') and never contrasts itself with overrun_start, so an agent must infer the pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'The run ended' tells the agent it is called at the end of a run, and 'Finishing with no run open is an error (409)' gives one precondition. It names no alternative from the siblings (overrun_start, overrun_watch) nor when-not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A run began on an overrun watch. Returns run_id and deadline. Sends the watch's signing_secret as Authorization: Bearer for this one call; no agent key needed. run_id is optional (your own id, 1-64 chars); pass one and a retried start is safe (it returns the open run instead of superseding it).
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | No | ||
| watch_id | Yes | ||
| signing_secret | Yes |
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 auth model (signing_secret as Bearer, no agent key needed), the return values (run_id, deadline), and idempotency behavior when run_id is supplied. It only weakly implies the default superseding side-effect without run_id, so it falls 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?
Four compact sentences, front-loaded with purpose then return values, auth, and the optional parameter's semantics. No filler, though the ordering of the auth detail before the run_id note is slightly less than ideal.
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 fills that gap by naming the returns (run_id, deadline). Auth, idempotency, and the optional parameter are covered; only the default supersede behavior and watch_id semantics remain 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 description coverage is 0%, so the description must compensate. It explains run_id thoroughly (optional, 1-64 chars, retry-safe) and clarifies signing_secret's role as the Authorization bearer token. watch_id is left undocumented, but its meaning is clear from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'A run began on an overrun watch', which maps to starting a run and is distinguishable from siblings overrun_finish and overrun_watch. It does not explicitly name an alternative sibling, but the resource 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?
Usage is implied by the tool's role (starting a run) but there is no explicit when-to-use vs when-not, nor a pointer to overrun_finish or overrun_watch. The idempotency note hints at retry scenarios but doesn't frame guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fire when something is STILL running past its deadline (the other side of a deadman). Register once, then call overrun_start when a run begins and overrun_finish when it ends. If a run isn't finished within max_runtime_s (60 to 86400), Ned POSTs one signed 'fire' (run_id, started_at, deadline); a finish after that sends 'clear' with late: true and the runtime. A start while a run is open closes the old one as superseded (no callback). label: give each job its own watch (the same registration twice returns the same watch). 1c/day; counts toward the free 5.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| callback_url | Yes | ||
| max_runtime_s | Yes |
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 richly: it specifies the signed 'fire' payload (run_id, started_at, deadline), the 'clear' payload with late:true and runtime, the superseded-start behavior with no callback, idempotent re-registration returning the same watch, and the billing impact (1c/day, counts toward the free 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?
Four dense sentences, front-loaded with the trigger condition and then ordered by lifecycle (register, start, finish, timeout, supersede), so the sequence reads naturally. The billing shorthand and compressed clauses are jargon-heavy but each sentence 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 and no annotations, the description covers the callback contract, supersede semantics, idempotency, and cost, which is most of what an agent needs. It does not describe what the registration call itself returns or any error/auth failure behavior, leaving a modest gap for a tool that provisions a persistent watch.
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 supplies the 60–86400 range for max_runtime_s (absent from the schema), explains label's per-job scoping and idempotency semantics, and implies callback_url's role via the POST description. The callback_url format and expected response are still left implicit.
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 precise verb and trigger condition ('Fire when something is STILL running past its deadline') and immediately positions it against the sibling concept ('the other side of a deadman'), which separates it from deadman_checkin and content_watch. An agent can identify the tool's role 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?
Gives an explicit workflow: register once, then call overrun_start when a run begins and overrun_finish when it ends, naming the exact sibling tools. It implies the deadman contrast but never states an explicit 'do not use this if...' exclusion, so it stops just 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.
Ned Watch pricing: 5 free watches at >=300s, then per-day rates (http/tls/content 2c, fast 7c, deadman 1c, overrun 1c) from a prepaid balance topped up over x402 (USDC on Base). Public, no key needed. Paying is done against POST /v1/topup/{5,20,50}, not here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it discloses the key trait an agent needs: this call is public with no key required, and it is read-only pricing information rather than a mutating/payment action. It adds the routing note that payments happen elsewhere, useful for avoiding a wrong invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Information is front-loaded with the resource name and free-tier rule, then rates and payment mechanics. It is dense with figures but every clause is payload for a pricing tool; the run-on structure is the only minor cost.
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 or annotations, the description does the heavy lifting by summarizing the pricing content the agent will receive and explicitly stating payment is not performed here. It is complete enough to call correctly, though it does not describe the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4. The description introduces no parameter semantics but none are needed for a no-arg informational call.
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 (Ned Watch pricing) and specifies exactly what it returns: free-tier limits, per-day rates, and the prepaid/x402 model. It also distinguishes itself from sibling tools like balance and quickstart by clarifying this is the rate reference, not the payment endpoint.
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 a clear usage condition ('Public, no key needed') and an explicit exclusion with the alternative named ('Paying is done against POST /v1/topup/{5,20,50}, not here'). It does not define when to consult this versus balance, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The fastest way to be watched, in one call. Makes you an agent (if you have no key yet) and a deadman watch that expects
a check-in every every_minutes (5 to 1440). Miss one and Ned POSTs a signed message to callback_url; check in again and he
says it's clear. Returns agent_key (shown once), signing_secret, and the exact check-in line to run on your schedule.
The first 5 watches are free. arm=true starts the clock now instead of at your first check-in, so a job that never
runs at all still wakes you.
| Name | Required | Description | Default |
|---|---|---|---|
| arm | No | ||
| callback_url | Yes | ||
| every_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers important behavioral details: it creates an agent and a deadman watch, returns agent_key shown once, signing_secret, and the exact check-in line. It also explains the failure behavior (missed check-in triggers a signed POST to callback_url) and the effect of arm=true, which is exactly the kind of side-effect disclosure an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the core value proposition and the rest is dense with useful detail. It is somewhat prose-heavy and could be more scannable, but every sentence adds operational meaning rather than restating the name or 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?
There is no output schema and no annotations, so the description must cover both behavior and returns; it does. It explains creation side effects, return values, failure behavior, pricing, and the arm option, leaving no critical gap for an agent invoking this composite onboarding 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 0%, so the description must compensate and does. It explains every_minutes as the required check-in interval with a concrete range (5 to 1440), callback_url as the destination for the signed message on a miss, and arm=true as starting the clock immediately rather than at first check-in.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific composite action: 'Makes you an agent (if you have no key yet) and a deadman watch' in one call. It distinguishes this quickstart from siblings like watch_register and deadman_checkin by emphasizing 'fastest way to be watched, in one call.' An agent can tell what the tool 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?
It clearly states the context: use this as the fastest way to get watched, especially if you have no key yet, and notes the first 5 watches are free. It does not explicitly say when not to use it or name an alternative sibling, but the one-call onboarding framing gives strong implied usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a watch you registered. Frees a free-tier slot.
| Name | Required | Description | Default |
|---|---|---|---|
| watch_id | Yes |
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.
Current state of one of your watches: status, fired, fire_count, next_check, last_state.
| Name | Required | Description | Default |
|---|---|---|---|
| watch_id | Yes |
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.
Register a watch. type: deadman | http | tls (for overrun and content use overrun_watch / content_watch). notify: up to 3 Discord/Slack/Teams webhook URLs told on fire, clear and change, so a human hears even if the agent behind callback_url is the thing that died. Your callback should outlive your agent. target: URL (http/tls); omit for deadman. interval_s >= 300 on the free tier. condition: e.g. {"grace_s": 600} for deadman, {"max_ms": 2000} for http latency, {"warn_days": 14} for tls. Ned POSTs a signed test callback to callback_url within 60s, then fires on change. No agent key yet? Call this without one: the response includes agent_key (shown once). Store it and pass it as NED_AGENT_KEY next time.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| notify | No | ||
| target | No | ||
| condition | No | ||
| interval_s | No | ||
| callback_url | Yes |
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 so well: it discloses the registration handshake (Ned POSTs a signed test callback within 60s then fires on change), the free-tier interval floor of 300s, and that a first call without an agent key returns an agent_key shown once. It omits only secondary details like idempotency or a full response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb and type enum, then organized by parameter, so it is easy to scan. A few sentences are dense and run-on (the callback/key bootstrap passage), costing some readability but not adding 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 complex bootstrap flow with no output schema, it covers the essentials an agent needs: how to register, the condition formats, the handshake, and the agent_key response. It stops short of describing the full return payload or failure modes, but nothing critical to a correct call 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 0%, so the description must compensate, and it documents all six parameters: type values, notify (up to 3 webhook URLs), target URL vs omission for deadman, interval_s floor, and concrete condition examples per type. This adds substantial meaning the bare schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Register a watch') and immediately scopes the type dimension, explicitly routing overrun and content cases to the overrun_watch / content_watch siblings. An agent can distinguish this from its sibling watch tools 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?
Gives the condition that selects alternatives ('for overrun and content use overrun_watch / content_watch') and per-type guidance for target and condition. It does not explicitly contrast against watch_get/watch_cancel, but the routing to the ambiguous siblings is covered clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
is_upwatch_register1 field changedInput schema / properties / notifyAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Notify"
+}overrun_finish2 fields changedInput schema / properties / errorAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Error"
+}Input schema / properties / failedAdded value: +{
+ "default": false,
+ "title": "Failed",
+ "type": "boolean"
+}quickstart1 field changedInput schema / properties / armAdded value: +{
+ "default": false,
+ "title": "Arm",
+ "type": "boolean"
+}content_watchoverrun_finishoverrun_startoverrun_watchbalancedeadman_checkinpricingquickstartwatch_cancelwatch_getwatch_registerDead-man switch monitors for cron & AI agents with dependency-cascade alerts. No account needed.
Dead-man switch for cron and webhooks: ingest URL, miss detection, alerts and a status feed.
Dead-man's-switch for cron jobs & AI agents. Import a crontab to arm one silent-miss alert per job.
Uptime monitoring for developers — monitors, incidents, heartbeats, maintenance, status pages
Add one secure layer between your agents and this server.
