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

No annotations exist, so the description carries the full burden. It clearly discloses the side effect of recording authorization, the non-actions of never submitting and never transmitting résumés, and the success response containing apply_channel and resume_transmitted=false. It stops short of documenting error behavior or idempotency, but the core behavioral profile is transparent.

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

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

The description is front-loaded with the core action and restriction, and the Args section is cleanly organized. The résumé prohibition is repeated several times for safety emphasis, which is slightly redundant but defensible for a privacy-sensitive 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?

Without an output schema, the description defines the return values and the intended follow-up: the user submits via the employer's apply_channel. It lacks error semantics for authorized=false and duplicate applications, but otherwise it is complete for a small three-parameter tool.

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

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

Schema description coverage is 0%, and the description compensates by explaining all three parameters: job_id provenance via search_jobs/check_watches, fingerprint as anonymous, and authorized as 'must be true' per-job consent. This adds both semantic meaning and validation guidance that the bare schema lacks.

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

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

The description opens with a specific verb and resource: 'Record an authorized, employer-direct application' and a hard exclusion 'REFUSES résumés.' It further clarifies the rename from apply, explicitly stating it records authorization and 'never submits anything on their behalf,' making it easy to distinguish from any submission-like sibling.

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 when to use it: on a job returned by search_jobs/check_watches, after receiving explicit per-job consent with authorized set to true. It also gives when-not behavior by refusing résumés and warning not to paste résumé content, and it directs the user to the apply_channel as the correct alternative path for actual submission.

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 burden. It discloses that the call returns new matches per watch and, importantly, advances each watch's last-notified marker, which is a side effect. It does not cover error cases or auth, but the core behavior is transparent.

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

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

Three compact sentences with front-loaded purpose, a clear rationale, and the behavioral result. Every sentence earns its place with no redundant 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 simple one-parameter tool with no output schema, the description covers when to call, what it returns, and what side effect it has. The only noticeable omission is a fuller explanation of the fingerprint value, which is a parameter-level gap rather than a tool-level one.

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 schema provides only a bare 'fingerprint' string with 0% description coverage. The description adds that the fingerprint is tied to tracking the last check, which gives it semantic meaning, but it never explains what a fingerprint is or how it is obtained, leaving a gap.

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

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

States a specific verb and resource: pull matches that are new since this fingerprint's last check. This clearly distinguishes it from siblings like search_jobs and watch_intent by focusing on polling watch results rather than searching, reading company info, or authorizing.

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

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

Provides explicit usage context: because stdio has no server push, the client should call this at the start of a session. It does not name alternative tools, but the context strongly implies this is the polling complement to watch_intent.

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 this well by stating a key guarantee—'NEVER returns any individual candidate data'—and explaining why ('the server holds none'). It also clarifies the meaning of index_built_at. The read-only nature is implied through 'Returns,' though it doesn't mention potential errors or authentication needs, which are secondary for this simple info 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 two sentences with no wasted words. The primary purpose is front-loaded, return fields are listed concisely, and the critical negative constraint (no individual candidate data) is stated crisply. Every sentence 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?

For a tool with one simple parameter, no output schema, and no annotations, the description is largely complete. It names all return fields, explains the meaning of one potentially ambiguous field (index_built_at), and discloses the privacy limitation. It could go further by mentioning error behavior or how company_id is validated, but given the low complexity, the current information is adequate 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 input schema provides zero description coverage for company_id, so the description must compensate. It only weakly ties the parameter to 'one employer,' but does not explain what a company_id is, where to obtain it, or expected format. This leaves the agent with only the tool name and the generic 'Company Id' title to infer the parameter's meaning, which is insufficient given 0% schema coverage.

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 'Aggregate, anonymous trust signals for one employer,' a specific verb+resource statement that immediately identifies the tool's function. It also enumerates the return fields (ghost_score_avg, active_jobs, index_built_at), and the scope ('for one employer') clearly distinguishes it from sibling tools like search_jobs, watch_intent, and authorize_application, which operate on different resources.

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

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

Usage is implied rather than explicit: the description says 'for one employer,' suggesting this is the tool to call when you need trust/aggregate signals for a specific company. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or conditional guidance for selecting among siblings.

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, and it delivers: it discloses that only hard filtering is done, ranking is fixed as match-quality × freshness, roles without stated pay are kept by default, require_stated_salary changes that behavior, and role_family is currently a no-op. It also lists exactly which fields every result contains.

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 front-loaded with the core purpose, followed by an important behavioral caveat, then a clean parameter list. Every sentence conveys necessary information without fluff or repetition.

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 tool with no annotations and zero schema description coverage, this description is fully self-sufficient. It covers semantics, edge cases, output fields, and the server's ranking behavior, so an agent can invoke it correctly and interpret results confidently.

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 fully document all 9 parameters, and it does. It explains union vs. AND matching for skills, remote_scope enum values, the salary floor interaction with require_stated_salary, currency implying stated pay, role_family no-op status, and limit default.

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: 'Search the live job index by hard filters; returns ranked JobPosting[]'. It clearly distinguishes this as a filtering/search tool and is not confusable with the unrelated sibling tools (get_company_info, watch_intent, etc.).

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 clearly explains that the server performs only hard filtering plus a fixed ranking, and that precise re-ranking is left to the client holding user context. This gives the agent a clear sense of when this tool is appropriate. However, it does not name an alternative search-like sibling or state explicit exclusion conditions.

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 it does well: it discloses that only the anonymous fingerprint and non-PII filter keys are stored, that the server cannot recover the fingerprint, and that the client must persist it. It also reports the return fields. It does not discuss duplicate registration behavior or idempotency, but the privacy and persistence semantics are unusually transparent.

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

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

The description is thorough but not bloated. The purpose is front-loaded, and each subsequent section — fingerprint ownership, data-retention guarantees, filter-key catalog, return payload — earns its place. The structure makes the content easy to scan and act on.

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 annotations, no output schema, and a completely open filters object, the description is remarkably complete. It covers the call's side effects, the client's responsibility, filter semantics, privacy behavior, and the returned fields. An agent has enough to call this correctly and to coordinate with check_watches.

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

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

Schema coverage is 0%, so the description must compensate entirely, and it does. It explains the fingerprint's ownership, persistence requirement, and relationship to check_watches, then details the accepted filter keys (skills, required_skills, remote, role_family, min_salary) with matching semantics and an example. This goes well beyond the bare schema's 'additionalProperties: true'.

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 clear verb and resource: 'Register a standing intent so new matches can be pulled later.' It establishes a distinct purpose that separates this from one-time search tools like search_jobs and from the later retrieval tool check_watches, even before reading any sibling 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?

The description clearly explains when to use this tool: to establish a persistent intent whose results are retrieved later. It names check_watches as the companion tool that must receive the identical fingerprint, and references search_jobs for filter-key semantics. It stops short of explicitly stating 'do not use this for one-time searches,' but the context is clear enough.

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