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

Beyond the annotations, the description discloses concrete behavioral facts: the survey keeps running, its public link still works, people can still answer it, results stay readable, and archiving an already-archived survey is a no-op. These details align with readOnlyHint=false, destructiveHint=false, and idempotentHint=true, with no contradiction.

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 four short sentences with no filler: the primary action, downstream consequences, the sibling alternative, and idempotence/restore behavior are all relevant and front-loaded. Every sentence contributes distinct useful 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 two-parameter tool with no output schema and rich annotations, the description covers the core effect, non-effects, idempotence, restore behavior, and the key sibling relationship. Nothing an agent needs to decide between archive_survey and close_survey 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 input schema already covers both parameters (id and restore) with 100% description coverage. The description's mention that '`restore` puts it back in the list' adds little beyond the schema's 'bring an archived survey back into the list instead of hiding it.' No new parameter-specific meaning is provided.

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 states a specific action ('Hide a survey') on a specific resource ('this account's list of surveys') and explicitly contrasts it with close_survey. This distinguishes it clearly from sibling tools and goes beyond the generic title 'Archive a survey'.

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 names the alternative tool (close_survey) and the condition that selects it: 'Use close_survey to actually stop responses.' It also frames archiving as a 'tidying action only,' giving the agent clear guidance on when to use this tool versus alternatives.

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 indicate that this is a non-read, non-destructive, non-idempotent operation. The description goes far beyond that by disclosing that the clone does not inherit archived state or expiry, keeps original colors without a theme, and that the returned admin link is a credential. This is valuable behavioral context for an agent.

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 compact and front-loaded, with the core behavior in the first sentence. Every subsequent sentence adds distinct value: usage guidance, edge-case behavior, theme default, and a security warning. No sentence is wasted.

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 tool with no output schema, the description covers what the operation does, what the result looks like, important inheritance exceptions, theme behavior, and the security implications of the returned link. It also points to the correct alternative sibling. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents all four parameters. The description adds only minor reinforcement about theme defaulting behavior, but does not materially extend what the schema provides. 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?

The description states a specific action (copy a survey's questions into a brand new survey), names the key result attributes (own link, own admin token, no responses), and distinguishes itself from the sibling save_survey_as_template. An agent can tell what this tool does without opening the schema.

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

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

It explicitly says when to use this tool ('run the same poll a second time') and when not to ('use save_survey_as_template instead when it will run repeatedly'). The edge case about expired surveys and active subscriptions adds further contextual 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?

The description adds significant behavioral context beyond the annotations: the public link remains functional and shows the survey as closed, results remain readable via get_survey_results, and reopen_survey can undo the action unless the expiry date has passed. This clarifies the meaning of destructiveHint by showing exactly what is and isn't affected.

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 tightly written sentences carry all the essential information: the main action, the side effects on the public link and results, and the undo path with an important caveat. There is no redundancy 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?

For a single-parameter mutation tool with no output schema, the description covers everything an agent needs: what changes, what remains unchanged, how to read results afterward, and how to undo the action. The expiry caveat is especially valuable because it defines the limits of reversibility.

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 id parameter is already fully documented with type, minLength, and an example. The tool description itself adds no extra parameter semantics, so the baseline score 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 states a specific action ('Stop a survey from accepting new responses') and clearly identifies the resource. It also distinguishes itself from siblings by mentioning reopen_survey as the undo operation and get_survey_results as the continuing read path.

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 establishes when to use the tool: when the survey should no longer accept responses. It also gives useful context about the public link continuing to work and explicitly names reopen_survey as the reversal path, including the expiry exception. It does not explicitly discuss when not to use it relative to archive_survey, but the intended use 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?

No contradiction with annotations: readOnlyHint=false, openWorldHint=true, and destructiveHint=false all match a create operation with external audience access. The description adds genuinely useful behavior beyond annotations — the survey is open immediately, anyone with the link answers without sign-in, results update in real time, and every question stays visible regardless of requirement mode.

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?

Roughly 190 words, front-loaded with the core output (two links), then question types, requirement behavior, theming, and usage guidance in logical order. Well structured and mostly tight, though the every-question-stays-visible sentence partly duplicates what the schema's requirement descriptions already state at length.

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?

Despite having no output schema, the description carries the return contract — the two links and their distinct roles — plus the access model and immediate-opening behavior, which structured data cannot express. That is sufficient for a complex tool whose parameter detail lives in a richly documented schema; only minor edge cases (question-count limits, slug-collision error handling) are left to the 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 schema fully documents all four parameters (slug, theme, title, questions) including the nested requirement/condition logic. The description only cross-references 'requirement' and 'theme' without adding syntax or semantics, so the baseline 3 applies.

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

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

The opening sentence names a specific verb and resource — 'Create a live audience survey on rifts.to' — and adds a distinguishing output: the two links (public + admin) that run it. This differentiates it from siblings like create_template, update_survey, and close_survey without needing to open their 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?

'Use this whenever someone wants to poll a room, run a quick vote, or collect open-ended feedback' gives explicit when-to-use context. It stops short of naming exclusions or alternatives, so an agent deciding between create_survey and create_template still has to infer which fits a reusable-vs-live scenario.

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 description goes well beyond the sparse annotations. It clarifies the key side effect—no survey is started—and explains the reuse behavior: each launch via launch_template creates a fresh survey, keeping weekly poll answers separate. It also discloses lifecycle limitations upfront: templates cannot be edited or deleted through this API. This meaningfully informs an agent about what to expect after invocation.

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, each earning its place: the first states the core action and what it avoids, the second explains the practical reuse pattern with a concrete example, and the third sets boundaries for template management. The most important information is front-loaded, and there is 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 tool with a complex nested questions schema and no output schema, the description covers the essential operational context: what saving means, that it does not start a survey, the relationship to launch_template, and where editing/deleting happens. It does not describe the return value, but given the absence of an output schema and the richness of the input schema, the description is still sufficiently complete for correct selection and invocation.

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

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

The description itself adds no parameter-level detail, but the input schema is fully covered (100%) with rich descriptions, including the meaning of `name`, the structure of `questions`, and the semantics of conditional `requirement` logic. Baseline 3 is appropriate because the schema already carries the heavy lifting.

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

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

The description opens with a specific verb and resource: 'Save a set of questions for reuse' and immediately distinguishes itself from creating a survey by adding 'without starting a survey.' It also names the related launch_template tool, so there is no ambiguity about what create_template does.

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 explicitly tells the agent when not to use this tool ('without starting a survey'), points to the correct alternative for launching later ('Launching it later with launch_template'), and gives an exclusion for editing/deleting templates ('done on rifts.to, not here'). This is proactive routing guidance that removes guesswork.

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 description goes well beyond the readOnlyHint and openWorldHint annotations by detailing exactly what is returned: per-option tallies, averages, full free-text answers, total response count, and current status. It also explains the behavioral nuance of optional/conditionally required questions and explicitly states that responses carry no respondent identity, adding significant transparency.

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?

Every sentence earns its place: the first states the core purpose and output summary, and the rest covers important behavioral caveats and privacy characteristics. The description is detailed but not padded, and the most important information is front-loaded.

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?

Despite having no output schema, the description fully enumerates the return components and clarifies edge cases about missing answers and anonymity. For a straightforward read tool with one well-documented parameter, this is complete enough for an agent to know what to expect and how to interpret the data.

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 schema already fully explains the 'id' parameter, including format and how to obtain it. The tool description adds no additional parameter-specific guidance, so the baseline score 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 states a specific verb ('Read') and resource ('answers to one of your surveys'), and clarifies it returns a summary rather than raw survey configuration or a list of surveys. This clearly distinguishes it from sibling tools like list_surveys, update_survey, or close_survey.

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 intended use is clear from the phrase 'Read the answers to one of your surveys,' so an agent can infer it is the right tool for retrieving results. However, it does not explicitly contrast this with sibling tools or state when not to use it, leaving the usage guidance implicit rather than 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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Read' framing is consistent with them. Beyond that, the description discloses the scope of the result set — counts, tallies for every option including zero-selection ones, mean and spread — and explicitly flags that written answers are excluded, which the annotations do not convey. It adds useful behavioral context without contradicting the annotations.

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

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

Three sentences with zero redundancy: the first states the core behavior, the second gives the selection rationale, and the third clarifies the exclusion. The most decision-relevant information is front-loaded, and every sentence earns its place.

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

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

For a one-parameter, read-only tool with no output schema, the description fully compensates by describing the return shape (counts, tallies including zero-picked options, mean and spread) and the notable omission (written answers). Nothing an agent needs to select and invoke it correctly is missing, and the annotations cover the safety profile.

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

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

The single parameter 'id' is fully documented in the schema (100% coverage) with type, minLength, and a concrete example ('fuzzy-sleepy-tornado'), so the description has no obligation to add more. It doesn't elaborate on the parameter, but the baseline of 3 applies because the schema carries the full semantic weight.

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

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

The description opens with a specific verb ('Read') tied to a clear resource (a survey's results) and enumerates exactly what form the summary takes: respondent count, a tally for every multiple-choice option including unpicked ones, and the mean and spread of each rating. This makes it immediately distinguishable from its closest sibling, get_survey_results.

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 instructs to 'Prefer this over get_survey_results whenever the question is about the numbers' and gives the size rationale. It also names what this tool omits (written answers) and which sibling returns them, leaving no ambiguity about tool selection.

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 description goes well beyond the annotations by disclosing key behavioral traits: the survey copies the template's questions at launch time, later template edits do not affect launched surveys, and each launch collects separate answers. It also states the two returned links and their functions.

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 three sentences with no filler. The core action and return values come first, behavioral nuances follow, and the use case is stated last. Every sentence earns its place.

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

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

There is no output schema, so the description correctly explains the return value: a public URL and an admin URL with real-time results. It also covers snapshot semantics and answer isolation, making the tool's behavior sufficiently complete for an agent to invoke it confidently.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds contextual flavor about recurring launches but does not add parameter-level meaning beyond what the schema provides, matching the 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?

The description clearly states a specific verb and resource: 'Start a new live survey from a saved template.' It also distinguishes itself from siblings by emphasizing the template source and the recurring-use case, so an agent can tell it apart from create_survey or list_templates.

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 gives clear usage context: 'Use this to run a recurring poll again.' It does not explicitly enumerate when-not-to-use or name alternative tools, but the template-snapshot behavior and recurring-poll phrasing provide enough differentiation.

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 readOnlyHint and openWorldHint annotations, the description discloses meaningful behavior: newest-first ordering, exclusion of archived surveys, default omission of admin links, and the credential-sensitive rationale for that default. This is rich, relevant behavioral context that annotations alone do not provide.

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 compact, front-loaded with the core listing behavior, and each sentence earns its place: what is returned, why the tool is used, and an important default behavior with rationale. No filler or redundancy.

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 covers the essential context: authentication scope, ordering, returned fields, archived-survey behavior, admin-link credential handling, and a typical usage scenario. The optional parameters are already fully documented in the schema, so nothing critical is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the practical consequence of include_admin behavior in terms of credential exposure, and it reinforces defaults without merely repeating schema text. This modest additional context justifies a 4.

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 states a specific action and resource: listing surveys on the authenticated rifts.to account, with explicit output fields (id, title, status, response count, public link). It also clarifies scope by noting archived surveys are never listed, which helps distinguish it from related survey operations.

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 gives clear context and an explicit use case: 'Use it to find the id of a survey before reading its results or closing it.' It does not explicitly name alternative sibling tools or state when not to use it, so it falls just short of full 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, but the description adds meaningful context: templates are not live surveys, they collect no answers until launch_template is invoked, and the output includes id, name, and questions. This clarifies the tool's conceptual behavior beyond the annotation and helps avoid misuse.

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, each earning its place: the first states the action and result, the second explains the template-vs-survey distinction, and the third gives the concrete use case. No filler or redundant restatement of the title.

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 listing tool, the description covers what the tool does, what it returns, why templates differ from surveys, and how to use the result (find id before launching). The lack of an output schema is mitigated by listing the returned fields explicitly.

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 has zero parameters, so there is nothing for the description to document. The baseline of 4 applies because no parameter guidance is needed; the description correctly focuses on the operation itself.

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 states a specific verb ('List') and resource ('saved question sets on the authenticated rifts.to account'), and specifies the returned fields (id, name, questions). It also differentiates templates from live surveys, which distinguishes this tool from list_surveys and other survey-related 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?

The description explicitly says to use this tool to find the id of a template before launching it, and names launch_template as the follow-up. It also clarifies that templates collect no answers until launched, which guides the agent away from using this tool for live survey data.

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, the description explicitly states that public links, admin links, and existing responses are unaffected, and explains why the title is not a key. This directly addresses the main concern an agent would have about renaming, adding valuable context that readOnlyHint and destructiveHint alone do not provide.

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. The first sentence states the action directly; the second sentence earns its place by explaining the non-destructive consequences. The most important behavioral information is front-loaded.

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 rename operation, the description covers the essential behavioral context: what changes, what does not change, and why. Combined with the fully described schema and safety-related annotations, nothing needed to invoke the tool correctly is missing.

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

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

The schema already documents both id and title with examples and length limits, so the baseline is 3. The description adds conceptual meaning by clarifying that title is not a key for any data association, which helps the agent understand that changing it is safe with respect to responses and links.

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

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

The description opens with a specific verb and resource, 'Change a survey's title,' which exactly matches the tool name and differentiates it from the broad update_survey sibling. It clearly states the single operation performed, leaving no ambiguity about scope.

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 makes the intended use clear: call this when you need to rename a survey. It does not explicitly name update_survey as the alternative for other modifications, but the title-only scope is obvious and no misleading guidance is present.

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 description adds meaningful behavioral detail beyond the annotations: answers already collected are kept, the same public link is reactivated, and expired surveys cause the API to refuse rather than silently succeed. This gives the agent a clear model of side effects and failure behavior.

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 compact and front-loaded, with the primary purpose stated first, followed by essential state-preservation and constraint details. Every sentence earns its place, and there is no filler or repetition of the title.

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 tool with no output schema, this description is complete: it explains the effect, what is preserved, what is reactivated, the expiry limitation, and where to handle that limitation. An agent has enough context to invoke it correctly and avoid misuse.

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

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

The input schema already documents the only parameter fully, including a concrete example ('fuzzy-sleepy-tornado'). The description does not need to repeat parameter details, so the schema carries the burden and the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Let a closed survey accept responses again.' This clearly distinguishes reopen_survey from siblings like close_survey and archive_survey, and states the observable effect (public link works again).

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 when to use the tool (for a closed survey that should accept responses again) and gives an exclusion: surveys past their expiry date cannot be reopened this way. It even routes the user to the alternative (clearing expiry via the rifts.to admin dashboard), leaving no ambiguity.

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 signal readOnly=false, idempotent=false, and destructive=false, so the bar for adding context is lower. The description adds significant behavioral value by explaining the snapshot semantics: editing the survey never changes the template, and launching the template never changes the survey. A minor gap is that it doesn't clarify what happens if the same survey is saved multiple times, which is relevant 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?

Three sentences, each earning its place: the first states the action and purpose, the second explains the snapshot behavior, and the third provides the alternative. There is no filler and the key scoping detail is front-loaded.

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 tool with no output schema, the description covers purpose, usage, and core behavior. It doesn't mention repeated-save behavior or name conflicts, which could matter given the non-idempotent annotation, but the essential information for an agent to call the tool correctly 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 description coverage is 100%, so the baseline is 3. The description adds one useful semantic nuance: it explicitly says only the survey's 'questions' are saved, not other survey data. This clarifies what the id parameter refers to and what the resulting template contains, going slightly beyond the schema's generic wording.

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 states a specific verb ('save') and resource ('a survey's questions as a template'), and immediately ties it to a clear purpose: so launch_template can run them again later. It also explicitly differentiates from clone_survey, which is the closest sibling. The title and description together make the tool's role 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?

The description explicitly states when to use this tool: when you want to reuse a survey's questions later via launch_template. It also names an alternative and the condition for choosing it: 'Use clone_survey instead for a one-off repeat.' This gives the agent clear routing guidance with no need for 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 only provide readOnlyHint=false and destructiveHint=false; the description adds substantial behavior beyond that: partial-update semantics, refusal-with-explanation on unsafe edits, the underlying storage model (answers stored by position and exact option text) that explains why edits would orphan answers, and a platform-level invariant about titles. The 'refused' behavior is consistent with destructiveHint=false since unsafe operations never execute. No contradiction with annotations.

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

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

Four dense sentences with the purpose front-loaded in the first and constraints ordered by importance. For a tool whose input schema is enormous and deeply nested, the description stays at the behavioral level and repeats nothing the schema already covers. Every sentence carries operational weight.

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?

Everything needed to invoke the tool correctly is present: what can be changed, which edits are refused and why, and that the title is immutable platform-wide. Two minor gaps exist given there is no output schema: the return value is never described, and preconditions such as whether the survey must be open (vs. closed/archived) are unstated, leaving those states to be inferred from sibling tools.

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 schema's embedded descriptions are exhaustive — replacement semantics for the question list, conditional requirement rules, and questionIndex constraints are all documented there. The description still adds value above the schema by establishing the patch semantics ('Send only what should change'), which tells the agent it can omit theme or questions entirely for a partial update.

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

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

The description opens with a specific verb and resource — 'Change a survey that already exists: its colors, its questions, or both.' It states the exact scope, and the 'already exists' phrasing immediately distinguishes it from sibling create_survey. The closing statement about the title also tells the agent precisely what this tool cannot do.

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 gives explicit when-to-use context ('a survey that already exists', 'Send only what should change') and explicit when-not guidance: losing/reordering/retitling questions is refused, and the title cannot be changed 'here or anywhere else on rifts.to'. However, it never names a sibling alternative (e.g., create_survey for new surveys), so routing between siblings is implied rather than stated outright.

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