Trademark Screen

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

With no annotations supplied, the description carries the full burden and does so: it declares the tool read-only, offline, deterministic ('same name always gives the same result'), and warns that there is 'no live data and no register results.' It also discloses the shape of the response, which matters for a tool with no output schema.

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

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

The key constraint is front-loaded and every sentence contributes routing or output information. It is slightly redundant, since 'no live data and no register results' restates the opening 'WITHOUT checking the register', but the density is justified for a tool whose behavior differs sharply from its siblings.

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 two-parameter, non-destructive analysis tool with no output schema, the description covers scope, determinism, data freshness, return contents, the optional parameter's effect, and sibling routing. Nothing an agent needs in order 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 100%, so the baseline would be 3, but the description adds genuine meaning beyond the schema: it explains the mechanism by which goodsDescription matters — 'a descriptive word for those goods scores weaker than the same word for unrelated goods' — and frames omitting it as a valid name-only read.

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 opens with a specific verb and resource ('Analyze a brand name's strength') and immediately bounds the scope ('WITHOUT checking the register — read-only, offline, deterministic'). It also names the exact output artifacts (distinctiveness spectrum, phonetic collisions, checklist), so an agent can distinguish it from screen_trademark without opening either schema.

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

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

Explicit routing is provided in both directions: 'pair it with screen_trademark, which checks the actual federal register', 'Use this to judge how protectable a name is; use screen_trademark to judge whether it conflicts.' The when-to-use and when-not-to-use conditions are stated outright rather than implied.

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 were supplied, so the description carries the full burden and does so well: it declares read-only status, the per-TLD result values (registered/available/unknown), parallel checking, and even the underlying RDAP semantics (404 means not registered, 'unknown' means no RDAP service). It does not mention rate limits, latency, or failure modes for network errors, which keeps it from a 5.

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

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

Front-loaded with the core purpose, then result shape, then mechanism, then scope caveat and sibling routing — a sensible order. It is dense but not padded; the only mild redundancy is repeating the default TLD list that the schema already provides.

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 compensates by explaining the return format (one JSON result per TLD with three possible values) and the domain-vs-trademark boundary. An agent has everything needed to call it correctly and interpret the response.

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

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

Schema coverage is 100% and both parameters are already documented with examples and the default TLD list, so the description adds little beyond restating the default set and the custom-list option. Baseline 3 is appropriate where the schema does the heavy lifting.

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

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

States a specific verb and resource ('Check whether a brand name is free to register as a domain') and immediately differentiates itself from the sibling screen_trademark by scoping itself to domains, not trademarks.

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?

Explicitly names the alternative tool and the condition that selects it: 'use screen_trademark for the trademark check'. It also warns what this tool does not establish (a free domain does not mean the trademark is clear), which prevents the most likely misuse.

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 supplied, so the description carries the full burden, and it does substantial work: declares read-only semantics, describes the return shape (EU/UK hits scored like screen_trademark, plus classes used), and discloses the degraded path ({ checked: false, reason } with a manual link) with the underlying cause (TMview has no published API and resets connections from plain HTTP clients). It does not mention latency or retry behavior, which is the main remaining gap for a best-effort network-dependent tool.

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

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

Front-loads what is checked and where, then return shape, then the ordering rule, then the failure mode and the legal caveat. Each sentence carries a distinct load and none is filler, including the compact "Read-only." fragment.

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

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

With no output schema and no annotations, the description covers the gaps that matter: return contents, degraded-response shape, cause of failure, and the caveat that a clear result is a signal, not clearance. Nothing an agent needs to call it, interpret it, or recover from failure 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 name, classes, and goodsDescription including the inference behavior. The description adds only tangential meaning via "the classes used" and "class-relatedness scoring," without new format or syntax guidance beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (check) and resource (a brand name against EU + UK trademark registers via TMview), and names the exact jurisdictions covered (offices EM + GB). It also implicitly distinguishes itself from the US-focused screen_trademark sibling, so an agent can route correctly without opening the schema.

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

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

Gives an explicit ordering rule ("Use AFTER screen_trademark when you also sell in the EU/UK") and names the condition that selects this tool. It also states the US screen is unaffected if TMview is down, clarifying that partial failure here does not invalidate prior work.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the call actually queries the register, that results are limited to filings since watch start / last check, that they are risk-scored, and the scheduled cadence. It omits auth/rate-limit or cost details and does not state what happens on a watch with no prior check, which keeps it just short of a 5.

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

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

Front-loaded with the action and scope, then rationale and cadence; every sentence adds information. The em-dash-heavy, multi-clause opening sentence is slightly dense and could be split, but nothing is padding.

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

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

No output schema exists, so the description supplies the return shape ('JSON with only the filings that appeared since... scored by risk') and a scope disclaimer ('SCREEN ONLY — not clearance, not legal advice'), which is the right amount for a single-parameter trigger tool.

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

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

Schema description coverage is 100%, so the id parameter and its 'omit to check all' semantics are already documented. The description restates the same all-or-one behavior without adding format or edge-case detail, 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?

States a specific verb and resource ('Run a check for NEW filings RIGHT NOW') with scope ('all your watches, or one by id') and explicitly distinguishes itself from list_watches ('which only shows what you have'). An agent can tell it apart from sibling tools without opening any 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 explicit when-to-use ('when you want fresh results immediately') and names the alternative behavior to expect from list_watches, plus the relationship to the scheduled daily checker. Both the trigger and the exclusion are 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?

With no annotations supplied, the description carries the full behavioral burden and does so: it declares read-only, deterministic behavior ("the same two names always give the same scores"), enumerates the returned JSON fields including the 0-1 scale of the confusion score, and states the analytical limits. These are exactly the traits a caller needs for a scoring tool with no structured 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?

Four sentences, each load-bearing: purpose, behavior/return shape, when-to-use routing, and exclusions. The key facts are front-loaded and there is no redundant restatement of the tool name.

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?

Although there is no output schema, the description lists the return fields and their scale, so an agent knows what comes back. For a two-parameter, read-only comparison tool, nothing needed to select or invoke 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%, with both parameters documented and exemplified (NOVABREW vs NOVABRU), so the baseline is 3. The description adds only that the two inputs are "names"; it does not clarify edge cases such as casing, whitespace, or length differences beyond what the schema examples imply.

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

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

Opens with a specific verb and resource: "Compare two specific names side-by-side," and immediately names what is returned (visual, Jaro-Winkler, phonetic, confusion score, risk level). It explicitly differentiates itself from screen_trademark, so an agent can distinguish it from the sibling without inspecting schemas.

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

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

States the selection condition directly: use this when you already have two names in mind, and use screen_trademark to discover conflicts across the register. It adds the reason for that routing (screen_trademark weighs classes and live/dead status) and closes with exclusions — no meaning, commercial impression, or class relatedness.

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 supplied, the description carries the full burden and does so: it declares read-only behavior, states it does not trigger checks, enumerates the returned fields, specifies the auth paths (email + 6-digit code or session token), and discloses the privacy guarantee that no email addresses are returned.

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

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

Front-loads the core distinction (list vs. check) in the first clause, then layers return contents, alternative tool, auth, and privacy in a tight sequence with no filler sentences.

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, yet the description enumerates the returned JSON fields (mark, classes, threshold, schedule, dates, alert count, recent hits) and covers authentication, so an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it explains that code and sessionToken are alternative authentication routes ('or a session token from a previous verification') and ties the code to request_watch_code.

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 ('List the watches you ALREADY have') and immediately scopes it as a read-only view that does NOT check for new filings, which cleanly separates it from the sibling check_watches.

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?

Explicitly routes the agent: 'Use this to see what you are watching; use check_watches to actually run a check for new filings right now.' Both the when and the when-not are named with the alternative tool.

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

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

With no annotations, the description carries the full behavioral burden and does so: it discloses the only side effect (sends an email), that nothing is created, the code lifetime (10 minutes), the attempt limit (5 tries), the resulting 60-minute reusable session token, and the privacy property that a code is sent regardless of whether the address has watches. This is exactly the behavior an agent cannot infer from a one-parameter schema.

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

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

Four sentences, front-loaded with purpose before prerequisites, then expiry/attempt limits, then the privacy rationale. Every sentence conveys a fact an agent needs; there is no filler or restatement of the name.

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

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

No output schema exists, so the description must explain outcomes, and it does: the downstream 60-minute session token and the deliberate non-disclosure of watch existence. For a one-parameter, annotation-free tool this leaves nothing an agent needs missing.

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

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

The single parameter has 100% schema description coverage ('Email address to send the code to'), so the schema already handles the basics and the baseline applies. The description adds only marginal parameter meaning, notably that an email with no watches still receives a code, which is behavioral context rather than syntax.

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 ('Send a 6-digit verification code to an email address') plus the scope ('for watch access'), which immediately separates it from the sibling watch tools and from domain/mark screening tools. An agent knows exactly what this does without opening the schema.

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

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

Gives explicit ordering ('Call it BEFORE list_watches, unwatch_mark, or attaching an email to a watch with watch_mark') and names the exact siblings it precedes. This is a clear when-to-use rule with the alternatives identified, not implied 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, the description carries the full burden and does so: read-only semantics, a 100 screens/day rate limit, the shape of the result (risk verdict tiers, ranked conflicts with similarity/class/live-dead/owner/serial, data-as-of date), and a CSV variant. It also discloses the liability boundary, which is behaviorally relevant for a legal-adjacent tool.

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

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

Front-loaded with purpose, then read-only and rate limit, then return payload, then the sibling handoffs — a sensible ordering with little wasted wording. It is dense, packing a long parenthetical inventory of returned fields, but every sentence carries usable 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?

For a 5-parameter, two-required-parameter tool with no output schema and no annotations, the description supplies everything an agent needs: scope, safety profile, quota, return contract, and next steps. No material gap remains.

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 every parameter is already documented and the baseline is 3. The description only restates the format='csv' behavior (one row per hit, spreadsheet-friendly) without adding syntax, defaults, or guidance on when to specify classes versus letting them be inferred.

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 — screening a brand name against the USPTO federal register — and frames it as the US-jurisdiction step distinct from check_global_marks (EU/UK) and check_domains. An agent can distinguish it from every sibling 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?

Explicitly says 'Use this FIRST for any name' and then chains the alternatives in order: check_global_marks for EU/UK, check_domains for the domain, watch_mark to monitor. It also states exclusions ('SCREEN ONLY — not a clearance opinion, not legal advice'), so both when-to-use and when-not-to-use are covered.

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 exist, so the description carries the full burden, and it does disclose key behavior: read-only, pure reasoning, no live data, no register lookup, and even a cost motivator ($350 per class). It also describes the return payload without an output schema. What keeps it from a 5 is the absence of any statement about confidence, failure modes, or what happens with an ambiguous/empty description.

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?

Purpose is front-loaded in the first clause, then constraints, then usage routing, then the verification caveat — a sensible order with no wasted sentences. There is minor redundancy, since the specificity guidance on goodsDescription is repeated from the schema, but nothing is bloat.

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 single-param, annotation-free, output-schema-less tool, the description covers everything an agent needs: input meaning, reasoning-only nature, return structure (classes with labels, assumed classes, reasons), recommended downstream tools, and a verification caveat.

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 the sole param's schema description already includes the 'music streaming app' example and the specificity hint. The description mostly restates that ('goodsDescription is what you sell... the more specific it is, the better'), adding little 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?

The description opens with a specific verb and resource: 'Suggest the Nice classes (1-45) a goods/services description falls under, with reasons.' The parenthetical range and the 'with reasons' qualifier pin down scope, and no sibling tool (screen_trademark, check_global_marks, analyze_name) does class suggestion, so it is trivially distinguishable.

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 when-to-use cases ('before filing to pick classes... or to feed classes into screen_trademark / check_global_marks') and an explicit when-not ('no live data, no register lookup'), plus a follow-up action ('Always verify against the USPTO ID Manual'). The decision context is fully spelled out rather than inferred.

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 supplies the safety profile itself (read-only) plus a non-obvious data-source caveat: TSDR when a free key is set, otherwise the public Trademark Search record, which implies possible differences in freshness or coverage. It also enumerates the returned fields. It stops short of stating behavior on a missing/invalid number or how latency/rate limits differ between the two backends.

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

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

One dense paragraph that front-loads the purpose and identifier format before the routing rule. Some waste in repeating the sn/rn examples already in the schema, but nothing extraneous beyond that.

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 single-parameter lookup with no output schema, the description covers identity, scope, data source, and return contents, which is nearly everything needed. Only not-found/error handling 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 coverage is 100% and the id parameter's description already covers sn/rn prefixes and the bare-number fallback, so the description's format examples largely restate structured data. Baseline 3 applies — no additional syntax, validation, or normalization behavior is added.

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 — authoritative status lookup for a single mark — and pins the identifier space (serial or registration number). It explicitly distinguishes itself from name-based searching, so an agent can route correctly without opening either schema.

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

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

Names the precondition (you already have an sn/rn, e.g. from a screen_trademark hit) and the exclusion (not for searching by name — use screen_trademark). Both when-to-use and the alternative are stated outright.

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

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

With no annotations, the description carries the full burden and does so: it discloses that removal is a destructive side effect, that the watch will no longer be checked, the exact JSON return shape ({ removed, ok: true }), and the conditional authentication requirement. This is exactly the context annotations would otherwise need to supply.

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 sentences, front-loaded with the action and its destructive effect, then the return value, then the auth rule. No filler; the parenthetical clarifying the deletion side effect is the only emphasis and it earns its place.

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

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

Although there is no annotation coverage and no output schema, the description still explains the destructive effect, the return payload, and the conditional verification flow for all four parameters. 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 baseline is 3, but the description adds conditional meaning the schema does not convey: email and code vs. sessionToken are alternative verification paths that only apply when the watch has an email. The id parameter's dual role (watch id or mark name) is left to the schema.

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

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

The description opens with a specific verb and resource ('Stop watching a mark') and immediately clarifies that this deletes the watch. That is enough to separate it from the sibling watch_mark (which creates a watch) without opening either schema.

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

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

It states the prerequisite condition explicitly: an email-bearing watch requires proof of ownership via email plus a 6-digit code from request_watch_code, or a session token, while a watch with no email needs no verification. It does not name watch_mark or list_watches as alternatives for agents that may have called 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?

With no annotations, the description carries the full burden and does: it discloses the write side effect (watch is stored and a confirmation email with stop link is sent), the baseline screen that marks existing register entries as seen, the server dependency RESEND_API_KEY, and the email-verification gate that prevents attaching someone else's inbox. It also states the return payload (watch id, classes/threshold/schedule, baseline hits).

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 core action and the NEW-filings constraint, then prerequisites, then return shape. The parenthetical "(a side effect — it stores the watch...)" slightly repeats the mutation point already made by "CREATES", and the email section is dense, but almost every sentence carries operational value.

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

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

For a 9-parameter mutation tool with no annotations and no output schema, the description covers everything an agent needs: auth prerequisite chain (request_watch_code → code/sessionToken), degraded-mode behavior without RESEND_API_KEY, alert cadence, and the shape of the returned JSON.

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 baseline is 3, but the description adds meaning the schema does not: email is the watch's owner and digest destination, and code vs sessionToken are two interchangeable verification paths tied to request_watch_code. Schedule and threshold semantics are mostly restated from the schema rather than extended, keeping it below a 5.

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?

"Start watching a mark for NEW confusingly similar filings" gives a specific verb (start watching) and resource (a mark, producing a watch). The emphasis on NEW and the baseline-screen explanation distinguishes it from check_watches and list_watches, so an agent can route to it without comparing schemas.

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

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

It names alternatives and the conditions selecting them: use check_watches for new filings, let the scheduled checker run daily/weekly/custom, and call request_watch_code first for verification. Exclusions are explicit — without verification the watch is refused, and it is screen-only, not clearance or legal advice.

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