AI survey platform: create and publish surveys, collect responses, generate AI analysis reports.
Scored across 6 tools
Each tool targets a distinct action: creating surveys, publishing them, retrieving links, listing surveys, fetching responses, and generating AI reports. There is no meaningful overlap or ambiguity between tool purposes.
All tool names follow a consistent verb_noun snake_case pattern (create_survey, publish_survey, get_surveys, get_responses, etc.). This makes the API predictable and easy for an agent to navigate.
With six tools, the server is well-scoped for a survey-focused workflow. Each tool contributes to a clear stage in the lifecycle: creation, publishing, sharing, listing, response retrieval, and reporting.
The core create-publish-collect-report flow is covered, but update and delete survey operations are missing, and there is no way to fetch a single survey's details. These are notable lifecycle gaps even though agents can partially work around them.
Generate a professional survey using AI based on a research goal. Returns the survey ID and shareable link.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | Describe what you want to research. E.g. 'Customer satisfaction survey for our SaaS product after onboarding' | |
| lang | No | Language for the survey content. Defaults to 'en'. | |
| publish | No | Whether to immediately publish the survey after creation. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it creates a survey and returns ID/link, but does not disclose side effects, permissions, or safety profile. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose. No filler words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple schema and no output schema, the description explains return values (ID and link). Could mention AI generation aspect but overall complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra parameter meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a professional survey using AI' which is a specific verb-resource combination. It distinguishes from sibling tools like get_surveys (listing) and get_responses by implying creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new survey is needed, but does not explicitly state alternatives or when not to use. Still, context from siblings makes it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI analysis report for a survey's responses. Returns executive summary, key metrics, per-question insights, and action recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| survey_id | Yes | The ID of the survey to analyze. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral transparency. It describes outputs but does not disclose whether the tool is read-only, destructive, or requires specific authentication/authorization. Given the absence of annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the purpose, second lists outputs. Every sentence adds value, no redundancy. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers input and output. However, missing usage guidelines and behavioral transparency prevent a top score. Overall, it is complete enough given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter survey_id with description). The description adds context by linking the parameter to the survey's responses, but does not significantly extend beyond the schema's own description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an AI analysis report for a survey's responses, listing specific outputs (executive summary, key metrics, per-question insights, action recommendations). This distinguishes it from sibling tools which handle survey creation, listing, responses, or publishing, leaving no ambiguity about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies use after responses are collected, it lacks explicit guidance on when to use this tool versus alternatives, prerequisites (e.g., survey must have responses), or exclusions. Usage is implied but not directly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all responses submitted to a specific survey.
| Name | Required | Description | Default |
|---|---|---|---|
| survey_id | Yes | The ID of the survey to get responses for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states what the tool does, not behavioral traits such as data volume, authentication needs, or whether it returns paginated results. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extra words, efficient. However, slightly too brief for a tool with no annotations or output schema; more detail could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and only one parameter, the description should cover aspects like response format, ordering, or limitations. It does not, leaving the agent uncertain about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter survey_id, and the description provides no additional meaning beyond the schema. Baseline of 3 applies as the description does not add value on top of the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves all responses for a specific survey, using a specific verb and resource. It distinguishes from siblings like create_survey or get_surveys which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_surveys. Usage is implied by the name and description, but no when-not-to-use or comparative context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the shareable link for a published survey.
| Name | Required | Description | Default |
|---|---|---|---|
| survey_id | Yes | The ID of the survey. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description doesn't disclose what happens if the survey is not published or doesn't exist, nor does it mention permissions or side effects. For a retrieval tool, more context about error conditions would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, eight words, front-loaded with verb and object. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should mention the return format (e.g., URL string or object with link). Also lacks mention of prerequisite (survey must be published). Incomplete for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a minimal description for survey_id. The tool description adds no additional parameter semantics beyond the schema's 'The ID of the survey.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get') and the resource ('shareable link for a published survey'), distinguishing it from siblings like create_survey or publish_survey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The description implies the survey must be published, but doesn't state it directly or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all surveys belonging to the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by survey status. Defaults to 'all'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing behavioral traits such as pagination, rate limits, or whether results are limited. For a read-only tool, basic safety is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the tool's purpose with no wasted words. However, it could be slightly restructured to front-load core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 optional parameter, no output schema), the description is minimally complete. It fails to mention that the result is a list of surveys or typical response fields, but is adequate for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'status,' which has an enum and description. The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'list' and resource 'surveys' with scope 'belonging to the authenticated user.' It is clear but does not explicitly distinguish from sibling tools like 'create_survey' or 'get_responses.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to use 'get_surveys' instead of 'get_ai_report' or 'get_responses'). Missing context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a survey to make it accessible via its share link.
| Name | Required | Description | Default |
|---|---|---|---|
| survey_id | Yes | The ID of the survey to publish. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states that the survey becomes accessible via its share link, but does not mention side effects, permissions needed, or reversibility. Lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. The verb 'Publish' is the first word, immediately conveying the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core functionality. It could mention prerequisites (e.g., survey must exist) or what happens after publish, but overall it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes survey_id. The description adds no parameter-specific details beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (publish), the resource (survey), and the outcome (accessible via share link). It distinguishes well from siblings like create_survey and get_survey_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like create_survey or get_survey_link. The usage is implied (after creating a survey), but no when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_surveyget_ai_reportget_responsesget_survey_linkget_surveyspublish_surveyCreate, edit and publish surveys, then read results from your AI chat.
AI-native survey & form builder. Manage surveys, responses, analytics, and webhooks.
Create AI surveys with dynamic follow-up probing directly from your AI assistant.
Create and run surveys by chatting. Respondents just open a link — no AI, no account.
Add one secure layer between your agents and this server.
