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

Annotations provide readOnlyHint=false and destructiveHint=false; the description adds that activation 'changes its structure and behavior', which is critical context. It also explains authentication using a service account. 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?

Two sentences: first states purpose and precondition, second gives technical details. No wasted words, front-loaded with essential 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?

Given complexity (4 params, output schema exists), the description covers activation purpose, consistency checks, required confirmation, and authentication. It's complete for typical use, though could explicitly note that activation may fail if checks fail.

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. The description adds the requirement 'confirm_activation=true' beyond what the schema indicates (const: true), and implies its role in acknowledging changes. This adds sufficient value.

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 tool activates a survey, with the verb 'activate' and resource 'survey'. It distinguishes from siblings as the only activation tool among many survey management tools.

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 indicates activation should occur 'after LimeSurvey consistency checks', providing clear context. It does not explicitly state when not to use or list alternatives, but the specificity suffices.

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?

Description aligns with annotations (writes, not destructive). It adds the detail about internal method call and authentication, but does not disclose additional behavioral traits beyond what annotations 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, each valuable: first states purpose, second gives technical context. Efficient with no fluff.

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 simple parameters and existence of output schema, description covers main functionality well. Missing preconditions (e.g., survey must exist) but otherwise 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 covers 100% of parameters. Description adds the concept of optional custom attributes matching attribute_fields, but no extra detail on syntax or usage beyond 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?

Clearly states it creates the survey participant table and optional custom attributes. Verb 'create' and resource 'participant table' are specific. Distinguishes from siblings like activate_survey or add_participants.

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 tool versus alternatives, no prerequisites (e.g., survey must exist), and no mention of required survey state before activation.

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 indicate a write operation that is not idempotent; description adds that it calls `add_group` and uses service account auth. However, it does not disclose potential error conditions (e.g., duplicate title) or side effects beyond creation.

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 superfluous words. Purpose and key technical detail (method + auth) are front-loaded. Every sentence adds value.

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 an output schema present, the description doesn't need to explain returns. It covers the core action and authentication. Minor gap: it doesn't explicitly tie parameters (title, description) to the group creation.

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 description does not need to add parameter details. However, it adds no extra meaning beyond the schema, such as clarifying the 'empty' nature or expected output.

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 tool adds an empty question group to a survey, which is a specific verb+resource. It distinguishes from sibling tools like delete_group, import_group, set_group_properties.

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 when to use (adding a new group) but does not explicitly exclude scenarios or mention alternatives. It provides authentication context but lacks explicit when-not 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 indicate readOnlyHint=false and openWorldHint=true, so the tool is not read-only. The description adds one behavioral detail: authentication uses a configured service account (no session key). However, it doesn't disclose side effects, error handling, or whether multiple additions are allowed. Given annotations already cover non-read-only nature, the description adds moderate value.

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 first immediately states the tool's core purpose, the second adds a critical authentication behavior. Every word earns its place; there is no fluff. The structure is front-loaded and efficient.

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 that the tool has a simple operation (add a language) and an output schema exists, the description is minimally adequate. However, it lacks context about valid language codes, whether the tool overwrites existing translations, or how to handle errors. For a tool in a large suite with many similar operations, more context would improve completeness.

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 all three parameters described in the input schema. The description adds no additional parameter details beyond what the schema provides. Baseline for high coverage is 3; no extra semantic value is contributed.

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 action 'Add a language to a survey' and references the underlying LimeSurvey method. It immediately distinguishes from sibling tools like 'limesurvey_get_survey_languages' (read) and 'limesurvey_delete_language' (delete) by specifying the add operation.

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 only says 'Add a language to a survey,' without guidance on when to use it versus alternatives. There is no mention of prerequisites (e.g., survey existence, valid language codes) or exclusions. The use case is implied but not explicitly differentiated from other language-related 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 (readOnlyHint=false, destructiveHint=false) indicate mutation but non-destructive behavior. The description adds no further behavioral context such as what happens if a participant already exists, validation rules, or side effects. Minimal transparency beyond structured 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?

Single sentence, front-loaded with verb and resource. Concise, but could be slightly more informative without losing brevity. No fluff.

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 3 parameters, nested objects, and an output schema, the description is too brief. It doesn't mention return values, required session key, or that the survey must exist. Incomplete for effective tool 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 67%, so baseline is 3. The description 'simple participant object' hints at the nature of the participant parameter but adds little beyond the schema's own description. No extra meaning for survey_id or create_token.

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 'Add one participant using a simple participant object' clearly states the action and differentiates from the sibling limesurvey_add_participants (plural) by specifying 'one'. However, it does not explicitly mention that the participant is added to a survey, though the survey_id parameter implies it. Slightly vague but sufficient.

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 alternatives like limesurvey_add_participants for batch adds. No prerequisites, no mention of token creation default or when to set create_token to false. Lacks contextual usage advice.

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 indicate readOnlyHint=false and openWorldHint=true. The description adds context about the underlying API method, authentication via service account, and instructs not to provide a session key. This goes beyond annotations and clarifies operational details.

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 concise sentences: the first immediately states the purpose, the second adds method and authentication context. No extraneous information. Well-structured and 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?

Given the presence of an output schema, the description does not need to explain return values. It covers core purpose and auth behavior. It might optionally mention parameter interactions like token generation, but overall it is sufficiently 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?

Input schema has 100% description coverage, so the description does not need to add per-parameter details. The description does not explain individual parameters beyond what is in the schema, which is acceptable. 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 clearly states 'Add one or more participants to a survey', using a specific verb and resource. It also mentions the underlying API method and distinguishes from the sibling tool for adding a single participant.

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 by stating the action but does not provide explicit guidance on when to use this tool vs alternatives like limesurvey_add_participant for single additions. No exclusions or prerequisites are mentioned.

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 annotations, only mentions authentication. No details on side effects, validation, or success/failure indicators. Does not contradict 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?

Two sentences, no fluff. Front-loaded with the action. Could benefit from slightly more detail without harming conciseness.

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 10 parameters and an output schema, the description lacks context about what a quota is, how it works, or any constraints. Minimal given tool complexity.

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 description adds minimal value beyond schema. The phrase 'minimum details' hints at optional parameters but doesn't clarify beyond 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?

Clearly states 'Create a quota' and specifies the underlying API method. Distinct from sibling tools (list, delete, get, set quotas).

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 vs alternatives, no prerequisites mentioned (e.g., survey must exist). Only auth note is provided.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds no new behavioral traits beyond stating it is an insert operation, which is implicit from the name and 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?

The description is concise with three sentences, front-loading the purpose. The second sentence mentioning the underlying method is somewhat redundant but not harmful. Overall efficient and well-structured.

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?

An output schema exists, so return values need not be explained. However, the description lacks guidance on constructing the response object or common pitfalls, which would be helpful given the nested structure and openWorld annotation.

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 covers 100% of parameters with descriptions, and the description does not add additional context or usage notes for the 'response' object or 'survey_id'. Baseline of 3 is appropriate as the schema is self-sufficient.

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 'Insert a response into a survey response table', providing a specific verb and resource. It differentiates itself from siblings like update_response or delete_response by using 'insert', though it does not explicitly name alternatives.

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 only provides authentication guidance ('do not provide a session key'). It lacks information on when to use this tool versus alternatives, such as update_response, and does not specify prerequisites or conditions.

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

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

The description adds value beyond annotations by naming the specific API method (add_survey) and clarifying that authentication is handled automatically. Annotations already indicate readOnlyHint=false and openWorldHint=true, so the mutation is expected. No contradictions.

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

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

The description is two sentences with no fluff. It front-loads the purpose and adds essential context about the API and authentication. 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?

Given the complexity of the LimeSurvey tool set and the presence of an output schema (not shown here), the description is adequate for a straightforward creation tool. It covers the key behavioral aspect (automatic auth) and purpose, though it could mention that the survey starts inactive or note next steps.

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 are well-documented in the schema. The description does not add additional meaning or context to the parameters beyond the schema, meeting 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 the verb (create) and resource (empty survey), and the title 'Create survey' reinforces it. Among many sibling tools like import_survey, copy_survey, and list_surveys, this tool is uniquely distinguished as creating a new empty survey with minimum settings.

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 mentions authentication details ('do not provide a session key') which is helpful, but it does not explicitly guide the agent on when to use this tool vs alternatives like import_survey or copy_survey. The context of 'minimum settings' is implied but not compared to other creation methods.

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 provide idempotent and non-destructive hints. The description adds value by clarifying that the tool works through set_survey_properties and does not install theme packages. This extra context about the underlying mechanism and scope enhances transparency beyond 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?

The description is a single, concise sentence that efficiently conveys the tool's purpose and a key limitation (no upload/install). Every word serves a purpose with no 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?

Given the tool mutates survey state, the description lacks details on return values, error conditions, prerequisites (e.g., theme must exist), and the effect of confirm_theme_assignment. While annotations provide some context, the description is insufficient for a complete understanding.

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 67%, with survey_id lacking a description. The description does not add any parameter-specific meaning, missing the opportunity to clarify the purpose or format of the parameters beyond the schema.

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

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

The description clearly states the tool assigns an already imported theme to a survey, using the verb 'assign' and specific resource. It distinguishes from sibling tools like limesurvey_set_survey_properties and limesurvey_list_installed_themes by clarifying it does not upload or install the theme.

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 the theme must be already imported, but does not explicitly state when to use this tool versus alternatives such as limesurvey_set_survey_properties. No direct comparison or when-not conditions are provided, making the guidance adequate 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 disclose readWrite (readOnlyHint=false), non-destructive (destructiveHint=false), and non-idempotent (idempotentHint=false). The description adds value by specifying the underlying LimeSurvey method and clarifying that authentication uses a configured service account (no session key), which is behavioral context beyond 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?

The description is extremely concise (two sentences) and front-loaded with the core purpose. Every sentence adds necessary information without redundancy or fluff.

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?

The description covers the basic operation and authentication detail but lacks preconditions (e.g., source survey existence, permissions) and does not address potential side effects flagged by openWorldHint=true. Since an output schema exists, return values are not required, but completeness for the agent is moderate.

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?

All parameters are fully described in the input schema (100% coverage). The description does not add any additional meaning or context for the parameters, meeting the baseline expectation.

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 'Copy an existing survey under a new name,' which specifies the action (copy) and resource (survey). However, it does not explicitly differentiate from sibling tools like add_survey or import_survey, but the purpose 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?

No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., add_survey for new surveys, import_survey for file-based creation), leaving the agent without context for 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?

Annotations already indicate write operation (readOnlyHint=false) and non-idempotent, non-destructive. The description adds a specific call method and authentication note, but does not elaborate on error behavior, batch limits, or conflict resolution beyond the update_existing parameter.

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 consists of two concise sentences. The first sentence clearly states the purpose, and the second provides a technical detail about authentication. No extraneous words or redundant 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?

Given the output schema exists, the description correctly avoids explaining return values. It covers the action, underlying method, and authentication. It could be improved by noting that this tool manages the central database rather than survey-specific participants, but overall it is quite 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 description coverage is 100%, so the schema itself documents all parameters. The tool description adds no additional meaning beyond what is in the schemas, so 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 'Import records into the central participant database', which is a specific verb (import) and resource (central participant database). It distinguishes from sibling tools like limesurvey_add_participants, which likely add participants to a survey, by targeting the central database.

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 provides an authentication instruction but does not give explicit guidance on when to use this tool versus alternatives (e.g., adding participants to a survey). The context is clear but lacks explicit when-not-to-use or comparison with siblings.

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

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

Description adds backend method name ('delete_group') and confirms destructive nature, consistent with destructiveHint annotation. No contradiction. Provides context beyond annotations about the required action confirmation.

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 key requirement, no fluff. Each 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?

Covers purpose, required parameter, auth, and backend. Missing preconditions or error scenarios, but output schema exists. Adequately complete given tool complexity.

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. Description only reiterates the confirm_destructive_action requirement without adding new semantic meaning to parameters beyond 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?

Clearly states deletion of a question group from a survey. Verb 'Delete' and resource 'question group' are explicit. Does not explicitly distinguish from sibling delete tools like limesurvey_delete_survey, but purpose 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?

Mentions required parameter confirm_destructive_action=true and authentication method. Provides some usage context but no guidance on when to use vs alternatives (e.g., delete question vs group) or when not to use.

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 the description reinforces this by requiring confirmation. It adds the backend method call and authentication note. No contradictions. It does not detail edge cases (e.g., removing base language), but given annotation coverage, this is acceptable.

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 no fluff: purpose, requirement, and implementation/authentication. Each sentence earns its place. Well-structured and 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 destructive tool with clear annotations and output schema, the description covers purpose, requirements, authentication, and backend method. It does not describe error handling or edge cases, but these are low priority given the tool's simplicity and annotation support.

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 minimal value beyond schema, only reinforcing the confirm_destructive_action requirement already captured by the const true definition. No additional parameter details are 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 clearly states the action (remove a non-base language), the resource (survey), and distinguishes from siblings like limesurvey_add_language and limesurvey_get_survey_languages. It is specific and 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 requires confirm_destructive_action=true and mentions authentication. It implies the tool is for non-base languages only, providing clear context. However, it does not explicitly state when to avoid using it or list alternatives, though the sibling set makes it 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?

Annotations already indicate destructiveHint=true. The description adds value by disclosing the required confirm_destructive_action parameter and the authentication method (configured service account, not providing session key). No contradictions.

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 concise sentences; the first sentence states purpose and requirement, the second provides technical implementation details. No wasted words, 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?

Given the tool has an output schema, the description does not need to explain return values. It covers deletion intent, required confirmation, and authentication, which is sufficient for a straightforward delete operation. Could mention error handling or success indicators, but not necessary.

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 minimal extra meaning beyond the schema, essentially restating the token_ids purpose and the confirm requirement. No detailed syntax or usage nuances are 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 clearly states the verb 'delete' and resource 'participants', specifying the method 'by token-table row IDs'. It differentiates from sibling tools like add, get, list, mail, invite, remind, etc.

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

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

The description implies usage for deletion (requires confirm_destructive_action=true) but does not explicitly state when to use this tool versus alternatives like delete_survey or delete_response. No exclusions or context is provided beyond the action itself.

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?

Description adds value beyond annotations by specifying the requirement for confirm_destructive_action=true, the underlying LimeSurvey method, and that authentication is handled automatically. 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?

Three sentences, each adding distinct value: action, requirement, background. No fluff, 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?

With output schema present, the description adequately covers the destructive nature, required confirmation, and authentication. It could clarify how to obtain question_id, but overall 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?

Schema coverage is 100%, so baseline is 3. The description reinforces the confirm_destructive_action parameter's role and mentions the method, but adds minimal extra meaning beyond the schema.

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

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

The description clearly states 'Delete a question from its survey', which is a specific verb and resource. It distinguishes from sibling tools like delete_survey, delete_group, etc., by focusing on questions.

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 for deleting a question and requires confirm_destructive_action=true. It does not explicitly exclude alternatives, but sibling tool names make it clear this is for questions only.

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 destructiveHint=true. Description adds details about the underlying LimeSurvey method and authentication requirement, but no additional behavioral expectations beyond what's obvious from the name.

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 fluff. Front-loaded with purpose and immediate requirement.

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 destructive tool with full schema coverage and output schema, the description covers the essential purpose, confirmation requirement, and backend method. Missing details like which quota to delete are in 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 coverage is 100%. Description only reiterates the confirm_destructive_action constraint, adding no new information beyond 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?

Clear verb 'Delete' and resource 'survey quota'. Distinguishes from siblings like limesurvey_delete_survey, limesurvey_delete_group, etc.

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

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

Explicitly states requirement for confirm_destructive_action parameter, indicating it's a destructive operation. Does not explicitly state when to use vs alternatives, but the tool is self-contained for deleting a specific quota.

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 set destructiveHint=true, but the description adds context like 'Permanently delete' and the necessary confirmation. The authentication note goes beyond structured metadata, providing valuable behavioral insight.

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 essential: purpose, prerequisite, backend call and authentication. No wasted words, front-loaded with key info.

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 output schema present, description need not detail returns. It covers purpose, requirement, and auth. For a deletion tool with good structured metadata, this is sufficient. Could mention effect on related data, but not required.

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?

Input schema covers all parameters with 100% description coverage, so baseline is 3. The description reiterates the confirm_destructive_action requirement but adds no new meaning beyond schema descriptions.

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 tool's action: 'Permanently delete a response.' The verb 'delete' and resource 'response' are specific, and the requirement for confirm_destructive_action is highlighted. No ambiguity.

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 provides clear prerequisites: 'Requires confirm_destructive_action=true' and 'Authentication uses the configured service account; do not provide a session key.' It implicitly distinguishes from siblings like 'limesurvey_update_response' by focusing on deletion, but lacks explicit when-not or 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?

Description goes beyond annotations by stating permanent deletion, required confirmation, underlying API method, and authentication details. No contradiction with annotations (destructiveHint: true).

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?

Description is extremely concise with 3 sentences, front-loading the key action and proceeding with essential details. No unnecessary words.

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 tool's simplicity, the description covers all necessary context: permanence, confirmation, underlying method, and authentication. Output schema exists for return values.

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. Description adds minimal parameter info beyond schema (e.g., survey_id is numeric, confirm_destructive_action must be true). Not significantly more helpful.

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?

Description explicitly states 'Permanently delete a survey', providing a specific verb and resource. This clearly distinguishes it from sibling tools like delete_question or delete_group.

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?

Description clearly indicates when to use this tool (to delete a survey) and requires confirm_destructive_action=true, but does not explicitly mention when not to use or compare with 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 already indicate read-only, idempotent, non-destructive behavior. The description adds that the output is base64-encoded and references the specific RPC method. No contradictions.

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?

Extremely concise with two sentences, no wasted words. The first sentence clearly states the primary action and output format.

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 high schema coverage and existence of an output schema, the description covers the essential purpose and output format. It does not detail the base64 document structure, but that is acceptable with an 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 very high (91%), so the baseline is 3. The description does not provide additional meaning beyond the schema, merely stating the overall purpose.

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 tool exports responses as a base64-encoded document. It specifies the underlying RPC method and notes authentication details. However, it does not differentiate this from sibling tools like limesurvey_export_responses_by_token, leaving some ambiguity.

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 provides only authentication instructions, stating the agent should not provide a session key. There is no guidance on when to use this tool versus alternatives (e.g., export_responses_by_token, export_statistics) or any prerequisites like survey activation.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by noting the output is a base64-encoded document and calling a specific API method. This provides behavioral context beyond annotations, though it could mention potential size limits or encoding details.

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 extremely concise: two sentences covering the main action and one sentence about authentication. It front-loads the core purpose and avoids unnecessary details, efficiently using every word.

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 complexity (9 parameters, 3 required), the presence of an output schema, and strong annotations, the description is fairly complete. It covers the tool's purpose, output format, and authentication. However, it does not explain how to decode or use the base64 result, which is a minor gap for a complete understanding.

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 input schema already fully documents each parameter. The description adds no additional per-parameter meaning, making it a baseline scenario. It does not compensate beyond the schema's rich enum and description details.

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 it exports responses for selected tokens as a base64-encoded document. It accurately reflects the action implied by the tool name. However, it does not explicitly differentiate from similar sibling tools like limesurvey_export_responses or limesurvey_export_responses_by_token_to_file, relying on the name for distinction.

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 mentions authentication context (no session key) and the target LimeSurvey method, providing some usage guidance. However, it does not specify when to use this tool versus alternatives (e.g., when you have tokens vs. when you don't), nor provide any 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 indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds 'securely decode the result inside LIMESURVEY_EXPORT_DIR' but doesn't explain error handling, overwrite behavior, or side effects.

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 18-word sentence is efficient but lacks important details; it is more under-specified than concise.

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 an output schema, the description fails to explain the file format, the meaning of 'securely decode', or the effect of many optional parameters (e.g., completion_status, response_type). Incomplete for a tool with 11 parameters.

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 45%, but the description adds no extra meaning beyond parameter names and schema descriptions. It does not clarify how fields, heading_type, response_type, etc., affect output.

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 specific verb 'export' and resource 'responses for selected tokens', clearly distinguishing from siblings like limesurvey_export_responses (no file output) and limesurvey_export_responses_to_file (all responses).

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 explicit guidance on when to use this tool vs alternatives (e.g., limesurvey_export_responses_by_token for in-memory results), nor prerequisites or when-not-to-use scenarios.

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 indicate non-read-only, non-idempotent, non-destructive behavior. The description adds minimal detail: it writes to LIMESURVEY_EXPORT_DIR and decodes base64, but does not disclose file creation, overwrite handling, or permission requirements.

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 a single sentence, but it is poorly structured and vague. It includes an oddly specific detail about decoding base64 without explaining why, and fails to convey the core functionality clearly.

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 tool's complexity (13 parameters, 2 required), the description is severely incomplete. It does not explain return values, output format, or the purpose of key parameters, leaving the agent ill-equipped to use the tool correctly.

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 low (38%), and the description adds no parameter explanations. Many important parameters like document_type, response_type, and completion_status are left unexplained, forcing reliance on the sparse schema descriptions.

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 tool exports responses, but does not distinguish it from sibling export tools like export_responses or export_responses_by_token_to_file. The mention of decoding base64 inside a specific directory adds specificity but is secondary.

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 tool versus alternatives. Sibling tools have similar names and purposes, but the description lacks any comparative context or usage scenarios.

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 readOnly, idempotent, open-world, and non-destructive. Description adds value by specifying base64-encoded output and the underlying RemoteControl method, without contradicting 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?

Two sentences, each adding essential information. No redundant words. Key action 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?

Covers core functionality and authentication. Output schema exists, so return values are documented. Could mention decoding base64, but adequate for a read-only export 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 covers 100% of parameter descriptions. Description does not add further meaning beyond what schema provides, so 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?

Clearly states the action (export), resource (survey statistics), and output format (base64-encoded PDF, XLS, or HTML). Differentiates from sibling tools like export_responses or export_timeline.

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

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

Provides authentication context but no explicit guidance on when to use this tool versus alternatives. No when-not-to-use or prerequisite conditions mentioned.

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 indicate a write operation with no idempotency and no destruction. The description adds one behavioral detail: 'securely decode the result inside LIMESURVEY_EXPORT_DIR.' However, it does not disclose potential side effects like file overwriting (though the parameters overwrite and confirm_overwrite suggest this). The description adds some context beyond annotations but is still limited.

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 a single concise sentence that front-loads the core action. No redundant words. While it is efficient, it sacrifices necessary detail for brevity, which slightly lowers the score.

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 tool has 8 parameters, a write operation, an output schema, and annotations, the description is too minimal. It does not explain the output, the meaning of 'securely decode', or how parameters like overwrite interact. The description is not sufficient for an agent to use this tool reliably without additional schema parsing.

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 63%, meaning several parameters (e.g., group_ids) lack descriptions. The tool description does not mention any parameter meaning or usage, thus adding no value beyond the schema. With moderate coverage, the description should compensate but fails to do so.

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 'Export survey statistics and securely decode the result inside LIMESURVEY_EXPORT_DIR.' It uses a specific verb (Export) and resource (statistics to file), and the mention of a secured directory distinguishes it from sibling tools like limesurvey_export_statistics which likely returns data directly.

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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or contrast with similar tools (e.g., export_statistics for direct output). The agent is left to infer usage from the name 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?

Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. Description adds critical details: writes a file, returns path instead of base64, always fails with EXPORT_UNSUPPORTED without flag. 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?

Two sentences, front-loaded with primary action, includes critical caveats about experimental status and failure condition. No wasted words.

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?

Covers all essential aspects for an agent: purpose, experimental nature, requirements, failure scenario, and preferred alternatives. Output schema presumably handles return values, so no 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 description coverage is 100%, each parameter has a clear description. The tool description does not add new information beyond what's in the schema, so 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 clearly states the tool attempts to export a survey's structure as .lss and write it to a directory, returning a path. It distinguishes itself from other export tools by specifying it's for survey structure and is experimental.

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?

Explicit guidance: prefers property-based verification over this tool, states experimental requirement (LIMESURVEY_ENABLE_EXPERIMENTAL_METHODS=true), and notes that core RC2 lacks this method, so it only works with custom plugins. Clear when to use and 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 already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by naming the underlying API method (export_timeline) and clarifying authentication (using configured service account, not session key). This goes beyond annotations, though it doesn't detail response format or pagination.

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 extremely concise with two sentences. The first sentence states the core functionality, and the second provides essential authentication guidance. No unnecessary words.

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 excellent annotations (read-only, idempotent, non-destructive), full parameter schema coverage, and presence of an output schema, the description is sufficiently complete. The agent knows it is a safe read operation, what it returns, and how authentication works.

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?

Input schema has 100% description coverage, so parameters are well-documented. The description does not add extra semantics beyond what the schema provides. It mentions the aggregation periods (day/hour) and date range, but these are already part of the parameter descriptions.

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 specifies the verb (return), resource (response counts), and scope (by day or hour for a date range). The tool name 'export_timeline' matches its purpose, and it is distinct from siblings like export_responses which handle raw responses.

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 states it returns aggregated counts and mentions authentication, but it does not explicitly guide when to use this tool over alternatives such as export_responses or export_statistics. The context signals show many sibling tools, but no direct comparisons are provided.

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 idempotentHint=true; the description adds 'bounded client-side pagination', which is useful but minimal. No contradictions.

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 a single, front-loaded sentence that conveys the core purpose efficiently. No wasted words.

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 tool with output schema, the description covers basic functionality but does not clarify what the output contains (e.g., list of survey objects) or the behavior of client-side pagination.

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% (only query has a description). The description mentions 'by ID or title' but does not explain limit/offset semantics beyond the schema. With low schema coverage, more compensation was needed.

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 tool finds visible surveys by ID or title with pagination, distinguishing it from the sibling 'list_surveys' which lists all surveys without search.

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 for search (by ID or title) but does not explicitly state when to use this over alternatives like 'list_surveys' or when not to use it.

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 annotations providing only false hints, description adds behavioral context: it creates a validated theme, inherits a specific base theme, and targets specific LimeSurvey versions. It does not fully disclose all side effects (e.g., overwrite behavior, authentication needs) but provides more than the annotations alone.

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 a single, focused sentence of 18 words, effectively front-loading the purpose and key details without extraneous text. Every word 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?

While the output schema exists, the description does not explain how parameters influence the generated theme, nor does it describe the generation process or return value. Given the high parameter complexity, the description is incomplete for guiding an agent on tool 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 very low (13%), yet the tool description does not mention any of the 23 parameters. It fails to add meaning beyond the schema, leaving parameter roles and guidance entirely to the schema's sparse descriptions.

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?

Description clearly states the tool creates a validated GPL-2.0-or-later ZIP theme inheriting Bootstrap 5 vanilla for LimeSurvey 7 or 6. It specifies verb (create), resource (ZIP theme), and distinguishes from sibling tools like validate_survey_theme or assign_survey_theme.

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?

Description provides context on what the tool creates and for which versions, implying usage for theme generation. However, it does not explicitly state when to use this tool versus alternatives like limesurvey_validate_survey_theme or limesurvey_assign_survey_theme, nor provides when-not-to-use 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds that it calls a specific RC method and that authentication is via service account, providing extra context beyond 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?

Two short sentences, front-loaded with purpose. Every sentence adds value without verbosity.

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 tool's simplicity (one optional parameter, output schema present, annotations cover safety), the description provides sufficient detail including the underlying method and authentication. No gaps remain for the agent.

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 (response_format) with full schema coverage (100%). The schema already describes the parameter meaning. The tool description does not add additional semantics beyond the schema.

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

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

The description 'List global setting names available to a super administrator' uses a specific verb ('list') and clearly identifies the resource (global setting names). It distinguishes from the sibling tool 'limesurvey_get_site_settings' which likely retrieves setting values.

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 mentions the underlying RC method and states that authentication uses the configured service account and that no session key should be provided, which is a clear usage guideline. It does not explicitly compare to alternatives, but the purpose is distinct.

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, idempotentHint=true, destructiveHint=false, indicating safe behavior. The description adds that authentication uses the configured service account and calls a specific remote method, but does not disclose other behavioral traits like response size or rate limits.

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

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

The description consists of two concise sentences without any fluff. It is front-loaded with the primary action and efficiently includes authentication context.

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 that annotations cover safety, schema covers parameters, and an output schema exists, the description is largely complete. It lacks explicit usage guidance but is otherwise sufficient for a read-only 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% with descriptions for all three parameters. The description does not add additional parameter details beyond what the schema provides, so 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 title 'Get survey field map' and description 'Return the survey response field map' clearly state the specific verb and resource. The description also identifies the underlying LimeSurvey method. Among many siblings, this is uniquely for field map retrieval.

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 for retrieving the field map and mentions authentication details, but does not explicitly state when to use this tool vs alternatives or provide when-not-to-use 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 indicate read-only, open-world, idempotent, non-destructive behavior. Description adds valuable context: 'Authentication uses the configured service account; do not provide a session key' and references the underlying RemoteControl method.

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 concise sentences: first clearly states purpose, second adds critical authentication info. No redundant 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 an output schema present and annotations covering safety, the description sufficiently explains purpose and authentication. It could optionally mention the ability to filter properties via the 'properties' parameter, but schema covers that.

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 has 100% description coverage for all 4 parameters, so the description adds no new parameter-level meaning. 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?

Description states 'Read selected question-group properties' with a specific verb and resource. It clearly distinguishes this read operation from sibling tools like limesurvey_list_groups or limesurvey_set_group_properties.

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 explicit guidance on when to use this tool versus alternatives like limesurvey_list_groups or limesurvey_get_survey_properties. The description implies usage through purpose but lacks direct comparisons.

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 indicate read-only, idempotent, non-destructive. The description adds behavioral context: the default no-RemoteControl-call behavior, the probe mode details (list_surveys count, get_site_settings versionnumber), and the superadmin degradation. This exceeds annotation information and clarifies side effects.

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 well-structured with key purpose front-loaded, followed by specifics and parameter details. It is relatively lengthy but every sentence adds value. Slight redundancy could be trimmed, but overall efficient.

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 tool's complexity (config reporting with optional probing), the description covers all relevant aspects: default behavior, probe behavior, auth prerequisites, use case guidance, and data fields. With an output schema present, return value explanation is not needed. The description is fully self-contained for an AI agent.

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% for the single parameter probe_instance, but the description adds rich semantics: it controls an additional connectivity/auth probe, details what calls are made (list_surveys, get_site_settings), and notes the superadmin requirement and degradation. This goes far beyond the schema's brief 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?

The description clearly states the tool reports server-side configuration (server_version, instance_host, etc.) without RemoteControl calls by default, distinguishing it from sibling tools that fetch specific survey data or perform actions. The optional probe_instance parameter is explained, providing a specific resource and action.

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 advises calling this before relying on file export/import or theming tools, and explains when to use probe_instance (for connectivity/auth) and the superadmin requirement for get_site_settings. It implicitly differentiates from siblings by being a configuration-reporting tool.

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, idempotentHint, and destructiveHint. The description adds useful context: it calls a specific RemoteControl method and states that authentication uses a service account (no session key). No contradictions 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?

Two sentences, front-loaded with the core purpose. Every sentence is essential, no wasted words. Perfectly concise.

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 rich annotations, complete schema, and presence of an output schema, the description is sufficient. It could mention that the properties parameter filters output, but that is already in the schema. Overall complete for a read-only 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?

The input schema has 100% coverage with descriptions for all parameters. The description does not add extra meaning beyond what the schema provides, so baseline score 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 clearly states it reads localized survey properties, which distinguishes it from sibling tools like limesurvey_get_survey_properties (survey-wide properties) and limesurvey_get_survey_languages (list languages). The verb 'Read' and resource 'localized survey properties' are specific and 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 implies usage for reading language-specific properties, but it does not explicitly mention when not to use it (e.g., for survey-wide properties use limesurvey_get_survey_properties). However, the context is clear enough for an agent.

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 indicate readOnly, idempotent, non-destructive behavior. The description adds that authentication uses the configured service account, which is a small behavioral note, but does not disclose other traits like effects of missing participants or rate limits.

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

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

The description is three sentences, each serving a purpose: purpose, underlying method, and authentication note. No redundant 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?

Given the available annotations and schema, the description is sufficient for a simple read tool, but it lacks any mention of the return structure or format, which would be helpful since no output schema is provided in the definition.

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. The description hints at the query parameter (matching by token or tid) but does not elaborate on individual parameters 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 states the tool reads participant properties by token or token-table ID, using a specific verb and resource. It distinguishes itself from sibling tools like set_participant_properties (which writes) and list_participants (which lists all participants).

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 a read-only use case but does not explicitly state when to use this tool versus alternatives like set_participant_properties or list_participants. Lacks explicit 'when-not' or alternative suggestions.

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, idempotentHint=true, destructiveHint=false. The description adds value by specifying the underlying method (`get_question_properties`) and clarifying authentication behavior (no session key needed). No contradictions.

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

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

The description is two sentences: the first states the purpose, and the second provides implementation and authentication context. No unnecessary words, front-loaded, and every sentence adds value.

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 presence of an output schema (not shown but indicated), the description need not explain return values. It covers purpose, method, and a key authentication detail. With 4 parameters (1 required), it provides sufficient context for an agent to use the tool correctly, though it could mention that the tool supports both JSON and Markdown output formats.

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 does not add any additional meaning beyond what the schema provides for each parameter. It says 'Read selected question properties' but does not elaborate on the available parameters like `language`, `properties`, or `response_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 starts with 'Read selected question properties,' clearly stating the verb (Read), resource (question properties), and scope (selected). This distinguishes it from sibling tools like `limesurvey_set_question_properties` (write) and other getters for surveys, groups, etc.

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

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

The description includes a guideline to not provide a session key because authentication is handled by the service account. While it does not explicitly state when to use this tool over alternatives, the naming and sibling context make it obvious. A slight improvement could be adding a mention that this is for reading, not writing, questions.

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, destructiveHint=false, and idempotentHint=true. The description adds value by specifying the underlying API method and authentication details, confirming the read-only nature and providing operational context beyond 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?

The description is very concise with two substantive sentences plus a line for method and authentication. It is front-loaded with the purpose and contains no extraneous 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?

Given the presence of an output schema (not shown but indicated), rich annotations, and thorough input schema, the description provides enough context. It covers authentication and the underlying method, making it complete for a read-only 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?

Input schema coverage is 100% with descriptive parameter names and descriptions. The description's mention of 'selected quota properties' is generic but does not add new meaning beyond the schema. Baseline score of 3 is appropriate as the schema already sufficiently documents 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?

The description explicitly states 'Read selected quota properties,' which clearly identifies the action (read) and resource (quota properties). This distinguishes it from sibling tools like limesurvey_set_quota_properties (write) and limesurvey_delete_quota (delete).

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 provides context on when to use it (reading quota properties) and the underlying RemoteControl method. It also includes authentication guidance ('do not provide a session key'). However, it does not explicitly state when not to use it or compare with alternatives, though siblings imply the 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?

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds the specific LimeSurvey method call and authentication note, but no additional behavioral traits like pagination or limits.

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

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

Extremely concise: two sentences that front-load the purpose and follow with method and authentication details. No wasted words.

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 presence of output schema and annotations, the description is fairly complete. However, it could explicitly state that the tool returns a list of IDs for the token.

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 descriptions cover 100% of parameters, so the description adds no extra meaning. The baseline of 3 applies as per guidelines.

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 tool finds response IDs for a participant token, using a specific verb and resource. It distinguishes from siblings like export_responses (which exports full data) by focusing only on IDs.

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 tool versus alternatives. It only mentions authentication. There is no explicit context for selection among many 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?

Beyond annotations (readOnlyHint=false), the description discloses caching behavior and that authentication uses a configured service account. It adds the important behavioral guarantee of not exposing the session key. No contradictions 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?

Two concise sentences with no wasted words. The primary action is front-loaded, followed by the implementation detail and a critical usage note.

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 simple input schema (one optional param) and the presence of an output schema, the description adequately covers the tool's authentication mechanism, caching, and security aspect. No missing critical information.

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 (response_format) with 100% schema description coverage. The description adds no extra meaning beyond the schema's enum values and defaults, meeting the baseline but not exceeding it.

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 tool's function: opens and caches an authenticated RemoteControl session without exposing the key. It specifies the underlying method (get_session_key) and distinguishes it from data manipulation tools, establishing a specific verb-resource pair.

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?

Implies usage as a prerequisite for authenticated operations by mentioning caching and configured service account. Explicitly warns not to provide a session key. However, does not explicitly state when to use or name alternatives like release_session_key.

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, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds useful context about the RC method and the authentication note ('do not provide a session key'), which goes beyond the annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the purpose. Every sentence is necessary: one for the core function and one for the method and authentication note. No wasted words.

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?

The description is complete given the low complexity. Parameters are fully documented in the schema, annotations cover behavioral traits, and an output schema exists. The description provides the essential context: what it does, how it accesses the API, and a critical authentication constraint.

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%: both parameters ('setting_name' and 'response_format') have clear descriptions and enums. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.

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 tool's purpose: 'Read one global LimeSurvey setting.' This uses a specific verb ('Read') and resource ('global LimeSurvey setting'), and distinguishes it from siblings like 'limesurvey_get_available_site_settings' which lists all settings.

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 provides clear context by specifying the underlying RC method and authentication handling ('do not provide a session key'). However, it does not explicitly state when to use this tool versus alternatives (e.g., get_available_site_settings) or provide exclusion criteria.

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 indicate read-only and non-destructive behavior. The description adds that it calls a specific remote method and that authentication is handled automatically, providing context beyond 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?

Two sentences, with the purpose stated first, followed by a key usage note. Every word adds value; no 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?

Given the annotations and output schema, the description is sufficient. It explains what the tool does, how authentication works, and references the underlying method, leaving no critical 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?

The schema already covers all parameters with descriptions (100% coverage). The description does not add any extra meaning to the parameters themselves, maintaining the baseline score.

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 starts with 'Read response and participant summary counters', clearly stating the verb and resource. It succinctly distinguishes this tool from siblings that handle other aspects like exports or modifications.

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 explains that authentication uses the configured service account and warns not to provide a session key, guiding proper invocation. It does not explicitly list alternatives or when not to use it, but the purpose is clear enough.

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 and idempotentHint. The description adds context by specifying that both base and additional language codes are returned, which provides behavioral clarity beyond 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?

Single sentence of 12 words, front-loaded with verb and resource, no redundancy. Every word 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 simple read-only tool with one parameter and an output schema, the description fully defines the purpose. No additional information is needed.

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 adequate description for survey_id. The tool description does not add any additional parameter meaning beyond the schema, so baseline score of 3 is appropriate.

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