Run it by

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

The annotation already flags destructiveHint=true, so the safety profile is known. The description adds real value with a user-visible consequence (pending public links resolve to a closed page), but says nothing about reversibility, whether existing submitted answers are retained, or permission requirements for a destructive state change.

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 primary effect followed by the side effect, with no filler. It is efficient, though the second sentence's phrasing ('show a closed page') is slightly ambiguous about who sees that page.

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, irreversible state change on a live request with no output schema, the definition omits what the agent most needs: whether the action can be undone, what happens to responses already collected, and what a successful vs. failing call looks like. What is present is accurate but far from sufficient.

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?

One required parameter with 0% schema description coverage, so the description carries the full burden and provides nothing — requestId's expected format, source, or validation is undocumented everywhere. The only compensation is that 'requestId' is fairly self-explanatory by name.

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?

"Stop accepting answers" describes the effect but never names the resource (a request) — the agent must infer that from the tool name and title. It does implicitly distinguish itself from siblings like createRequest and updateRequest, since none of them close anything.

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

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

No guidance on when to use this versus updateRequest or any other sibling, and no stated prerequisites or exclusions. The verb 'stop' implies a terminal action, but nothing tells the agent under what conditions closing (rather than updating) is correct.

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

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

No annotations exist, and the description carries the full burden well: it discloses return shape (one url or one link per recipient), per-recipient sendEmail status values, delivery channels (webhookUrl, notifyEmail, getStatus), quota behavior (250/month Free, fails with clear error, already-sent links keep working), and the verification requirement for sensitive approvals. That is exactly the kind of operational context an agent needs before invoking a mutation.

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

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

Purpose is front-loaded, but the remainder is one very long paragraph mixing mode selection, schema-subset rules, widget names and quota policy, with semicolon-chained clauses that are hard to scan. A bulleted structure per mode would convey the same content with less parsing cost; some widget enumeration is arguably over-detailed for a description.

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 14-parameter, nested-object tool with no output schema and no annotations, the description covers the return values, delivery paths, expiry default, quota and error behavior — enough to call it correctly. The unexplained 'sections' parameter and the absent follow-up tool guidance (updateRequest, closeRequest, remind) are the remaining 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?

Adds substantial meaning beyond the 57% schema coverage: the JSON Schema subset and limits for mode 'form' (types, formats, 40-field cap, no nesting except the location widget), the full widget catalogue via x-runitby.widget, the 1–50 named recipient bound, approval.policy resolution semantics, and sendEmail/notifyEmail behavior. Gaps remain: 'sections' is never mentioned despite being a structured parameter, and 'theme', 'requester' and 'metadata' are left to the schema or to llms.txt.

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 concrete verb+resource — collect answers from people outside the chat via a link — and enumerates the three concrete shapes (open form/survey/poll/sign-up, named-recipient form, approval/sign-off). This is clearly distinguishable from siblings like listRequests, getStatus, closeRequest and remind, which operate on already-created requests.

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 clear selection criteria between mode 'form' vs 'approval' and audience 'named' vs 'open' (attributed answers vs one link capped by maxSubmissions), plus when to set approval.verify 'email' (money, access, deletion). It also points to getStatus (with wait) as the retrieval path. It stops short of explicit when-not-to-use guidance or naming updateRequest/closeRequest as the follow-up 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?

readOnlyHint is already covered by annotations, but the description adds genuinely new behavior: the call blocks up to ~25s, returns immediately on any change, and is meant to be re-invoked to continue waiting. That's a non-obvious polling contract an agent needs. It stops short of describing the returned payload structure in detail.

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 what is returned and then the blocking semantics. No filler and no redundancy in phrasing.

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 polling tool with no output schema, the description tells the agent the shape of the result and the blocking contract, which is most of what's needed to call it correctly. The unexplained requestId parameter keeps it from being 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 only 50%: requestId has no description anywhere, and the description does not explain what it identifies or where it comes from. The wait explanation largely restates the schema's own description and maximum, adding only the 'call again' loop pattern. With half the parameters undocumented, the description should compensate more than it does.

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 specific resource being returned: status, verdict (approvals), and each recipient's answer. This is clearly a read/poll operation, distinguishable from mutating siblings like closeRequest or updateRequest. It does not explicitly contrast with listRequests or previewRequest, so a 4 rather than a 5.

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 long-poll pattern is spelled out ('call again to keep waiting'), which implies usage for waiting on responses. However, it never states when to prefer this over listRequests or previewRequest, nor any exclusions or prerequisites. Usage is inferable but not explicit.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds two useful behaviors beyond that: results are limited to the caller's own requests and are ordered newest first. It says nothing about pagination, the default page size, or the maximum limit, which matter for a cursor-based listing 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?

A single front-loaded sentence with zero filler, but it is so terse that essential guidance was cut rather than compressed.

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 four-parameter, cursor-paginated listing tool with two enums and no output schema, the definition omits filter semantics, page size behavior, and how to continue with a cursor. An agent could call it, but not confidently or efficiently.

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% across four parameters, so the description needed to carry the load, but it never mentions mode, status, limit, or cursor. The enum values 'form' and 'approval' are especially opaque with no explanation of what distinguishes them.

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 (Find) and resource (requests) plus scope ('you already created') and ordering ('newest first'), so the agent knows this is a listing of the caller's own requests. It stops short of differentiating from getStatus or the other siblings, so not a 5.

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 statement of when to use this rather than getStatus, previewRequest, or createRequest, and no mention of what mode/status filters are for. The 'requests you already created' scoping is the only implicit usage cue.

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?

readOnlyHint=true is the only annotation, and the description corroborates it by framing this as a rendering pass performed 'before creating', with an explicit return payload: screenshots plus lint on contrast, long labels and missing help. It does not address whether the preview is persisted or expires, which is the one remaining behavioral gap.

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 is rendered and returned, then the input scoping, then the workflow guidance. Dense but every clause carries information an agent needs.

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 tool with 10 parameters and no output schema, the description covers the return artifacts, the input subset and the workflow, which is enough to call it correctly. Minor gaps are lifetime/persistence of the preview and any auth requirement, neither of which blocks a correct call.

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 60%, and the description usefully clarifies that this accepts the fields of createRequest minus audience, expiresIn, webhookUrl and metadata — a scoping rule the schema cannot express on its own. It also names viewports and sampleData and their purpose, going beyond the property definitions.

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 — renders the form or approval card as a recipient sees it — and pins down the output (screenshots plus plain-language lint) and the two viewport widths. An agent can distinguish this from createRequest purely from the text, since 'preview' versus 'create' is drawn 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?

Gives an explicit trigger ('preview before creating when the person will see the form more than once') and an implicit exclusion for one-off forms, plus the follow-up action ('then adjust theme and hints'). It also names the sibling it relates to (createRequest) and the fields to reuse.

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

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

With no annotations, the description carries the full burden and does well: it discloses the external side effect (sends real email), the rate limit including that sendEmail counts toward it, and the failure modes (no email, reminded in last 24h, sending failed, plan email limit reached). It omits permission/auth requirements and whether sending is reversible — impossible to undo a sent email.

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

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

Front-loaded with the action and its constraints, and the second sentence covers return shape — necessary here because no output schema exists. Dense but essentially every clause (rate limit, skip reasons, plan limit) 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?

For a 2-param tool with no annotations and no output schema, the description supplies the safety profile (rate limit, irreversible send), the trigger conditions, and the return contract (sent[]/skipped[] with reasons). Only auth/prerequisite context and the definition of 'the link' would add further value.

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 only 50%, so the description should compensate; it clarifies eligibility ('pending named recipients that have an email') and ties recipientIds to recipients added via updateRequest. requestId is never explained, but its meaning is self-evident from the required-field schema. Adequate, not rich.

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: emails the link to *pending* named recipients that have an email, with a per-person 24h cap. The scope ('pending … that have an email') is precise enough that an agent can distinguish this from closeRequest/createRequest/listRequests without inspecting schemas.

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

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

Gives explicit trigger conditions: chase people who have not answered, or email recipients just added with updateRequest. The 24h-per-person cap implicitly defines a 'do not use' case, but no explicit exclusion or prerequisite (e.g. request must be open) is 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?

With no annotations, the description carries the full behavioral burden and delivers two non-obvious traits: existing links keep working after edits, and added recipients are silently NOT emailed. What it omits is equally important mutation semantics — whether supplying `sections` or `schema` replaces existing content wholesale, and what error/response occurs when the time window has passed.

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

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

Four sentences, zero filler, and the most consequential constraint (the first-response cutoff) is stated first. Each sentence carries a distinct rule rather than restating the field list.

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

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

For a 9-parameter mutation with nested objects, no annotations and no output schema, the description covers the temporal gating, the link-stability guarantee, and the recipient-notification workaround. It falls short on replacement semantics for nested fields and on permission/error preconditions, which an agent calling this correctly would want.

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 33%, so the description should compensate more than it does. It adds real meaning for `expiresIn` ('a new expiry counted from now' — resets, does not extend) and for `addRecipients` (no email sent), but leaves the highest-risk parameters, `schema` and `sections` (nested objects, replace vs merge), unexplained in both schema and description.

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 a specific verb ('Change') and enumerates exactly which request fields are editable, plus the distinct group (addRecipients, expiresIn, notifyEmail) governed by a different rule. An agent can immediately tell this is a field-level patch on an existing request rather than a create/close operation, and the mention of 'remind' anchors it against a named 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?

Gives explicit, differentiated timing rules: title/schema/sections/reason/theme only 'until the first response', while addRecipients/expiresIn/notifyEmail work 'until the request is closed, expired or complete'. It also routes the agent to an alternative ('send their links, or call remind with their recipientIds') for the follow-up notification case.

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