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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, but the description adds a fact they don't carry — "it spends no credits" — which matters for an agent deciding whether to call repeatedly. It also discloses the two distinct result modes (summary list vs. full posting), though it says nothing about pagination totals 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 purpose is front-loaded and the ordering (what it returns → how to shape the call → safety → exclusion → next step) is logical. It is dense, packing six parameters into one long semicolon-chained sentence, which costs some scannability, but no sentence is redundant.

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, dual-mode read tool, the description covers scope, filtering, polling, cost, exclusions and hand-offs. Since an output schema exists, the brief field list is sufficient rather than a gap, and nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns more by explaining intent behind parameters: the cursor pattern ("after_job_match_id with the newestJobMatchId you stored to see only matches newer than your last check") and the 10-id cap on job_match_ids. Only page, limit and saved_only go unmentioned, and those are self-evident from 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 concrete verb+resource ("List the user's matched jobs") and immediately disambiguates the source of the data ("roles GetMattered found for them against their saved job preferences"), which separates it from getmattered_search_jobs. It also names the returned fields, so an agent knows the shape of a result without opening the output schema.

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

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

It gives explicit routing for each mode: job_match_ids for full detail, job_url for an unsaved posting, and filter params to narrow. It adds a clear exclusion ("Do not use it to change what the user is matched against; use getmattered_update_job_preferences") and hands off to getmattered_apply and getmattered_triage_matches for next steps.

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