GAIP Integration & Protocol Agent

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

Annotations already cover readOnly/idempotent/non-destructive/open-world, so the bar is lower. The description adds real context: it's free, no account required, inputs must be public and non-personal, and it returns fixes plus a receipt. It doesn't explain what happens on fetch failure vs validation failure in depth, but it discloses the safety and side-effect profile well.

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 use case, then invocation guidance, then return values and constraints — all in roughly three dense, high-value sentences 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 10-parameter tool with no output schema, it covers purpose, trigger, return states, and constraints. It could say more about the VERIFY_BEFORE_CALL mode and the receipt, but the schema descriptions fill most of that gap and nothing critical is missing from the description itself.

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

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

Schema coverage is 100% and each of the 10 parameters has its own description, so the schema already carries parameter semantics. The description only mentions url and reinforces the public/non-personal constraint; it adds little beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb+resource ('check an AI agent or MCP server'), states the questions it answers ('does it work, is it reachable, is its card valid'), and enumerates the exact return states. This clearly distinguishes it from siblings like gaip_observatory_lookup or the gaip_watch_* family.

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 explicit trigger phrases ('check this agent', 'is this MCP server up?') and instructs 'Pass just its url', plus constraints (inputs must be public and non-personal). This tells the agent both when to use and how to invoke it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds meaningful extras beyond that: it is free with no account, inputs must be public and non-personal, and the response includes the quoted rule, a timestamp and a signature. It stops short of describing latency 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?

Dense but well front-loaded: the trigger condition and the two arguments come first, followed by sources and return values. The parenthetical restatement of the title is slightly redundant, but every other 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 four possible verdicts and the accompanying evidence (quoted rule, time, signature). Combined with the annotations and a fully documented schema, an agent has everything needed to call and interpret this 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 coverage is 100%, so the schema already documents url, agent and user_agent in detail, giving a baseline of 3. The description adds value by indicating the required input shape and the public/non-personal constraint on the URL, plus the default '*' behavior context for the agent 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 states a specific verb+resource ('check permission before your agent fetches a page') and enumerates exactly what sources it consults (robots.txt per RFC 9309, AI-preference lines, RSL, tdmrep.json, llms.txt) and what it returns (ALLOWED/DISALLOWED/NO_RULE/UNKNOWN). This is clearly distinguishable from siblings like gaip_watch_register or gaip_diagnose_integration_failure.

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 this before your agent fetches a page' gives an explicit trigger condition, which is strong usage guidance. It does not name alternatives or state when NOT to use it, but the pre-fetch check framing is unambiguous enough that an agent knows the context.

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 readOnlyHint=false, the description usefully explains the side effect ('records a GAIP receipt only') and adds cost/auth context ('Free, no account') plus a data constraint ('inputs must be public and non-personal'). It also pre-announces the return taxonomy (BREAKING/NON_BREAKING/INFO with migration notes). It stops short of disclosing failure modes 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?

Four tight sentences, front-loaded with the trigger and naming the required params, then output shape, then cost/constraint caveats. Every sentence carries information an agent needs.

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 tool with nested objects and no output schema, the description covers the trigger, required inputs, return classification and side effects/constraints. The optional GAIP plumbing parameters (continuity_handle, episode_id, etc.) are left to the schema, which is acceptable given full coverage.

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 fully documents all 10 parameters including enums and nested objects. The description only names `prior` and `current`, adding nothing the schema does not already provide; 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 pairs a specific verb (compare/what changed) with the exact resource set (agent card, MCP server description, OpenAPI document) and gives a plain-language trigger ('did this API break?'). An agent can distinguish this from generic change tools such as gaip_manifest_changes 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 gives an explicit when-to-use condition ('Use this when asked what changed between two versions') and the required inputs. It does not name or exclude sibling alternatives, so it falls short of a full routing rule but the context 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?

Beyond the annotations, it discloses the side effect ('GAIP touches no other system'), the auth/cost model ('Free, no account'), exactly what is persisted ('records a GAIP receipt only'), and a data-handling constraint ('Inputs must be public and non-personal'). This accounts for the non-readOnly/non-idempotent annotation profile by explaining that only a receipt is written.

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 is front-loaded with the triggering scenario and what to pass before moving to outputs and constraints, and every sentence carries information. It is dense and slightly parenthetical-heavy, but there is 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 still enumerates the return contents (likely cause, when/how to retry, fix steps, receipt), and with 9 params at 100% schema coverage the remaining fields are self-documenting. 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 coverage is already 100%, so the baseline is 3, but the description adds real meaning: it clarifies the required 'failure' payload shape ({code, detail}) and, notably, that raw error text is an acceptable alternative input. It does not explain the optional continuity_handle or episode_id linkage beyond what the schema already states.

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+resource — diagnosing a failed agent/MCP/API call and returning cause, retry guidance, and fix steps. It is clearly distinguishable from siblings like gaip_observatory_lookup, gaip_watch_events, or check_agent_conformance, which observe or monitor rather than diagnose a single failure.

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 concrete invocation triggers ('why did my call fail?', 'what does this 429 mean?') and tells the agent what to pass (the failure object or raw error text). It does not name an explicit alternative tool or state when NOT to use this, so it stops short of a full routing rule.

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/non-openWorld, and the description adds genuinely new context: the log is hash-chained with before/after hashes, neutral facts and receipts, and no account is required. It does not discuss pagination or how far back the log goes, which would push it to 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?

Two sentences, use-case front-loaded, parameter list compact. No filler, though the parameter enumeration is largely redundant with the 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?

No output schema exists, but the description explains the return payload (before/after hashes, neutral facts, receipts), plus auth and input constraints. An agent has enough to call it correctly; only paging/limits on depth are 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 all three parameters are already documented. The description restates their names and formats rather than adding syntax or edge-case meaning (e.g., behavior when target_id matches nothing, or timezone handling), so baseline 3 applies.

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

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

Names a specific resource (the Observatory's manifest-change log) and the verb (retrieve what changed), and the title/description combination makes the output kind explicit (hash-chained log with before/after hashes). It does not explicitly contrast itself with siblings like gaip_watch_events or gaip_observatory_lookup, so 4 rather than 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?

Gives a concrete trigger scenario ('what changed this week?') that an agent can pattern-match, plus preconditions (free, read-only, no account, inputs must be public and non-personal). It stops short of naming when to prefer a sibling tool instead, so no exclusion guidance.

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

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

Goes well beyond the annotations by disclosing operational behavior: reads once with robots.txt respected, never issues tools/call, re-reads daily, and returns capture id, time and SHA-256 hashes. It also states cost/auth posture (free, no account) and the receipt-only side effect, which explains why readOnlyHint=false while destructiveHint=false.

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 sentences, front-loaded with purpose, then behavior, then constraints. Every sentence carries information; the only mild redundancy is restating the public/non-personal constraint already implied by 'public MCP server'.

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, but the description supplies the essential return shape (capture id, time, SHA-256 hashes), the read semantics, the side effect, and the input constraints. Nothing an agent needs to call this 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 coverage is 100%, so the schema already documents both url and protocol (including the enum and the /.well-known inference rule). The description reinforces that url is the required input but adds no format or constraint detail beyond what the schema provides, 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?

Names a specific verb (save) and resource (dated record of what a public MCP server or A2A agent card declares now), and explicitly rules out what it is not ('Not an assessment'), which separates it from assessment-oriented siblings like check_agent_conformance. An agent can identify the target class (MCP endpoint or A2A card) 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 clear context: use this to snapshot a public server/agent card, pass its url, inputs must be public and non-personal. The 'Not an assessment' line implicitly excludes the conformance-checking alternative, but no sibling is named explicitly, so the routing is implied rather than spelled out.

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 the description adds real value beyond them: 'Free, read-only, no account; inputs must be public and non-personal.' It also discloses the return payload categories (status history, manifest hash, conformance codes, change log) and the key negative ('Not an assessment').

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 trigger condition, then the inputs, then the return payload, then constraints, in four tight sentences with no filler. Every clause carries actionable 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 carries the return-value burden itself and does so by enumerating what comes back (status history, manifest hash, conformance codes, change log). Combined with the auth/privacy constraints and the 'Not an assessment' scope note, 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%, so the schema already documents url, name, and target_id, establishing a baseline of 3. The description only echoes 'Pass its url or name' and adds no format, precedence, or conflict-resolution detail (e.g., which wins if both url and name are supplied).

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?

Specific verb ('look up') plus resource ('an MCP server's or agent's history'), with example questions that nail the intent. It partially differentiates from siblings via 'Returns dated facts ... Not an assessment,' which carves space against check_agent_conformance and gaip_supplier_reliability, but never names an 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?

Explicit when-to-use trigger ('Use this when asked about a server's or agent's history') reinforced with two concrete user phrasings ('has this server changed?', 'was it up last week?'). No explicit when-not or named alternatives, but the 'Not an assessment' line implies the boundary.

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, non-destructive and non-open-world, but the description adds genuinely new behavioral facts: it is free, requires no account, inputs must be public and non-personal, and results are time-correlated observations rather than causal claims. That last caveat is important for interpretation and is not in any structured field; only rate limits and the meaning of idempotentHint=false (repeated calls may return different observations) are left unstated.

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 sentences, front-loaded with the usage trigger before inputs and traits, so every sentence does work. It is slightly dense with stacked parentheticals and prose asides, but nothing is wasted.

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

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

With 11 params, nested objects, and no output schema, the description does the necessary compensating work by summarizing the return ('diagnosis plus changes observed... with receipts'). The one real gap is the missing boundary against gaip_diagnose_integration_failure, which matters given the overlap in inputs and purpose.

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 11 well-documented params, so the schema already carries parameter meaning. The description names supplier_url and failure but adds no format, defaults, or constraint detail beyond the schema, making 3 the correct 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 gives a specific trigger and outcome: it diagnoses why 'a supplier agent or API you depend on started failing' and returns 'the diagnosis plus changes GAIP observed around then.' That is a clear verb+resource, but it never names or contrasts with its only sibling, gaip_diagnose_integration_failure, which the input schema itself references ('as for gaip_diagnose_integration_failure'), so the supplier-vs-integration boundary is left ambiguous.

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 opens with an explicit selection condition ('Use this when a supplier agent or API you depend on started failing') and even supplies the user's likely phrasing ('did something change on their side?'). There is no when-not guidance and no pointer to the sibling for the alternative case, which keeps it 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, and non-destructive behavior, so the bar is lower. The description adds meaningful context beyond them: it returns "dates, change classes, stored hashes and whether yours match," is "facts, not a verdict," is free with no account, and requires public non-personal inputs. That is genuinely useful disclosure for a check 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 compact and front-loads the trigger ("Use this before connecting") ahead of mechanics and constraints. Every sentence carries weight, with only the param recap being arguably redundant against the 100%-covered 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?

For a six-parameter, no-required, no-output-schema tool, the description covers purpose, usage timing, return contents, and privacy/auth constraints. It is nearly complete; only explicit sibling differentiation and result-shape nuance are missing, which is minor.

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 all six parameters in detail, including formats and constraints. The description only loosely restates url, since, and the digest option without adding syntax or semantics beyond the schema, so the baseline 3 is correct.

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

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

The description states a specific verb and resource: checking whether an MCP server's tools changed since a given date, framed as a pre-connection check. It is clear about what it does, but it does not differentiate itself from close siblings such as gaip_manifest_changes or gaip_compare_supplier_snapshots.

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 this before connecting to an MCP server" gives an explicit usage context and timing. However, it names no alternatives and states no when-not condition, so the agent must infer how it differs from the overlapping manifest-change sibling.

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 carry readOnly/idempotent/non-destructive, but the description adds genuinely new context: it is free, needs no account, and requires inputs to be public and non-personal. It also discloses the shape of the result, which the annotations do not.

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 with the trigger front-loaded and the return payload second. 'Read-only' is restated even though annotations cover it, a small redundancy, but nothing else 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 output schema, the description usefully summarizes return fields and auth requirements, and the nested continuity_handle is documented in the schema. It is close to complete; pagination/ordering of the returned events is left unstated.

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

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

Schema description coverage is 100%, so the schema already documents limit, watch_id, and continuity_handle. The description only reinforces the continuity_handle's ownership role ('proves you own these watches'), adding marginal meaning over 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 specific verb+resource ('Read watch change events') and enumerates what comes back (verdict before/after, change summary, receipt and webhook delivery status). It implicitly separates itself from gaip_watch_list and gaip_watch_register, but never names the alternative explicitly, so a sibling-aware agent still has to infer the boundary.

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

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

'Use this when asked what changed on a watched agent or service' gives a clear triggering context, and it tells the caller to pass continuity_handle and optionally watch_id. It stops short of naming when NOT to use it (e.g., listing watches vs. reading events).

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 and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: exactly which fields come back (kind, target, last verdict, last/next check, webhook endpoint), that the secret is never returned, and that the operation is free with no account — a solid supplement 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?

Three compact sentences: trigger first, the single required input second, the return shape and safety limits last. No filler, no repetition of the name or 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 present, the description compensates by enumerating the returned fields and explicitly noting the secret is excluded. Combined with the annotations covering the safety profile and the fully-described single parameter, an agent has everything needed to call this 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?

Only one parameter exists and schema description coverage is 100%, with the schema itself explaining that the handle 'proves you own these watches.' The description only restates 'pass your continuity_handle,' adding no format or provenance detail beyond 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?

States a specific verb and resource — listing the watches the caller owns — and names the trigger explicitly ('when asked which agents or services you are watching'). It implicitly separates itself from gaip_watch_events (events vs. watch list) and gaip_watch_register/remove, but it never names a sibling outright, 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 this when asked which agents or services you are watching' gives a clear, concrete activation context, and the read-only/free framing tells the agent this is safe to call unprompted. No explicit when-not or named alternative is given, so it is clear context without 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?

Despite annotations covering safety (readOnlyHint false, destructiveHint false, openWorldHint true), the description adds substantive behavior: 24-hour re-check cadence, a 3-watch free quota, per-change receipting, optional webhook callbacks, no-account/free cost model, and a public/non-personal data constraint. That is exactly the context annotations 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 usage trigger, then constraints and cost, in three tight sentences. Slight redundancy in 'Free, no account; records a GAIP receipt only,' which restates cost twice, but nothing is wasted overall.

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 an 8-parameter, nested-object, no-output-schema tool, the description covers cadence, quota, side effects, and data policy well, and the schema carries the parameter detail. It never says what registration returns (no watch id/handle mentioned), which is the main gap for an agent needing to reference the watch later.

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 explains kind, target_url, sla, interval_hours, webhook_url, and the nested continuity_handle. The description mostly echoes those names ('Pass the continuity_handle from any GAIP result, kind and target_url') with only the marginal addition of 'from any GAIP result'.

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 combination ('keep an eye on an agent or MCP server') and pairs it with the trigger phrase users actually say ('tell me if it changes or goes down'). It implicitly distinguishes registration from the sibling gaip_watch_list / gaip_watch_remove / gaip_watch_events tools, but never names them, so an agent must infer the boundary.

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

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

It gives an explicit when-to-use condition keyed to a user utterance, which is rare and helpful. However, it names no alternatives (e.g. one-shot checks vs. recurring watches) and states no exclusion criteria, so the agent must infer when a watch is the wrong 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?

Annotations declare destructiveHint=true, but the description goes well beyond them: it specifies exactly what is destroyed (stored events), what survives (retained receipts stay verifiable), the cost/auth model (free, no account), the side effect (records a GAIP receipt), and an input constraint (public, non-personal). This is unusually rich behavioral disclosure for a destructive operation.

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

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

Four short sentences, front-loaded with the trigger condition, then the required inputs, then the destructive/retention semantics. No filler and no repetition of the 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?

For a destructive, two-parameter tool with nested inputs and no output schema, the description covers the trigger, the required arguments, destruction scope, retention behavior, cost/auth, and input constraints — everything an agent needs before invoking 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 description coverage is 100% and the schema already documents both watch_id (returned by gaip_watch_register) and continuity_handle (proves ownership). The description restates that both must be passed but adds no format or edge-case detail beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource — stop/remove a watch on an agent or service — and pairs it against the register flow via the required watch_id, so an agent can tell it apart from gaip_watch_register or gaip_watch_list 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?

"Use this when asked to stop watching an agent or service" gives an explicit trigger condition. It does not name a when-not case or explicitly contrast with gaip_watch_list (view) versus this removal tool, so the guidance is clear but not exhaustive.

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