LimeSurvey MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct, targeting specific resources like surveys, groups, participants, questions, quotas, responses, and files with precise actions. However, some potential overlap exists between 'add_response' and 'save_responses', and 'add_participants' and 'import_cpdb_participants', which could cause minor confusion for agents.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'activate_survey', 'add_group', 'delete_participants', 'export_responses', 'import_survey', and 'set_question_properties'. This uniformity makes the tool set predictable and easy to navigate.
Tool Count3/5
With 35 tools, the count is high but may be justified for a comprehensive survey management system like LimeSurvey, covering CRUD operations for multiple entities. However, it borders on being heavy and could overwhelm agents, suggesting some consolidation might improve usability.
Completeness5/5
The tool set provides extensive coverage for LimeSurvey's domain, including full lifecycle management for surveys, groups, questions, participants, responses, quotas, and files. It supports activation, import/export, property setting, and deletion, with no obvious gaps for core workflows.
Average 2.9/5 across 35 of 35 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Set' implies a mutation/write operation, but the description doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens to existing properties not mentioned, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: a purpose statement and a parameter list. It's front-loaded with the main purpose. However, the parameter descriptions are overly minimal and could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested object parameter), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what properties can be set, their format, the effect of the operation, or what to expect in return. This leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the two parameters ('gid' and 'properties') but provides minimal semantic information: 'gid: The group ID' is tautological, and 'properties: The properties to set' doesn't explain what properties are available, their format, or constraints. This adds little value beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set LimeSurvey group properties' which provides a clear verb ('Set') and resource ('group properties'), but it doesn't specify what properties can be set or distinguish this from similar sibling tools like 'set_survey_properties' or 'set_question_properties'. The purpose is understandable but lacks specificity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With sibling tools like 'add_group', 'delete_group', and other property-setting tools, the description doesn't indicate whether this is for updating existing groups versus creating new ones, or when to choose this over other property-setting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Set' implying a mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, potential side effects, or error handling. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences, front-loaded with the purpose. However, the 'Args' section is redundant with the schema and could be omitted for better conciseness, as it doesn't add value beyond what's already in the structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on what 'language properties' are, how to format them, what the tool returns, and any behavioral context, making it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters 'lid' and 'properties' but adds minimal meaning: 'lid' is described as 'The language ID' and 'properties' as 'The properties to set', which is tautological. No details on format, constraints, or examples are provided, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Set LimeSurvey language properties' which provides a clear verb ('Set') and resource ('language properties'), but it's vague about what 'language properties' specifically entails. It doesn't distinguish from sibling tools like 'set_group_properties' or 'set_survey_properties' beyond the resource name, lacking specificity about what makes language properties unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as whether it's for configuring survey languages or system-wide settings. With many sibling tools for setting properties on different resources, the absence of usage guidelines leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a 'Set' operation, implying mutation, but doesn't describe permissions required, whether changes are reversible, error conditions, or what happens to unspecified properties. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by a parameter list. It avoids unnecessary words, but the parameter explanations are overly terse and could benefit from more detail without sacrificing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested objects, no annotations, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on behavioral traits, parameter constraints, and expected outcomes, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters 'id' and 'properties' with brief explanations, but 'properties' is described only as 'The properties to set', which is tautological and doesn't clarify what properties are valid, their format, or examples. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Set LimeSurvey quota properties', which provides a clear verb ('Set') and resource ('quota properties'), but it's somewhat vague about what 'properties' specifically means. It doesn't differentiate from sibling tools like 'set_group_properties' or 'set_survey_properties' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing quota ID), exclusions, or compare it to related tools like 'add_quota' or 'delete_quota' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a creation operation ('Add'), implying mutation, but doesn't disclose behavioral traits like required permissions, whether the survey becomes active immediately, error handling, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, but the 'Args' section is redundant since it repeats what's in the schema without adding semantics. It could be more efficient by integrating parameter details into the main sentence or omitting the redundant listing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage (0%), the description is incomplete. It doesn't explain what 'survey_data' entails, what happens after creation, or how this differs from sibling tools. For a mutation tool with nested parameters, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only names the parameter ('survey_data') without explaining what it should contain, such as required fields, structure, or examples. This adds minimal value beyond the schema, leaving the parameter largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('a new LimeSurvey survey'), making the purpose understandable. However, it doesn't differentiate from similar tools like 'import_survey' or 'copy_survey', which could also create surveys through different methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'import_survey' or 'copy_survey'. The description lacks context about prerequisites, such as whether authentication or specific permissions are needed, or what distinguishes this from other survey creation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a mutation tool ('Set'), but doesn't describe what happens on success/failure, whether properties are merged or replaced, permission requirements, or side effects. This leaves significant gaps for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, but the parameter listing is redundant with the schema and adds little value. While not verbose, it could be more efficiently structured by focusing on contextual guidance rather than repeating parameter names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It lacks details on behavior, parameter meanings, error handling, and relationships to sibling tools, leaving the agent with inadequate context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the three parameters but provides no semantic context beyond their names—no explanation of what a 'participant token' is, what format 'properties' should take, or what 'sid' represents. This adds minimal value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'LimeSurvey participant properties', making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'set_group_properties' or 'set_survey_properties', but the resource specificity is adequate for basic clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'add_participants' or 'update_response', nor does it mention prerequisites such as needing an active survey or valid token. Usage context is implied only by the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Add' implies a write/mutation operation, the description doesn't address permissions needed, whether the operation is idempotent, what happens on failure, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief (two sentences plus parameter list) and front-loaded with the core purpose. However, the parameter descriptions are overly terse ('The group data' adds almost no value), slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters (including a nested object), 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks essential information about parameter details, behavioral traits, error handling, and return values, making it inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the two parameters ('sid' and 'group_data') but provides minimal semantic information: 'sid' is described as 'The survey ID' (basic) and 'group_data' as 'The group data' (tautological). This doesn't explain what constitutes valid group data, required fields, or format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a group') and target resource ('to a LimeSurvey survey'), providing specific verb+resource information. However, it doesn't differentiate from sibling tools like 'import_group' or 'set_group_properties', which handle related group operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'import_group' or 'set_group_properties'. It mentions no prerequisites, constraints, or typical use cases, leaving the agent without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions adding participants but fails to disclose critical behavioral traits: whether this requires specific permissions, if it's idempotent, what happens on duplicate entries, rate limits, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: a clear purpose statement and a parameter list. It's front-loaded with the main action, though the parameter explanations are brief and could be more informative without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 2 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks details on permissions, error handling, return values, and how it differs from sibling tools, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the parameters ('sid' and 'participant_data') but adds minimal meaning beyond the schema—only clarifying that 'sid' is 'The survey ID' and 'participant_data' is 'The participant data', without explaining data format, structure, or examples. This insufficiently compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add participants') and the resource ('to a LimeSurvey survey'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'invite_participants' or 'import_cpdb_participants' that also involve participants, missing full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'invite_participants' or 'import_cpdb_participants', nor does it mention prerequisites such as whether the survey must be active. It only states what the tool does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds responses but doesn't clarify whether this is a write operation, what permissions are required, if it's idempotent, how errors are handled, or what the output looks like. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with three sentences: a clear purpose statement followed by parameter explanations. It's front-loaded with the main action, and each sentence adds necessary information without redundancy. However, the parameter explanations are overly brief given the low schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with two parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is insufficient. It doesn't address behavioral aspects like side effects, error handling, or return values, nor does it provide adequate parameter semantics or usage guidance, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It lists the two parameters (sid, responses) and briefly describes them ('The survey ID', 'The responses to add'), but this adds minimal semantic value beyond the schema's property names. It doesn't explain the format of responses, what constitutes a valid survey ID, or provide examples, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add multiple responses') and target resource ('to a LimeSurvey survey'), making the purpose immediately understandable. It distinguishes from the sibling 'add_response' by specifying 'multiple responses' rather than a single response, though it doesn't explicitly contrast with other survey-related tools like 'save_responses' or 'update_response'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'add_response' (for single responses), 'save_responses', or 'update_response'. It mentions the required parameters but offers no context about prerequisites, error conditions, or typical use cases, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Set' implying a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error handling, or side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. The two-sentence structure with an 'Args:' section is efficient. However, the second sentence is redundant with the schema, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (mutation tool with nested objects, 0% schema coverage, no output schema, no annotations), the description is incomplete. It lacks details on parameter semantics, behavioral context, and usage guidelines. The agent would struggle to use this tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters (qid, properties) but adds minimal semantics: 'The question ID' and 'The properties to set' are tautological. It doesn't explain what properties are available, their formats, or constraints. With 2 parameters and nested objects, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('LimeSurvey question properties'), making the purpose understandable. It distinguishes this tool from other property-setting siblings like set_group_properties and set_survey_properties by specifying 'question' properties. However, it doesn't fully differentiate from update_response which might also modify question-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing question ID), exclusions, or compare it to similar tools like update_response or set_survey_properties. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Set' implies a mutation operation but doesn't specify permissions required, whether changes are reversible, rate limits, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: a purpose statement followed by parameter listings. It's front-loaded with the core functionality. However, the parameter section is overly terse and could benefit from more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with nested object parameter), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter details, or usage context, making it inadequate for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists both parameters ('sid' and 'properties') but provides minimal semantics: 'sid' is described as 'The survey ID' (basic), and 'properties' as 'The properties to set' (vague). It doesn't explain what properties are available, their formats, or constraints, failing to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('LimeSurvey survey properties'), making the purpose specific and understandable. It distinguishes this from other tools like 'set_group_properties' or 'set_question_properties' by specifying it's for survey-level properties. However, it doesn't explicitly differentiate from 'set_participant_properties' or 'set_quota_properties' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing survey), exclusions, or compare it to sibling tools like 'add_survey' (for creation) or 'update_response' (for response data). The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Import' implies a write operation, the description doesn't specify whether this creates new records, updates existing ones, requires specific permissions, has side effects, or provides any feedback about the import process. This is inadequate for a tool that likely modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear purpose statement followed by parameter explanations. However, the parameter section uses minimal explanations that don't add substantial value. The structure is front-loaded but could be more efficient in conveying necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (including a nested object), 0% schema description coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, what happens during import, error conditions, or how it differs from similar sibling tools. The description leaves too many open questions for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds some value by explaining that 'sid' is 'The survey ID' and 'attributes' are 'The attributes to filter participants.' However, this is minimal - it doesn't clarify what format 'attributes' should take, what filtering logic is applied, or what happens when no participants match the filter. The description compensates partially but not fully for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import participants') and source ('from the central participant database'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'add_participants' or 'import_group', which handle similar participant/survey data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'add_participants', 'import_survey', and 'import_group' available, there's no indication of what makes this tool distinct or when it should be preferred over other participant management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action ('activate tokens') but doesn't explain what 'activate' means operationally (e.g., enabling tokens for distribution, setting status), whether it's idempotent, requires specific permissions, or has side effects. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: a purpose statement and parameter documentation. It's front-loaded with the core functionality, though the parameter section could be more integrated. No wasted words, but structure is basic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation operation with no annotations, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on what 'activate' entails, expected outcomes, error conditions, or how it interacts with sibling tools, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics: it mentions 'sid' as 'The survey ID' which matches the schema's title 'Sid' and type 'integer'. With 0% schema description coverage, this provides basic clarification but doesn't compensate fully for the coverage gap (e.g., no format, range, or source guidance).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('activate tokens') and target resource ('for a LimeSurvey survey'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'add_participants' or 'invite_participants' which might involve token management, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., survey must exist), exclusions, or relationships to other tools like 'add_participants' that might handle token creation or activation differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool adds a language but doesn't mention whether this requires specific permissions, what happens if the language already exists, whether the change is reversible, or any rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one stating the purpose and another listing parameters. It's front-loaded with the core functionality. While efficient, the parameter section could be more structured (e.g., bullet points) for slightly better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers basic purpose and parameters but lacks crucial context: behavioral traits (e.g., permissions, idempotency), error conditions, and what the tool returns. Given the complexity and missing structured data, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description lists the two parameters (sid and language) and briefly explains their purpose ('survey ID' and 'language code'), adding some semantic value beyond the bare schema. However, it doesn't specify format details (e.g., language code standards like 'en' or 'fr-FR') or validation rules, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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') and target resource ('to a LimeSurvey survey'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'delete_language' or 'set_language_properties', which would require explicit comparison to achieve a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'delete_language' or 'set_language_properties'. It mentions the survey ID and language code as parameters but offers no context about prerequisites, constraints, or appropriate scenarios for language addition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds a quota but doesn't explain what that entails—whether it's a creation operation, if it requires specific permissions, what happens on success/failure, or if there are rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear first sentence stating the purpose, followed by a brief parameter list. There's no wasted text, and it's front-loaded with the main action. However, the parameter descriptions are very minimal, which slightly reduces efficiency, but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no annotations, no output schema), the description is incomplete. It doesn't explain what a 'quota' is in LimeSurvey context, how the addition affects the survey, what the return value might be, or error conditions. For a mutation tool with undocumented parameters, this leaves too many unknowns for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the parameters ('sid' and 'quota_data') and provides minimal context ('survey ID' and 'quota data'), but doesn't elaborate on formats, constraints, or examples (e.g., what 'quota_data' should contain). This adds some meaning beyond the bare schema but falls short of fully documenting the parameters, especially the complex 'quota_data' object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a quota') and the target resource ('to a LimeSurvey survey'), providing specific verb+resource pairing. However, it doesn't distinguish this tool from other quota-related tools like 'delete_quota' or 'set_quota_properties' among the sibling tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'set_quota_properties' or 'delete_quota'. The description lacks context about prerequisites, such as whether the survey must be active or if quotas are limited, and doesn't mention any exclusions or specific scenarios for its application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds a response but doesn't clarify if this is a write operation, what permissions are needed, whether it's idempotent, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by parameter explanations. It avoids unnecessary fluff, though the parameter section could be more integrated into the flow rather than listed separately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of adding survey responses (a write operation with nested objects), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on error handling, response format, and operational constraints, making it inadequate for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists both parameters ('sid' and 'response') and provides basic semantic context (survey ID and response to add). However, with 0% schema description coverage, it doesn't fully compensate by explaining the structure of the response object or format constraints, leaving the agent to infer details from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a response') and the target resource ('to a LimeSurvey survey'), which is specific and unambiguous. However, it doesn't distinguish this tool from its sibling 'add_responses' (plural), which could cause confusion about when to use one versus the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'add_responses' (plural), 'save_responses', or 'update_response'. It also doesn't mention prerequisites such as whether the survey needs to be active or if authentication is required, leaving the agent with insufficient context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive operation, it doesn't specify whether this action is reversible, what permissions are required, how errors are handled, or what happens to associated data. For a destructive tool, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and another listing parameters. It's front-loaded with the main action, though the parameter listing could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive tool with no annotations, no output schema, and low parameter semantics coverage, the description is incomplete. It lacks critical context like side effects, return values, error conditions, or usage examples, which are essential for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema by naming the parameters ('sid' as survey ID and 'tokens' as participant tokens). However, with 0% schema description coverage, it doesn't fully compensate—it doesn't explain token format, sid constraints, or array handling. Baseline 3 is appropriate given the schema does the structural heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete participants') and the resource ('from a LimeSurvey survey'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_survey' or 'delete_response' beyond mentioning participants specifically, which is why it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'delete_response' or 'delete_survey', nor does it mention prerequisites or constraints. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Delete') but doesn't mention critical details like whether this is reversible, what permissions are required, if it affects related data, or what the response looks like. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and another documenting the parameter. It's front-loaded with the main action, though the parameter documentation could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like irreversibility, error conditions, or response format, leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that documents the single parameter (qid) with a brief explanation ('The question ID'), but schema description coverage is 0%. This adds minimal value beyond the schema's type information, meeting the baseline for a tool with one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('a question from a LimeSurvey survey'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like delete_group or delete_survey, which target different resources in the same system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like delete_survey or delete_group, nor are any prerequisites or exclusions mentioned. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is 'Delete', implying a destructive mutation, but doesn't specify whether deletion is permanent, requires specific permissions, affects associated data (e.g., survey responses), or has side effects. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by parameter documentation. Both sentences are necessary and efficient, with no redundant information. However, the lack of usage or behavioral context slightly undermines completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and low schema coverage, the description is insufficient. It doesn't cover critical aspects like success/error responses, idempotency, or system impacts. The agent lacks enough information to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It documents the single parameter 'id' as 'The quota ID', which adds basic semantics beyond the schema's type information. However, it doesn't explain where to find the ID, its format constraints, or validation rules, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'LimeSurvey quota', making the purpose unambiguous. It distinguishes itself from siblings like 'delete_survey' or 'delete_group' by specifying the quota resource type. However, it doesn't explicitly differentiate from 'delete_participants' or 'delete_response' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., whether the quota must be inactive), consequences of deletion, or relationships with other tools like 'set_quota_properties' or 'add_quota'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool deletes a response, implying a destructive mutation, but does not disclose critical behavioral traits such as permissions required, whether deletion is permanent or reversible, error handling, or side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured with a clear purpose statement followed by parameter listings. It avoids unnecessary words, though the parameter section could be more integrated. Overall, it is efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive mutation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects, error conditions, or return values, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description lists the parameters (sid, response_id) and their roles, adding basic semantics beyond the schema. However, it does not explain data formats, constraints, or examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a response from a LimeSurvey survey'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'delete_survey' or 'delete_participants', which target different resources, so it lacks specific sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention if this is for single-response deletion versus batch operations or how it differs from tools like 'delete_participants' or 'update_response'. This leaves usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Delete' implies a destructive operation, it doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects on related data. This is inadequate for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences: one stating the purpose and another documenting the parameter. Every word earns its place, and the structure is front-loaded with the core action first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive deletion tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion, whether confirmation is needed, error conditions, or how this differs from other deletion tools. The context signals indicate high complexity (destructive operation) that requires more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description documents the single parameter 'sid' and explains it's 'The survey ID,' which adds meaning beyond the schema's minimal title 'Sid.' With 0% schema description coverage, this compensates adequately for the one parameter, though it could provide more context about valid ID formats or sources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a LimeSurvey survey'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling deletion tools like delete_group or delete_response, which would require specifying what makes survey deletion unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With multiple deletion tools available (delete_survey, delete_group, delete_language, etc.), there's no indication of which resource type this applies to or any prerequisites for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool exports data but doesn't mention whether this is a read-only operation, whether it requires specific permissions, what the output format looks like (e.g., file download vs. inline data), or any rate limits. For a data export tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, and there's no redundant information. The parameter list is appropriately formatted for readability. It could be slightly more concise by integrating parameter details into the main sentence, but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a 4-parameter export tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'responses' includes, doesn't describe the output (e.g., file content or structure), and doesn't mention error conditions or limitations. For a tool that presumably generates downloadable data, this leaves critical contextual gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all 4 parameters with brief explanations, adding meaning beyond the schema which has 0% description coverage. It clarifies that 'sid' is a survey ID, 'file_format' includes options like csv/json, 'language' uses codes like en/es, and 'heading_type' has specific values. However, it doesn't provide examples, format details, or constraints for parameters like 'heading_type' values beyond 'code, full, abbreviated'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export responses') and resource ('from a LimeSurvey survey'), making the purpose immediately understandable. It distinguishes itself from other survey-related tools like 'export_statistics' or 'export_timeline' by focusing specifically on response data. However, it doesn't explicitly differentiate from potential sibling tools that might also export data in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., whether the survey must be active), doesn't specify what 'responses' includes (e.g., completed vs. partial responses), and doesn't compare with similar tools like 'export_statistics' or 'download_files'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Export statistics' which implies a read operation, but doesn't clarify permissions needed, rate limits, whether it's destructive, or what the output format looks like. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear purpose statement followed by parameter explanations. The structure is front-loaded with the main function first. The only minor improvement would be integrating parameter details more seamlessly rather than as a separate 'Args:' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what 'statistics' includes, what the output looks like, whether there are size limits, authentication requirements, or error conditions. The agent would struggle to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides basic parameter explanations ('sid: The survey ID', 'document_type: The document type (pdf, xls, html)'), which adds meaning beyond the schema's 0% description coverage. However, it doesn't explain parameter constraints, format requirements, or provide examples, leaving room for improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export statistics') and the resource ('for a LimeSurvey survey'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'export_responses' or 'export_timeline', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'export_responses' or 'export_timeline'. The description only states what it does, not when it's appropriate or what distinguishes it from similar export functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Import') which implies a write operation, but doesn't clarify permissions needed, whether it's idempotent, what happens on failure, or the expected output format. This leaves significant gaps for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with a clear opening sentence followed by parameter explanations. Each sentence adds value, though the parameter section could be more integrated with the main description rather than presented as a separate 'Args' block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a 'group' in LimeSurvey, what the import process entails, what format the group file should be in beyond base64 encoding, or what the tool returns upon success/failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists all three parameters with brief explanations, adding meaning beyond the 0% schema description coverage. It clarifies that 'group_file' should be base64 encoded and 'group_name' is for the imported group. However, it doesn't explain what a 'group' is in LimeSurvey context or provide format details for the file content, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import a group') and the target resource ('to a LimeSurvey survey'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from similar sibling tools like 'import_survey' or 'import_question', which would require more specific context about what a 'group' represents in LimeSurvey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing survey), exclusions, or how it differs from sibling tools like 'add_group' or 'import_survey', leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Import' implies a write operation, the description doesn't specify permissions needed, whether this creates or overwrites existing questions, error conditions, or what happens after import. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by parameter explanations. The structure is logical and front-loaded with the main functionality. However, the parameter explanations could be more concise (e.g., 'base64 encoded' could be integrated into the main sentence).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after import, what format the question file should be in beyond 'base64 encoded', error handling, or success indicators. The agent lacks sufficient context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides parameter names and brief explanations (e.g., 'The survey ID', 'The group ID', 'The question file content'), which adds meaning beyond the schema's 0% description coverage. However, it doesn't explain format expectations (e.g., what 'base64 encoded' means for the file, valid ID ranges) or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import a question') and target resource ('to a LimeSurvey survey'), providing specific verb+resource pairing. However, it doesn't distinguish this tool from similar sibling tools like 'import_group' or 'import_survey' beyond mentioning 'question' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, constraints, or when other import tools might be more appropriate. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose whether this is a create or update operation, what happens on failure, if it's idempotent, or any rate limits or permissions required, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by parameter explanations. It avoids unnecessary fluff, though the parameter section could be more integrated into the flow rather than a separate list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and low schema coverage, the description is insufficient. It doesn't cover behavioral aspects like side effects, error handling, or return values, making it incomplete for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists both parameters ('sid' and 'data') and briefly explains their roles, but with 0% schema description coverage, it doesn't fully compensate. It lacks details on 'data' structure (e.g., format, required fields) or 'sid' validation, leaving the agent with incomplete information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'save' and resource 'responses for a LimeSurvey survey', making the purpose unambiguous. It distinguishes from siblings like 'add_response' or 'update_response' by specifying 'save' rather than create or modify, though it doesn't explicitly differentiate from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_response', 'update_response', or 'add_responses'. The description lacks context about prerequisites, such as whether the survey must be active or if authentication is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description fails to mention critical aspects: whether this requires specific permissions, if changes are reversible, what happens to existing data not in the 'response' parameter, or error conditions (e.g., invalid IDs). For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated in the first sentence. The parameter list is formatted clearly but includes minimal explanations. While efficient, the lack of behavioral or usage details means some sentences don't earn their place fully, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with nested objects), no annotations, and no output schema, the description is incomplete. It covers basic parameters but omits critical context: behavioral traits (e.g., side effects, error handling), usage guidelines, and output expectations. For a tool that modifies survey data, this leaves too many gaps for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters (sid, response_id, response) with brief explanations, adding basic meaning beyond the schema's titles. However, it doesn't clarify the structure of 'response' (a nested object) or provide examples, leaving significant ambiguity. This partial compensation justifies a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a response in a LimeSurvey survey'), making the purpose immediately understandable. It distinguishes from siblings like 'add_response' (creation) and 'delete_response' (deletion) by focusing on modification. However, it doesn't explicitly mention what aspects of the response can be updated, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing response), exclusions (e.g., not for creating new responses), or contextual cues (e.g., use after 'add_response' for corrections). With siblings like 'add_response' and 'delete_response' available, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Upload' implies a write/mutation operation, it doesn't specify authentication requirements, rate limits, file size restrictions, supported formats, or what happens on success/failure. The description mentions base64 encoding for file_content but provides no further behavioral context about the upload process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The parameter documentation is structured clearly with bullet-like formatting. While efficient, the 'Args:' section could be more integrated with the main description rather than appearing as an afterthought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after upload (success indicators, returned file ID, error conditions), file constraints, or how this integrates with LimeSurvey's file management system. The lack of output information is particularly problematic for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters with brief explanations, adding meaning beyond the bare schema. However, it doesn't provide format details (e.g., sid format, file_name extensions), constraints, or examples. The base64 encoding note for file_content is helpful but insufficient for full parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload a file') and target resource ('to a LimeSurvey survey'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'download_files' or 'import_survey' that also handle files, leaving room for ambiguity about when to choose this specific upload method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With sibling tools like 'download_files', 'import_survey', and 'import_question' that also handle file operations, there's no indication of when this upload method is appropriate versus other import/export mechanisms. No context about prerequisites or exclusions is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Activate') which implies a state change, but doesn't describe what activation entails (e.g., makes survey available to participants, irreversible change, requires specific permissions), nor does it mention response format or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with two sentences: one stating the purpose and another documenting the parameter. The structure is front-loaded with the main action first. However, the second sentence could be integrated more smoothly rather than as a separate 'Args:' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'activate' means operationally, what state changes occur, what permissions are needed, or what the tool returns. The context signals show minimal parameter complexity, but the behavioral aspects are underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides the parameter name 'sid' and clarifies it's 'The survey ID', adding semantic meaning beyond the schema's basic type (integer). With 0% schema description coverage and only 1 parameter, this minimal addition is sufficient to reach a baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate') and resource ('a LimeSurvey survey'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'add_survey' or 'set_survey_properties', which would require more specific context about what 'activate' means in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'add_survey' or 'set_survey_properties'. There's no mention of prerequisites (e.g., survey must exist in draft state), timing considerations, or what happens after activation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('download files') but lacks details on permissions required, file formats, download limits, error handling, or what happens when 'file_id' is None (e.g., if it returns a zip or list). This is a significant gap for a tool with potential data transfer implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. It avoids unnecessary fluff, though the 'Args:' section could be slightly more integrated into the flow, but overall it's efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file download operation), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, rate limits, or return values (e.g., file content or error messages), leaving the agent with insufficient information for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'sid' is the survey ID and 'file_id' is the file ID, clarifying their roles, and notes that if 'file_id' is None, it downloads all files—a crucial semantic detail not in the schema. This compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('download') and resource ('files from a LimeSurvey survey'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'upload_file' or 'export_responses', which might handle similar file operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'upload_file' or 'export_responses'. It mentions the parameters but offers no context about prerequisites, timing, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action ('Copy') but doesn't disclose what gets copied (structure, settings, data?), permissions required, whether it's idempotent, or what the new survey's initial state is (e.g., active/inactive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear purpose statement followed by brief parameter explanations. Every sentence earns its place with no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'copy' entails (full/partial duplication), success/failure behaviors, return values, or error conditions—critical gaps for safe tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for both parameters: 'sid' is explained as 'source survey ID' and 'new_name' as 'name for the new survey'. With 0% schema description coverage, this compensates well by clarifying parameter roles beyond just their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Copy') and resource ('LimeSurvey survey'), making the purpose immediately understandable. It distinguishes itself from siblings like 'add_survey' (create new) and 'import_survey' (import from external source), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention prerequisites (e.g., needing an existing survey), exclusions, or compare with similar tools like 'import_survey' or 'add_survey' for different creation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the action 'Delete' without disclosing behavioral traits like whether this is irreversible, requires specific permissions, affects related data, or returns confirmation. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a brief purpose statement followed by parameter explanations, using minimal words without redundancy. Every sentence adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete—it lacks crucial information about consequences, permissions, return values, or error handling. Given the complexity and risk, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents both parameters ('sid' as survey ID and 'gid' as group ID) with clear semantics, compensating fully for the schema gap. It doesn't provide format details but gives essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a group from a LimeSurvey survey'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_survey' or 'delete_question' beyond mentioning 'group' specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'delete_survey' or 'delete_question', nor any prerequisites or warnings about irreversible deletion. The description only states what it does 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a deletion, implying it's destructive, but doesn't specify if it's reversible, requires specific permissions, affects survey functionality, or has side effects (e.g., removing associated data). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a clear purpose statement followed by a bullet-point list of parameters. Every sentence earns its place, with no redundant or verbose language, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens upon deletion (e.g., success/failure responses, error conditions), behavioral constraints, or integration with sibling tools, leaving critical gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents both parameters ('sid' and 'language') with brief explanations, adding meaning beyond the input schema which has 0% description coverage. This compensates well for the schema's lack of descriptions, though it doesn't provide format details (e.g., language code standards).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a language from a LimeSurvey survey'), making the purpose immediately understandable. It distinguishes itself from siblings like 'delete_survey' or 'delete_group' by specifying the language resource, though it doesn't explicitly contrast with them in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., whether the survey must be active), exclusions (e.g., cannot delete the last language), or comparisons to siblings like 'add_language' or 'set_language_properties'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It mentions 'import' which implies creation/mutation, but doesn't disclose permissions needed, whether it overwrites existing surveys, error handling, or output format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, though the formatting with 'Args:' could be slightly more polished for front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter mutation tool with no annotations and no output schema, the description covers the basic operation and parameter meanings adequately. However, it lacks details on behavioral aspects like what happens on success/failure or the returned data structure, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for both parameters: 'survey_file' is clarified as 'base64 encoded' content (not just a file path), and 'survey_name' as 'the name for the imported survey'. With 0% schema description coverage, this significantly compensates by explaining what each parameter represents beyond their titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and resource ('a LimeSurvey survey'), making the purpose immediately understandable. It distinguishes from siblings like 'add_survey' or 'copy_survey' by specifying import from a file, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'add_survey' or 'import_group'. The description only states what it does, not when it's appropriate or what prerequisites might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action 'invite' but doesn't clarify whether this sends emails, requires survey activation, has rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this leaves significant behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured with a clear purpose statement followed by parameter explanations. Every sentence earns its place, with no redundant information. The two-sentence format is front-loaded and efficiently communicates essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't address prerequisites (e.g., survey must be active), side effects, error conditions, or return values. The parameter explanations help but don't compensate for the missing behavioral context needed for reliable tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'sid' as survey ID and 'tokens' as participant tokens with the clarification that 'None' means invite all participants. This adds meaningful context beyond the bare schema types, though it doesn't specify token format or survey ID validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'invite' and resource 'participants to a LimeSurvey survey', making the purpose immediately understandable. It distinguishes itself from siblings like 'add_participants' by focusing on invitation rather than creation. However, it doesn't explicitly contrast with other invitation-related tools that might exist in the broader context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'add_participants' or 'set_participant_properties'. It mentions that tokens can be 'None' to invite all participants, which is a usage detail but doesn't address broader context or prerequisites for successful invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an export operation but doesn't clarify whether this creates files, returns data directly, requires specific permissions, or has rate limits. The mention of 'aggregation submission counts' hints at data transformation, but behavioral aspects like output format, side effects, or authentication requirements remain unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and economical. The first sentence states the core purpose, followed by a clean parameter documentation section. Every sentence earns its place, with no redundant or verbose language. The information is front-loaded with the most important context first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description does an adequate job covering parameter semantics but leaves significant gaps. It doesn't explain what the export produces (file download? JSON data?), authentication requirements, error conditions, or practical usage examples. The purpose is clear but operational context is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting all 4 parameters with clear semantic meaning. It explains 'sid' as survey ID, 'period' as granularity level with allowed values, and both date parameters with format examples. The description adds significant value beyond the bare schema, though it doesn't explain parameter interactions or default behaviors for 'end_datetime'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export timeline') and target resource ('for a LimeSurvey survey'), making the purpose immediately understandable. It distinguishes itself from siblings like 'export_responses' or 'export_statistics' by focusing specifically on timeline data with aggregation. However, it doesn't explicitly contrast with these similar export tools, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'export_responses' or 'export_statistics'. It mentions aggregation of submission counts but doesn't explain why one would choose timeline export over other export methods. There are no prerequisites, exclusions, or contextual recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![limesurvey-mcp MCP server](https://glama.ai/mcp/servers/edgarrmondragon/limesurvey-mcp/badges/card.svg)](https://glama.ai/mcp/servers/edgarrmondragon/limesurvey-mcp)

Score Badge

Copy to your README.md:

[![limesurvey-mcp MCP server](https://glama.ai/mcp/servers/edgarrmondragon/limesurvey-mcp/badges/score.svg)](https://glama.ai/mcp/servers/edgarrmondragon/limesurvey-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/edgarrmondragon/limesurvey-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server