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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate important non-obvious behavior: watchlist rows are removed, audit history is preserved, and any stored observations are migrated to the survivor measure. However, it does not explain concurrency implications of expected_revision, what happens to related records, or failure semantics, so transparency is partial.

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

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

The description is a single, dense sentence that leads with the primary action and adds only necessary behavioral qualifiers. Every clause earns its place and 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?

This is a destructive mutation tool with four undocumented parameters, no annotations, and no output schema. Although the description captures the core purpose and important invariants, it omits essential operational details such as what 'note' is for, how 'expected_revision' is used, what the result of a successful call looks like, and what validations or failure conditions may occur.

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, but it only hints at the meaning of survivor_measure_id and duplicate_measure_ids. It provides no guidance for the required 'note' parameter or for 'expected_revision', leaving the agent to guess their purpose and formatting.

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

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

The description uses a specific verb ('Remove') with a clear resource ('duplicate watchlist rows') and states the key defining behaviors: preserving append-only audit history and migrating observations to the survivor measure. This clearly distinguishes it from all listed sibling tools, none of which perform deduplication.

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 this tool is for consolidating duplicates on the watchlist, but it does not explicitly state when to use it, what preconditiones must hold, or which alternatives to consider. Since no sibling overlaps with this functionality, an agent can infer usage, but the guidance is implicit rather than explicit.

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

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

There are no annotations, so the description carries the full burden of explaining behavior. It discloses that the tool lists (implying read-only), but it does not explain how the as_of parameter affects the 'due' calculation, nor what 'active measures' means in this context.

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

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

The entire description is one concise, front-loaded sentence with no filler. Every word contributes to understanding the core function.

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?

Despite the low complexity of a single optional parameter, the description leaves critical details unexplained: the meaning of as_of, the definition of 'due', and the return format (no output schema exists). An agent could invoke the tool with the wrong date semantics as a result.

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

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

With 0% schema description coverage and a single undocumented as_of parameter, the description was expected to compensate, but it makes no mention of the parameter. The agent receives no information about allowed formats, defaults, or how as_of changes the 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 specifies a clear action ('List') and a specific resource ('active measures whose next-review date is due'), which is distinct from sibling tools like review_candidate or list_watchlist. However, it does not explicitly contrast itself with sibling list tools, so the differentiation is implicit rather than stated.

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

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

The description provides no guidance on when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. It only states what the tool does, leaving the agent to infer the appropriate context from the resource name.

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 must carry the full behavioral burden. 'List' and 'consolidated' communicate a read-only, likely grouped operation, which is useful. However, it does not disclose response structure, pagination, sorting, default time window, or any edge-case behavior, leaving transparency incomplete.

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

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

The description is a single sentence with no filler. The core action and the optional filter are front-loaded, and every word contributes to understanding the tool.

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 low-complexity optional-parameter list tool, the description captures the essential operation and parameter. However, with no output schema and no annotations, it omits any indication of the return shape or behavior when 'since' is omitted, leaving a modest gap.

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

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

The input schema exposes only a bare 'since' string with no description, and schema description coverage is 0%. The description compensates by specifying that the parameter is optional and expects an ISO datetime, adding format and requirement context beyond the schema.

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

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

The description uses the specific verb 'List' and names the resource 'consolidated exceptions,' making the operation's intent clear. It is naturally distinct from sibling mutation tools like record_exception and resolve_exception, though it does not explicitly contrast any close read alternative.

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 choose this tool over alternatives such as get_due_reviews or resolve_exception. The phrase 'optionally since an ISO datetime' hints at time-filtered usage, but no exclusions, prerequisites, or alternative routing are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Report' implies a read-only operation, but the description does not explicitly confirm that there are no side effects, nor does it explain what 'safety boundaries' means or what kind of response the agent can expect.

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

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

The description is a single sentence with no filler and the key concepts are front-loaded. It is concise, though perhaps too terse to fully resolve ambiguity around 'monitor state'.

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 annotations and no output schema, the description needs to explain what the tool returns and what the terms mean. It merely names two output concepts without defining them, leaving an agent uncertain about the response shape and the precise meaning of 'safety boundaries'.

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

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

The tool has zero parameters, so the schema already fully documents the input surface. The description correctly focuses on the output domain instead of inventing parameter details. A baseline of 4 is appropriate for a no-parameter tool.

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

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

The description uses a clear verb ('Report') and names two distinct output topics: monitor state and safety boundaries. It is not a tautology, and the tool name reinforces the intent, though 'monitor state' is slightly ambiguous as to whether it refers to monitoring-system status or monitored server state.

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 about when to call this tool versus any alternative. No sibling tools are mentioned, and there is no context about prerequisite conditions or typical use cases, so an agent must infer usage from the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal idempotency and the CSV source, but it does not explain what side effects 'seed' has on existing data, whether data is replaced or merged, what happens on revision mismatch, or whether the workspace CSV must already exist.

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

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

The description is a single sentence with no filler, and it front-loads the most important trait (idempotency). However, it is so terse that it omits critical operational details, so conciseness comes at the expense of usefulness.

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

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

Given the absence of annotations, output schema, and parameter descriptions, the tool description should compensate with richer context. It does not explain the meaning of 'expected_revision', the behavior on existing data, or what 'seeding the MCP' concretely changes in the system, so the agent cannot reliably predict the tool's effects.

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 does not mention the 'expected_revision' parameter at all. The agent receives no explanation of what this integer means, why it matters, or how it relates to the idempotent seeding behavior, leaving the parameter effectively undocumented.

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 action ('seed') and a resource ('the MCP' from a 'normalized watchlist CSV'), and adds the key property 'idempotently'. It is clear this imports data from a workspace CSV, though it does not explicitly differentiate from sibling tools like list_watchlist or dedupe_watchlist_measures.

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 gives no guidance on when to use this tool versus the many sibling tools. There is no mention of prerequisites, whether this is for initial setup, or when it should be avoided in favor of alternatives such as record_measure_observation or dedupe_watchlist_measures.

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 behavior burden; 'List' implies a read-only operation, and the review-status filter is disclosed. However it does not state any default behavior when the parameter is omitted, ordering, or return format, so transparency is only partial.

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

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

A single front-loaded sentence with no filler; it delivers the operation, resource, and filter in five words.

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

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

For a one-optional-parameter list tool, the description covers the core operation, but with no output schema and no annotations, it leaves unspecified what the returned candidate objects look like and what happens when review_status is absent. It is minimally adequate, not complete.

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

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

The description tells the agent that candidates are listed 'by review status', directly indicating the role of the single parameter, but it does not explain the enum values or the effect of omitting the parameter. The schema's enum provides the values, so a baseline of 3 is warranted.

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 clear verb ('List') and resource ('candidates') and adds the review-status filter, so an agent knows what the tool returns. It does not explicitly distinguish discovery candidates from sibling list_watchlist or get_due_reviews, but the resource name and status enum provide enough specificity.

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

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

No guidance is given about when to choose this tool over siblings such as get_due_reviews or list_watchlist, nor any exclusions or conditions. The filtering by review_status is implied but not tied to a concrete use case.

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 of behavioral disclosure. It implies a read-only listing operation and states the default scope (all states and supported local jurisdictions). However, it does not disclose behavior such as how results are ordered, whether 'code' filters the list, or what errors or rate limits may apply, leaving some ambiguity.

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

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

The description is a single, front-loaded sentence with no filler or redundant phrasing. It is concise and easy to parse. It could earn a 5, but it omits any mention of the 'code' parameter, making it slightly under-specified for the tool's interface.

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

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

Given the tool has an undocumented optional parameter, no output schema, and no guidance about alternative list tools, the description is not complete enough for an agent to use it reliably. It states the core purpose but leaves out parameter semantics and usage context, which are necessary for correct invocation.

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

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

The only parameter, 'code', has a 0% schema description coverage, and the description does not mention it at all. Since the schema provides no meaning for this parameter and the description fails to compensate, an agent cannot determine what values are valid or what effect it has on the results.

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

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

The description uses a specific verb ('List') and identifies a distinct resource: 'official source routes for all states and supported local jurisdictions.' This clearly indicates what the tool returns. However, it does not explicitly contrast with sibling tools like list_discovery_candidates, so it only partially differentiates.

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 provides no guidance on when to use this tool versus alternatives, no exclusions, and no mentions of prerequisites such as whether a 'code' parameter is needed. The context signals show a sibling list tool (list_discovery_candidates), but the description does not help an agent decide between them.

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 of behavioral disclosure. 'List' implies a read-only operation, but the description does not disclose the default value of active_only, whether jurisdiction_code narrows results, pagination behavior, or what the response contains. The behavioral profile is largely left to the agent to assume.

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 six-word sentence that is front-loaded with the verb and contains zero filler. The brevity is appropriate for a simple two-parameter list tool, though the space saved could have been reinvested in parameter semantics.

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?

Key context is missing: the meaning of jurisdiction_code, the default behavior of active_only, and the expected return shape. Since there is no output schema and no annotations, the description should carry more of this burden itself, and it does not. The operation's simplicity prevents a score of 1, but an agent would still be guessing at essential call details.

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 for both parameters. 'All or active' maps usefully to active_only, but jurisdiction_code is never mentioned — its role, format, and whether it filters or is required are unexplained. The description only partially covers the parameter surface.

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 ('List') with a specific resource ('monitored measures') and adds a scope qualifier ('all or active'). This distinguishes it from sibling tools like list_discovery_candidates and get_due_reviews, which target different resources. It falls short of 5 only because it does not explicitly contrast itself with those siblings.

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

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

The description implies the usage context: when an agent needs to view monitored watchlist measures, this is the tool. However, it provides no explicit when-to-use rules, no exclusions, and no pointers to alternatives such as list_discovery_candidates or get_due_reviews, leaving agent 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?

With no annotations provided, the description carries the burden of disclosing behavioral traits. It meaningfully discloses that the tool does not modify the watchlist and that the recorded item is deduplicated and queued for human review. However, it does not explain duplicate-handling behavior, whether it is idempotent, or what happens after a candidate is recorded.

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

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

The description is a single sentence that efficiently communicates the core action, purpose, deduplication behavior, and the important exclusion from the watchlist. Every clause earns its place with no redundancy.

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

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

Given the complexity of 15 parameters, 7 required fields, 0% schema description coverage, no output schema, and no annotations, this brief description is not sufficient for an agent to confidently construct a valid call. It orients the agent but leaves too many required fields and expected behaviors unexplained.

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 adds meaning for only one parameter implicitly ('official measure URL' maps to official_status_url) and does not clarify the remaining 14 parameters, many of which are required and lack property descriptions in the schema.

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

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

The description uses a specific verb ('record'), a specific resource ('a deduplicated candidate'), and states the purpose ('for human review'). It also explicitly distinguishes itself from watchlist-related tools by noting it does not add the candidate to the watchlist.

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 this tool is for capturing candidate items that need human review rather than directly entering the watchlist, which gives useful context. However, it does not explicitly state when to choose this tool over alternatives such as review_candidate, record_measure_observation, or import_normalized_watchlist.

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 must carry behavioral disclosure, and it does add one important behavior: recording an exception does not alter legal status. However, it does not disclose persistence, side effects, idempotency, permissions, or response behavior, leaving significant gaps.

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

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

The description is a single well-structured sentence with no filler. It front-loads the core behavior and adds the key scoping constraint about legal-status changes efficiently.

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 tool with no annotations, no output schema, and no parameter explanations, this description is too sparse. An agent would struggle to know what values belong in the optional fields or what the tool returns, despite understanding the overall intent.

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 for the 8 bare string parameters. It adds some meaning by implying what 'type' values may look like (retrieval, parsing, migration, verification), but it does not explain 'message', 'source_url', 'observed_at', 'retry_after', 'expected_revision', 'jurisdiction_code', or 'measure_id'.

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

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

The description uses a specific verb ('Record') with a clear resource ('exception') and enumerates the exception categories: retrieval, parsing, migration, or verification. It also distinguishes this from a legal-status change, which separates it from sibling tools like resolve_exception.

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 gives clear context for when to use the tool: for recording non-legal-status exceptions. It implies the tool should not be used for legal-status changes, though it does not explicitly name an alternative tool or provide a when-not-to-use 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 disclosure burden and does disclose three key behaviors: recording, computing field changes, and updating the watch snapshot, plus a non-publication side effect. It does not, however, explain side effects of expected_revision, error/rejection behavior, or the meaning of 'official-source observation' at the operation level.

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, front-loaded with the action and containing no filler. Every clause adds a distinct behavioral fact.

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?

This is a complex 7-parameter mutation with a nested 15-field object, no output schema, and no annotations; the two sentences do not equip an agent to form a correct invocation. Critical gaps include expected_revision's role, relationship to watch snapshot updates, and return or verification behavior.

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

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

Schema description coverage is 0%, so the description needed to compensate by explaining key parameters such as expected_revision, current, and retrieval_status, but it mentions none. Property names in the schema provide some guessable meaning, yet the 7-parameter tool's crucial semantics—especially the nested 'current' object and revision guard—are left undocumented.

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

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

The description uses specific verbs—record, compute, update—against identifiable resources: an official-source observation, material field changes, and the watch snapshot. The closing 'Does not publish' distinguishes it from publishing or ingestion flows and clarifies its scope relative to sibling record_* tools.

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

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

It provides no explicit when-to-use guidance or alternatives; an agent must infer from the name that it is for observations. The only exclusion, 'Does not publish,' is a behavioral note, not a selection criterion among siblings like record_discovery_candidate or review_candidate.

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

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

No annotations are provided, so the description carries the full burden of describing behavioral effects. It indicates a state change but does not disclose details such as whether expected_revision is used for concurrency, whether resolved_at is auto-set or user-supplied, whether the operation is idempotent, or what happens on failure.

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

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

The description is a single declarative sentence, front-loaded with the verb and object, and contains no filler or repetition. It is appropriately sized for the amount of information it conveys.

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 four parameters, no annotations, and no output schema, this description is too thin for an agent to invoke the tool reliably. It omits parameter-level semantics, behavioral side effects, confirmation/return behavior, and failure conditions, leaving important decisions to guesswork.

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 does not explain the parameters beyond the generic idea of an exception. The purpose of expected_revision is non-obvious, and resolved_at's behavior is unstated. The description provides minimal contextual help but does not compensate for the missing schema documentation.

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

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

The description uses a specific verb ('Mark... as resolved') and identifies the resource ('a previously recorded exception') plus the qualifying condition ('after a successful re-check or remediation'). This clearly distinguishes it from sibling tools like record_exception, which creates exceptions, and get_exceptions, which reads them.

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 states when the tool is appropriate: after a successful re-check or remediation. It implicitly places this tool after record_exception and gives concrete timing context, but it does not explicitly name alternatives or state when not to use it.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that acceptance requires a normalized watch entry even though watch_entry is not a required field in the schema, and it reveals that this tool is the exclusive route from candidate to watchlist. It does not cover behavior such as rejection effects, expectd_revision semantics, or idempotency, but what it states is material and non-obvious.

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 concise sentences with no filler. The core action is front-loaded and the key constraint follows immediately, making the description easy to parse quickly.

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?

The tool has six parameters including a complex nested watch_entry object, no annotations, and no output schema, yet the description omits important operational details such as expected_revision semantics, reject side effects, what the response contains, and how to construct a normalized watch entry. It gives a starting point but is not complete enough for an agent to call reliably in all cases.

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 for parameter meaning. It partially explains watch_entry by tying it to acceptance and implicitly clarifies decision via accept/reject wording. However, it does not explain candidate_id, reviewed_by, note, expected_revision, or the structure and purpose of the nested watch_entry fields.

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

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

The description uses a specific verb-resource pair: 'Explicitly accept or reject a candidate.' It also distinguishes this tool from siblings by stating it is 'the only candidate-to-watchlist path,' so an agent can tell it apart from record_discovery_candidate or list_discovery_candidates.

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 provides clear usage context: this is where a candidate decision is made. It also gives a key prerequisite: 'Acceptance requires a normalized watch entry.' It does not explicitly enumerate when not to use it, but 'only candidate-to-watchlist path' strongly implies the appropriate selection among sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It nicely sets expectation that output is unverified leads, but it does not mention side effects, network/failure behavior, or output structure. Transparency is partial.

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

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

Two short sentences with the action and output front-loaded, plus a high-value caveat. Every sentence earns its place and 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?

For a tool with no output schema and no annotations, the description gives a minimal but usable mental model: provide a URL and get matches/links as leads. It omits output shape, timeout semantics, and possible side effects, leaving some uncertainty for correct invocation and result interpretation.

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 conveys that `url` is the official-source target and hints that `terms` is used for keyword matching, but it does not define optionality/format of `terms` or the meaning of `timeout_ms`.

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

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

The description identifies a specific task: take one explicit public-official-source URL and return keyword matches plus candidate links. It implies a narrower scope than discovery or search siblings, though it does not explicitly name an alternative tool.

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

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

The line 'Results are leads, not verification' sets a clear boundary for how the output should be used. However, the description does not explicitly say when to prefer this tool over sibling search or discovery tools, nor does it describe optional-parameter usage.

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 provided, the description carries the full burden for behavioral disclosure. It does add a useful behavioral caveat: results must still be verified against the official matter page or enacted local law before acceptance. However, it does not mention authentication, rate limits, pagination, or output shape, which limits transparency for a search tool hitting an external API.

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 concise, with two short sentences; the core purpose is front-loaded and the verification caviat is placed second. Every sentence earns its place, though the brevity leaves out important parameter and usage details.

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 10 optional parameters, no output schema, and no annotations, the description is under-specified. It explains the high-level purpose and reliability caveat but omits essential invocation details such as query syntax, filter semantics, return value shape, and error behavior. An agent would struggle to use all available parameters correctly.

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

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

The input schema has 10 parameters with 0% description coverage, and the tool description provides no explanation of any parameter. It does not clarify what 'q' expects, how filters like status, matter_type, passed_since, or introduced_since behave, what formats are accepted, or how limit/top/timeout_ms interact. The description adds essentially no meaning beyond the bare parameter 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 description states the specific action 'Search' the 'official NYC Legistar matters API' and ties it to 'discovery leads', which clearly identifies what the tool does. It does not explicitly name sibling tools like search_openstates_bills, but the NYC/Legistar scoping makes the resource distinct enough.

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

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

The phrase 'for discovery leads' gives clear context about when this tool is appropriate, and the second sentence warns that results are not final and must be verified before watchlist acceptance. It does not explicitly describe exclusions or alternatives, but the use case is reasonably 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?

With no annotations, the description carries the behavioral disclosure burden. It meaningfully discloses that results are unverified leads and must be checked against official sources before acceptance. It also identifies the external data source, though it doesn't cover output format, pagination behavior, 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?

The description is two sentences with no filler. It front-loads the main action and follows with the critical caveat, making efficient use of limited space.

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

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

This is a 15-parameter tool with no required parameters, no output schema, and no parameter descriptions. The current description only establishes the source and the discovery caveat; it is insufficient for an agent to confidently construct valid queries or interpret results.

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 no parameter-level guidance. Some parameters like sort and include are partially self-explanatory through enums, but many others such as classification, action_since, jurisdiction, and identifier lack format or value guidance, leaving the agent to guess.

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 ('Search Open States v3') and a clear intended purpose ('for discovery leads'). This distinguishes it from sibling tools like scan_official_source and search_nyc_legistar_matters, which target different sources or verification workflows.

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 explicitly frames when this tool is appropriate: it is for discovery only, not final verification, and results must be pivoted back to official sources before watchlist acceptance. This gives clear context and an implicit exclusion, though it does not name an alternative sibling tool explicitly.

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

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

The description discloses the core mechanism—replaying the log and comparing it—which implies a read-only integrity check. However, with no annotations provided, it leaves unstated what happens on mismatch, what the return value is, and whether any state 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?

A single clear sentence, front-loaded with the action verb and containing no filler. Every word contributes to understanding the operation.

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?

The tool is low-complexity with no parameters and no output schema, so the description is usable. Still, without annotations or output schema, an agent is left guessing about the result format and whether this verification has side effects or should be run under specific conditions.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add. The baseline of 4 applies because parameter semantics are fully trivially satisfied.

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 ('Replay'), the exact resource ('append-only event log'), and the comparison target ('stored snapshot'). None of the sibling tools overlap with this operation, so an agent can clearly distinguish it.

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

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

There is no guidance on when to run this tool, what prerequisites might exist, or what alternatives should be considered. An agent would have to infer from the name that this is an integrity-check operation.

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