AI survey platform: create and publish surveys, collect responses, generate AI analysis reports.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.5/5 across 6 of 6 tools scored.
Tools have distinct purposes, but create_survey and get_survey_link both involve shareable links, causing slight overlap. Otherwise clearly differentiated.
All tools follow a consistent verb_noun pattern using snake_case, e.g., create_survey, get_responses, publish_survey.
Six tools are well-scoped for a survey management server, covering creation, listing, publishing, and data retrieval without being excessive.
Core survey lifecycle is covered (create, publish, list, get responses, report), but missing update and delete operations are minor gaps.
create_surveyAInspectGenerate 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.
get_ai_reportAInspectGenerate 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_responsesBInspectGet 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_survey_linkBInspectGet 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.
get_surveysCInspectList 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_surveyAInspectPublish 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!