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

Goes well beyond the annotations by disclosing the cost model ('no launch is spent', 'free allowance') and two concrete error outcomes, which is exactly the kind of consequence info an agent needs before mutating. It stops short of describing the success result or whether the change can be undone, leaving a small gap given there is 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?

Three sentences, front-loaded with the operation and its cost implication, then the required prerequisite, then the error semantics. No sentence restates the name or the schema.

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

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

For a 4-parameter mutation with full schema coverage and non-destructive annotations, the description supplies the prerequisite flow, cost behavior and error paths, which is nearly everything an agent needs. The only omission is what a successful call returns or changes, which matters slightly more here because there is no output schema.

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 baseline is 3; the description adds meaning by tying the include path to the free-allowance limit and to the allowance_exhausted error, and by anchoring confirm_selected to preview_launch's reported count. The exclude / excluded_directories distinction is left entirely 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?

States a specific verb and resource ('submits a launched project to more directories') plus the crucial scope qualifier 'from its free allowance (no launch is spent)', which separates it from launch_project and preview_launch. An agent can tell exactly which operation this is 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 prescribes the workflow: 'Call preview_launch with the same arguments first and get the user to agree', naming the sibling to use as a prerequisite and the human-confirmation gate. It also names the failure conditions (allowance_exhausted, invalid_directories) that tell the agent when to stop and re-plan.

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

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

Annotations already declare non-idempotent, non-destructive, open-world writing, but the description adds the meaningful quota constraint ('5 at most') and warns that repeated calls accumulate screenshots. That accumulation behavior is exactly the consequence an agent needs beyond the idempotentHint flag.

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

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

Two sentences, no filler, with the quota limit and the non-idempotency warning front-loaded. Every clause carries actionable information.

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

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

For a simple single-item add tool with full schema coverage and safety annotations, the description covers sources, quota, and repeat-call risk. It does not describe the return value, a minor gap given there is no output schema.

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 real semantics: url and file_path are alternative sources, and local file use requires the npx package. That packaging constraint is not conveyed by the schema alone.

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

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

Specific verb and resource ('Adds one screenshot to a project'), with scope limits (5 at most) and supported sources (public URL or local file via npx). Clearly distinguishable from siblings like set_logo and remove_image.

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

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

Gives a concrete usage rule: 'Each call adds another one, so do not repeat a call that succeeded' — a practical when-not-to-repeat instruction. It does not explicitly name alternative tools or state prerequisites (e.g., needing an existing project), but the context for calling it is clear.

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

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds two non-obvious behaviors: name, tagline and description are asynchronously backfilled from the site when omitted, and the call consumes no credits. It does not cover idempotency/duplicate handling or what state the new project starts in (draft vs. live), which matters given idempotentHint=false.

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

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

Two short sentences, both front-loaded with the highest-value facts (what it creates, what it costs). No repetition of schema or annotation content.

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 23-parameter creation tool with no output schema, the description gives a solid mental model: minimal input is a URL, everything else backfills or is optional, and no credits are spent. It omits what the call returns (e.g. the new project id needed for a subsequent launch_project), which is the one real 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?

Schema coverage is 87%, so the schema already carries most parameter meaning and the baseline would be 3. The description adds value by generalizing the auto-fill behavior beyond the schema's note on 'name' to also cover tagline and description, which the schema does not state for those 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?

States a specific verb and resource ('Creates a project') and scopes it to a client's product via its URL, so the sole required parameter is visible in the first clause. It also explicitly names the boundary against the sibling launch_project, letting an agent separate creation from launching 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?

The closing sentence gives a clear conditional rule — creating is free, credits are only consumed by launch_project — which effectively tells the agent when to pick this tool over that alternative. It stops short of naming other siblings (update_project, preview_launch) or stating preconditions/preferred ordering 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?

Annotations already declare non-read-only, non-idempotent, non-destructive, closed-world, so the mutation profile is known. The description adds genuinely new behavioral context: the build is asynchronous ('takes a moment') and results must be fetched via get_report. It does not say what create_report itself returns (job handle?) or what happens if a report already exists, which is why it is not 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?

Two short sentences with zero waste; the core action and formats are front-loaded, and the sequencing constraint follows immediately. Every clause carries 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?

No output schema exists, and the description implies the result is retrieved later via get_report rather than returned inline, which is the key thing an agent needs. The one remaining ambiguity is what create_report itself returns (a job/status object?), but the essential calling pattern is complete for a 2-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 coverage is 50%: project_id is documented in the schema, and the format enum has no schema description. The description compensates partially by spelling out 'PDF or XLSX', mapping directly to the enum values, but adds nothing about project_id or format defaults. Baseline 3 fits given the partial 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 (builds) and resource (PDF/XLSX report of a project) with the branding qualifier, and names the follow-up sibling get_report, so the agent can distinguish it from retrieval 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?

Explicitly prescribes the workflow: build first, then call get_report, which tells the agent this is not a synchronous 'get the report' call. It stops short of naming when to prefer create_report over alternatives like preview_launch or save_report_file, so no exclusions are given.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false; the description usefully adds that replace:true invalidates the previous link, which is real destructive context. However it never states that a call without replace may still create a link when none exists, nor how expires_at interacts with an existing link.

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 tight sentences, with the default behavior stated first and the mutation case second. Every clause carries information and nothing is padded.

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?

There is no output schema, and the description gives only a partial picture of the return value ('the current link') without saying what happens when no link exists and replace is false. For a three-parameter mutation tool it should cover the not-found path and expiry 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 100%, so the schema already documents all three parameters thoroughly, including the replace semantics. The description merely restates the replace behavior and says nothing about expires_at or the required project_id format, so it adds little beyond the structured data.

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

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

The description names the resource precisely (the project's client page link) and explains the get-or-create behavior plus the replace flag. It is clear what the call returns, but it never differentiates itself from the sibling get_share_link, and the verb 'Gives' sits awkwardly against the name/title 'create'.

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 only implied: the 'replace: true' clause hints at the regenerate case, but there is no explicit statement of when to call this instead of get_share_link or delete_share_link. An agent must infer the routing decision from the flag semantics 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?

The annotations already declare destructiveHint=true and idempotentHint=true, so the description is not the sole source of safety information. The description adds valuable context by defining exactly which projects are eligible for deletion and ruling out launched projects, though it does not explicitly say whether deletion is irreversible or what happens to associated resources.

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 then the critical restriction. There is no redundant or filler text.

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 delete operation with rich annotations, the description covers the essential precondition and exclusion. It could optionally mention irreversibility or post-deletion effects, but the annotations already signal destructiveness.

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

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

Schema description coverage is 100%, and the single project_id parameter is documented with its required pattern in the schema. The description does not add any parameter-level details beyond what is already structured, so the baseline of 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?

The description gives a specific verb and resource ("Deletes a project") and immediately narrows the scope to drafts that were never launched. This distinguishes it from the launch-related siblings and makes the tool's purpose unambiguous.

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 explicitly states the key eligibility condition: the project must never have been launched, and a launched project cannot be deleted. It does not name an alternative action for launched projects, but the exclusion criterion is clear enough for an agent to choose correctly.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real context beyond them — the effect is scoped to anyone holding the URL and they 'see nothing afterwards' — but it leaves reversibility ambiguous: 'turns off' suggests it can be re-enabled, while the tool is named delete_share_link and flagged destructive.

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, no filler, with the primary action front-loaded and the consequence immediately after.

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-parameter destructive toggle with rich annotations and no output schema, this is largely sufficient: the agent knows the target, the effect, and that it is destructive and idempotent. Only the reversibility question and any permission prerequisite remain open.

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% with a single required project_id that includes a format pattern, so the schema carries the parameter burden. The description adds nothing about project_id and does not clarify whether the project id is the owner of the link.

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: turning the project's client page link off. It is unambiguous what object is affected, but it never names the inverse sibling create_share_link or get_share_link, so sibling differentiation is only implicit through the shared 'share link' concept.

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 — you call it when you want the client page to stop being visible to link holders. There are no explicit exclusions, no prerequisites (ownership/permission requirements), and no mention that create_share_link is how you restore or rotate the link.

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

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

Annotations already mark it read-only and closed-world; the description adds useful behavior: results are ordered by Domain Rating and the catalog is capped at 20 before first launch purchases. It does not cover auth or rate limits, but with annotations carrying the safety profile this is solid added 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?

Two sentences, front-loaded with purpose and mode, then the visibility caveat. No wasted wording.

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 search tool with rich schema docs and read-only annotations, the description covers purpose, ordering, id read, and the top-20 business rule. It remains thin on pagination and return shape, but cursor and limit are in the schema and no output schema is present.

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 78%, so the schema documents most filters and modes, including directory_id and min_dr. The description reinforces ordering and id lookup but does not add syntax or meaning for q, kind, limit, topic, cursor, audience, or requires.

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

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

The description names a specific verb and resource ('Searches the directories') and adds ordering plus an id-read mode, making the catalog scope clear. It does not explicitly contrast with sibling directory tools such as project_directories or add_directories, so it stops short of full sibling differentiation.

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 implies two modes (query search or directory_id read) and notes the pre-purchase top-20 limit, but gives no explicit when-to-use guidance or alternatives. An agent must infer that this is for catalog discovery rather than project directory management.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that one of the outputs is a message intended for forwarding to the client, which is useful framing, but says nothing about failure modes, whether a badge is guaranteed, or response shape beyond the field list.

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 dense sentence with the resource identified first, outputs second, and the platform behavior last. No redundant restatement of the title or filler.

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

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

With no output schema, the description carries the return-value burden and does so by naming the three payload pieces. Slightly incomplete in that it does not say what 'status' values look like or what happens when no badge exists yet.

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 both parameters are already documented, including the platform field's meaning. The description reinforces the optionality of platform and its narrowing effect on the result, but adds no format or valid-value detail beyond what the schema states.

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

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

Names the concrete resource (the agency-branded badge some directories require) and enumerates what comes back: status, a client-facing message, and install code. An agent can tell it apart from verify_badge or find_directories without opening a schema, though neither sibling is named.

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?

"Call without platform to see the platforms" is a genuine operational instruction that tells the agent how to discover valid values before a targeted call. No explicit exclusions versus verify_badge or project_directories, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds value by enumerating the returned content (status, wait state, progress counts, allowance, readiness, texts, images, site image candidates), but gives no caveats about permissions, missing projects, or data shape.

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 single sentence is front-loaded with the core scope ('One project in full') and then lists returned fields. It is dense but efficient with no filler.

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

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

Given no output schema, the field enumeration is useful, but the list is somewhat vague ('what it waits for', 'texts', 'images') and omits behavior for unknown ids. It is minimally adequate for a simple get-by-id tool but leaves gaps.

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 project_id fully documented including its pattern, so the schema carries the parameter burden. The description adds no parameter-level detail, which is acceptable at this coverage level.

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 makes clear this returns a single project 'in full', which distinguishes it from list_projects without naming it explicitly. The verb 'get' is implicit ('One project in full'), but the resource and detail-retrieval scope are unambiguous.

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 explicit guidance on when to use this versus list_projects or update_project, and no prerequisites or error conditions are mentioned. The only hint is 'One project in full', leaving usage 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds nothing about what is actually returned (a status flag? a download URL? an expiry?), whether the file is streamed inline, or whether readiness is polled repeatedly, leaving the most operationally important behavior undisclosed.

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

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

It is short with no filler, but it is an unanchored fragment with no subject or verb and no front-loaded statement of what the tool does. Conciseness here comes at the cost of clarity rather than from efficiency.

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?

There is no output schema, so the description carries the burden of explaining return values, yet it only gestures at them ('whether a report is ready, and how to get the file'). For a polling-or-fetch tool whose entire utility is the shape of its response, this is materially incomplete.

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 a single parameter and 100% schema description coverage, the schema fully documents report_id including its pattern, so baseline 3 applies. The description contributes no additional meaning about the identifier or its format.

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 the resource (a report) and two concerns: whether it is ready and how to obtain the file, which adds meaning beyond the bare name. However, it is a noun-phrase fragment with no verb, so it never states an action an agent can map to a call, and it does not distinguish itself from siblings like save_report_file or create_report.

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 call this versus create_report, save_report_file, or get_share_link, all of which touch adjacent report/file concerns. The phrase 'how to get the file' hints at a post-readiness step but never states the condition or the alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about the returned artifact (a read-only, agency-branded client-facing progress page) and that view data accompanies it, though it omits whether view counts are totals or a breakdown.

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 short sentence with no filler. It is front-loaded with the resource, though the phrasing is clipped to the point of reading as a label rather than a statement of action.

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?

A simple one-parameter read tool with full annotation coverage, so not much is required. However, with no output schema, the description should clarify what "with its views" returns (a URL plus a count? a list of view records?); that ambiguity is left unresolved.

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

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

Only one parameter, project_id, and schema description coverage is 100% with a clear pattern constraint, so the schema carries the burden. The description never mentions the parameter, but nothing about its meaning is left ambiguous either.

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

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

The description names the resource ("the project's client page link") and hints at a payload ("with its views"), so an agent can infer this retrieves a share link. But it is a noun phrase with no verb, and it never distinguishes itself from create_share_link or delete_share_link, which is the key disambiguation for a CRUD-lite trio.

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 when-to-use, when-not-to-use, or prerequisite guidance. It does not say whether a link must already exist or what happens when none does, nor does it route an agent between this and the sibling create_share_link/delete_share_link 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?

Annotations already flag destructiveHint/readOnly=false/openWorld, but the description adds genuinely new behavior: it consumes a launch credit, sbm_test_ keys produce a test launch, and live keys trigger a confirmation question to the client's own user. That last point is non-obvious third-party side-effect disclosure. It still doesn't say whether a launch is reversible or what a failed launch does to the credit.

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

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

Three sentences, front-loaded with what the tool does, followed by the precondition and the live-key caveat. Dense but every clause carries information. The opening clause 'spends one launch of the agency' is slightly convoluted but still earns its place by conveying quota consumption.

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

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

For a destructive mutation with rich annotations, full schema coverage and no output schema, the description covers the essential unknowns: quota spend, test vs live key behavior, and the mandatory preview/confirm loop. Nothing an agent needs in order to invoke it safely 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 every parameter including confirm_selected, directories, auto_replace and excluded_directories is already documented in the schema. The description's 'confirm_selected is the count they agreed to' essentially restates the schema's own wording. Baseline 3 for a fully documented schema with no material added semantics.

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 action (start submissions / spend one launch credit on a project) and ties it to the concrete resource. The 'agency' and 'one launch' phrasing is domain jargon, but the pairing with preview_launch and sbm_test_ keys makes the intent recoverable. It clearly is not a read tool like get_project or preview_launch.

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 prerequisite workflow: call preview_launch with the same arguments, get user agreement, then pass that agreed count as confirm_selected. That routes the agent away from blind launching. It does not state explicit when-not-to-use conditions (e.g. insufficient credits, draft state), so it stops short of 5.

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

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

Annotations already mark the tool read-only and closed-world, and the description adds substantial behavior beyond that: 90-day retention, oldest-first scanning, up to 1,000 events per call, default since window, and cursor continuation semantics. These details materially affect how an agent interprets and calls the 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 front-loaded with the core purpose, then adds only operationally necessary details about retention, pagination, and alternatives. There is no filler, and each sentence contributes to correct invocation.

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 an output schema, the description supplies enough return-shape and pagination context: event scanning limits, ordering, cursor reuse, and default time window. It is complete for selecting and correctly invoking this tool.

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

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

Schema coverage is 100%, so all five parameters are already documented structurally. The description adds some useful context around cursor continuation and the default since window, but it does not explain the type filters, limit behavior, or project_id scoping beyond what the schema already provides.

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 clearly defines the tool as a change feed over projects and listings and explicitly says it returns events. It also distinguishes this from the current-state siblings get_project and list_listings, so an agent can tell when this tool applies.

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 usage guidance: use the feed for changes, and use get_project or list_listings instead for current state because they are cheaper. It also explains the cursor workflow for incremental reads, which directly affects how the tool should be called.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that: ordering by highest DR first, one row per directory, and the presence of status plus the live link once published, which tells the agent what state each listing carries.

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 zero filler, and the primary list behavior is front-loaded before the single-item alternative.

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

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

With no output schema, the description does carry return-shape burden and partially meets it by stating fields (status, live link), ordering (highest DR first), and granularity (one per directory). It omits pagination/cursor semantics and the effect of the status filter, which the schema covers but the prose does not.

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 83%, so the schema already documents limit, cursor, directory, listing_id, and project_id. The description only echoes listing_id ("by its id"), directory granularity, and status implicitly; it adds no new syntactic or behavioral detail on pagination or filtering. Baseline 3 applies.

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

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

The description names the resource (a project's listings) and its granularity (one per directory), plus the sort order and included fields, and notes a second mode (one listing in full by id). It's specific rather than tautological, but it's a noun phrase without a verb and doesn't explicitly distinguish itself from nearby siblings like project_directories or find_directories.

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?

"Or one listing in full by its id" implies a second usage mode, and the parameters imply filtering by status/directory, but nothing states when to pick this tool over project_directories or find_directories, nor when to use the single-listing mode versus the list mode. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the useful behavioral fact that results come newest first, but says nothing about paging behavior despite a cursor parameter, nor about what happens when no filters match.

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, the ordering trait front-loaded and the filtering guidance second. 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 read-only list tool with no output schema, the definition covers scope, ordering, and the two lookup paths. The only gap is the status enum and cursor paging, though the schema's own descriptions for limit and cursor partially carry that load.

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 only 60% (status and external_id have no schema descriptions), so the description must compensate. It does clarify external_id as 'your own external_id' — a caller-owned identifier rather than an agency-assigned ID — and maps q to name-or-URL matching. It leaves status unexplained, but adds real meaning over the schema for two of five parameters.

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 ('Lists the agency projects') plus the sort order ('newest first'), which is immediately distinguishable from get_project. It stops short of naming how it differs from sibling listing tools like list_events or list_listings, but the resource is unambiguous.

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 tells the agent how to find a specific project ('by name or URL with q, or by your own external_id'), which implies the lookup use case, but gives no explicit when-to-use-this-vs-get_project guidance and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with that by calling it a 'free dry run'. It goes beyond the annotations by disclosing that it is cost-free and by listing the full set of computed outputs an agent will get back.

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 dense sentence describing the tool plus one short directive sentence, front-loaded with the dry-run nature and cost. No filler; every clause carries information.

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

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

With no output schema, the description compensates by enumerating the return contents (counts, DR stats, missing items, unlock info, cost). Combined with the fully documented params and read-only annotations, 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 description coverage is 100%, so the parameters (including the auto/include/exclude union and auto_replace) are already fully documented in the schema. The description only says it takes 'the same arguments' as the launch tools, adding little beyond the structured data. 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 and resource ('free dry run of launch_project / add_directories') with the same arguments, and enumerates exactly what it reports (submission count, top/median DR, gaps, unlock potential, cost). This clearly distinguishes it from the real launch_project and add_directories 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?

Explicitly routes usage: names the two alternatives it mirrors and instructs 'Show the numbers to the user before launching', giving a clear sequencing context. It does not state any when-not-to-use condition, but the recommended flow is unambiguous.

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

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

Annotations already establish this as a read-only, closed-world operation, so the bar is lower. The description adds useful behavior: it lists the possible states, explains that suggested/open/locked are shown by default, and clarifies that counts cover all states.

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 tightly written sentences with no waste. The core scope is front-loaded, and the second sentence clarifies default behavior and counts.

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 read-only list tool with no output schema, the description adequately explains what is returned: catalog directories grouped by state, with default filtering and count coverage. Pagination is left to the schema, which is acceptable given its 100% coverage, but the description could have mentioned it briefly.

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

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

Schema coverage is 100%, so the schema already documents parameters, but the description adds meaning beyond the enum values by explaining that 'suggested' is the auto pick and 'locked' includes what unlocks it. It also restates the default state selection, which helps interpret the 'states' parameter.

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 clearly states the resource: every catalog directory as seen by one project, with the possible states enumerated. It is specific enough for an agent to understand the tool, but it does not explicitly distinguish itself from sibling tools like find_directories or add_directories.

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 by 'as seen by one project' and the default state filtering, but the description gives no explicit guidance on when to use this tool versus alternatives such as find_directories. An agent can infer the context but is not routed away from 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the description doesn't need to re-establish the safety profile. It adds genuine context beyond them by disclosing the invariant that keeps a launched project from losing its last logo/screenshot. It stops short of saying what the response or error looks like when that invariant blocks the call.

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: the action and its accepted values come first, then the constraint. No filler, no repetition of annotation data.

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 2-parameter, non-read-only tool with no output schema and fully documented parameters, the description covers purpose, accepted inputs, and the key invariant. The only real omission is failure behavior (error vs silent no-op) when the last-logo/screenshot rule is hit.

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

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

Schema description coverage is 100%, and the description's parameter content ("logo" or an img_ id) merely restates what the anyOf const and pattern already encode. Baseline 3 applies since the schema carries the parameter semantics.

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 (removes) and the exact resource set: the logo literal "logo" or one screenshot by img_ id. This clearly distinguishes it from the opposite-direction siblings set_logo and add_screenshot, though it never names those siblings explicitly.

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

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

The second sentence supplies the operative precondition: a launched project retains at least its logo and one screenshot, which tells the agent when this call will be refused. It gives no explicit alternative-routing guidance (e.g., use set_logo to replace rather than remove), keeping it below a 5.

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

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

Adds real behavior beyond annotations: it never overwrites existing files, the default destination is the Downloads folder, and it returns the path. This meaningfully softens the non-idempotentHint by telling the agent repeated calls will produce new files rather than clobber data.

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 short sentences with zero waste; the core action, the safety guarantee, and the return value are ordered front to back.

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 two-parameter tool with no output schema, the description covers action, destination, overwrite policy, and return value. It could note what happens if the report isn't ready or the directory is invalid, but nothing essential is missing 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?

Schema description coverage is 100%, so both parameters are already documented, including the Downloads default. The description only restates the directory default and adds no new meaning about the report_id format or path constraints.

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?

Uses a specific verb+resource pair ('Downloads a ready report and saves it to a local folder'), which clearly separates it from read-only siblings like get_report. It does not explicitly name the sibling it replaces, but the file-persistence framing makes the distinction inferable.

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 usage (you want the report as a local file rather than data returned inline), but never states when to choose this over get_report or get_share_link. No preconditions or exclusions are given.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, but the description adds real context: the URL is fetched immediately and a failed fetch surfaces as the image_unreachable error, plus the SUBMITATOR_FILES_DIR constraint on local paths. That timing and error behavior is not derivable from annotations or 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?

Two tight sentences, front-loaded with the action, then the failure mode, then the alternative input path. No filler and nothing repeated from the schema.

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

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

With no output schema, the description covers the meaningful failure signal and both input routes. It omits what happens to an existing logo beyond 'replaces' and any project-state prerequisite, but for a 3-param tool with full schema coverage and annotations this is close to 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?

Schema coverage is 100%, so baseline is 3, but the description goes beyond it by tying url and file_path to an either/or choice and by explaining what 'the starting folder' means in the file_path definition. Format and size limits remain schema-only, which is fine.

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

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

The description names a specific verb and resource ('Sets or replaces a project's logo') so the agent knows exactly what changes. It does not, however, distinguish itself from adjacent image tools like add_screenshot or remove_image, which a reader must infer.

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 clearly explains the two input modes — supply a URL, or with the npx package supply a local file — which is the main decision an agent faces here. It stops short of saying when to prefer this over add_screenshot or how it interacts with remove_image.

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

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

Annotations only declare readOnly=false, idempotent=true, destructive=false. The description adds behavior the agent could not otherwise know: null clears a field, a list replaces the entire list, contact_email is immutable post-launch, and after launch an edit only propagates to listings not yet sent to a directory. That last point is a genuinely non-obvious partial-propagation effect that directly affects how a caller reasons about the result.

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 compact sentences, front-loaded with the update semantics and then the launch-state constraints. Every clause carries distinct information: partial send, null-clears, list-replaces, immutable field, and post-launch propagation scope.

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 22-parameter mutation tool with an open-world annotation and no output schema, the description covers the semantics that matter most: how to send fields, what clears data, and what is forbidden after launch. It does not say what the response contains or how errors are surfaced, which leaves a small gap for a mutation with this many fields.

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

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

Schema coverage is already 82%, so most parameters are self-documenting. The description still adds cross-field semantics the schema only states piecemeal (replacement for tags, competitors, metadata, excluded_directories): a uniform rule that null clears and lists replace wholesale, plus the immutability of contact_email. Enum values for category, pricing_model, and price_period remain only 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?

States a specific verb and resource: 'Changes project fields.' Combined with the name update_project, an agent immediately understands this is a partial-update operation on a single project. It does not explicitly contrast with siblings like create_project or get_project, but the mutation/read distinction is unambiguous from the verb.

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?

"Send only what changes" tells the agent to use this as a PATCH-style call rather than a full replacement, and the launch-state caveats ("contact_email cannot change after launch") tell it when an edit will fail. There is no explicit pointer to an alternative tool when the edit is rejected, but the preconditions are 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?

The rate limit of 10 checks an hour per project is disclosed in the description and is not available from the annotations, which is exactly the kind of side-effect context that matters. This also implicitly explains why readOnlyHint=false and idempotentHint=false despite the read-like verb. It does not say what a check consumes or what happens when the quota is exhausted.

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, no filler, with the core action first and the operational constraint second. Every clause carries information the agent needs to call it correctly.

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, low-complexity verification tool the description covers when to call, how often, and the quota. The one gap is outcome semantics: there is no output schema and the description does not say whether a missing badge produces an error, a status field, or a failed result. That is a modest but real omission for a network-side check.

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

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

Schema description coverage is 100% and the single project_id includes a regex pattern, so the schema carries the parameter burden. The description only alludes to "per project", adding no format or scoping detail beyond what the schema already states. 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 uses a concrete verb and resource ("checks the client's site for the badge") and adds temporal scope ("now", i.e. a live check) that separates it conceptually from get_badge. It never names get_badge or any sibling explicitly, so an agent must still infer that this is the execution/verification counterpart to fetching badge markup.

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?

Strong context: "check once after the client says it is installed" tells the agent the triggering condition and warns against repeated calls. The rate limit (10/hour per project) reinforces the when-to-use guidance. It stops short of naming alternatives or stating what to do when the check fails, so it is clear context rather than full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description goes further by enumerating the returned facts, including quota state ('launches left and the hourly request budget'), which is exactly the rate-limit context the rubric rewards. With no output schema, this enumeration is the only source of return-value information and it delivers it.

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 zero waste: the payload is front-loaded in a single enumerating clause, and the usage directive follows. Nothing restates the name or title verbatim.

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 zero-parameter read-only diagnostic with no output schema, the description supplies everything needed: the full list of returned fields and the instruction to invoke it first. No auth, side-effect or pagination concerns exist for this tool, so nothing material 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate — the baseline for a no-param tool applies. The description correctly adds no parameter talk, keeping it clean, though it also adds nothing beyond baseline.

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

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

Uses a specific verb ('Shows') against a precisely enumerated resource: the agency, mode, permissions, launches remaining and hourly request budget behind the API key. An agent knows exactly what this tool returns and needs no sibling comparison, since no other tool in the list inspects key 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?

The closing imperative 'Call it first' gives a clear timing/sequencing directive that an agent can act on. It stops short of stating when not to call it or what to do with the results, so it is clear context rather than a full when/when-not rule set.

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