Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
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 11 of 11 tools scored. Lowest: 2.7/5.
There is clear overlap between several tools: create_ask is explicitly a backward-compatible alias for create_form, making them nearly indistinguishable. get_my_form_responses vs get_responses and watch_my_form_responses vs watch_ask also serve similar purposes with only subtle differences (form ownership vs generic ask). The creation session tools (join_creation_session, update_creation_session) and creation tools (create_form, create_feedback_form) have moderately clear boundaries but could confuse agents about when to use session tools vs direct creation.
The naming mostly follows a verb_noun pattern (create_form, list_asks, watch_ask) and many share a consistent 'my_' prefix for owned resources. However, the aliasing (create_ask), the distinction between 'ask' and 'form' terminology, and create_feedback_form vs create_form introduce inconsistency in domain vocabulary. Watch_ask vs watch_my_form_responses and get_responses vs get_my_form_responses use parallel but not fully consistent naming.
11 tools is a reasonable count for a form lifecycle server. However, three tools are essentially redundant aliases or near-duplicates (create_ask, get_responses, and possibly watch_ask given HTTP bridge equivalents), which could be consolidated. The count is not excessive or too thin, but the effective surface is smaller than 11 distinct tools.
The server covers creation (create_form, create_feedback_form), listing (list_asks, list_my_forms), reading responses (get_responses, get_my_form_responses), and real-time watching (watch_ask, watch_my_form_responses). However, there is no tool for updating or deleting existing forms, and no tool for closing/archiving a form. The creation-session tools are present but lack a corresponding read/view for drafts. The domain is form lifecycle, and update/delete operations for published forms are notable gaps.
create_askCreate Superforms AskCInspectCreate a voice-first Superforms answer link for human input. Backward-compatible alias for create_form.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| title | No | ||
| prompt | No | Plain-English ask or request. Use only when explicit questions are not already known. | |
| context | No | Private context for smart follow-ups. Summarize relevant non-sensitive host-conversation context and append any extra context the creator provides. Never shown to respondents. | |
| questions | No | Explicit questions to ask the respondent. Use this whenever questions already exist; preserve them exactly. | |
| persistent | No | ||
| followUpMode | No | For exactly one question, set this only after asking the creator "Want smart follow-up questions?" Use deep_dive for yes or none for no. For multiple questions, use none unless explicitly requested. | |
| responseMode | No | ||
| responseLimit | No | Use "one" for a form intended for one named person/client. Use "multiple" for forms, surveys, feedback, customers, users, and public/embedded links. | |
| questionContext | No | ||
| creationSessionUrl | No | ||
| max_total_questions | No | Optional compatibility setting. Omit for adaptive one-question smart follow-ups. | |
| max_followups_per_question | No | Optional compatibility setting. Omit for adaptive one-question smart follow-ups. |
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 'voice-first' and 'answer link' as behavioral traits, but does not disclose what happens upon creation, any side effects, permission requirements, or the return format. The alias reference hints at behavior but does not explain it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is not verbose and every word adds some intent. However, it is arguably under-specified rather than appropriately concise, which is a minor flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested question objects, no output schema, no annotations), the description is grossly incomplete. It does not explain return values, side effects, or how the parameters interact, and the alias reference is not elaborated. This is inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 54%, with several parameters (goal, title, persistent, responseMode, questionContext, creationSessionUrl) lacking descriptions. The tool description itself adds no parameter-level semantics beyond 'voice-first', which loosely relates to responseMode. It fails to compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'voice-first Superforms answer link for human input', and explicitly identifies itself as a backward-compatible alias for create_form. This distinguishes it from the other sibling tools like create_feedback_form, though the phrase 'human input' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it is an alias for create_form, which implies similar usage, but provides no explicit guidance on when to use this tool versus the alternatives (e.g., create_form or create_feedback_form). There are no stated prerequisites, exclusions, or context for when this alias should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_feedback_formCreate Feedback FormBInspectPublish a voice-first feedback, cancellation, feature request, survey, or research form immediately after creator confirmation, with optional smart follow-ups.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| title | No | ||
| prompt | No | Plain-English ask or request. Use only when explicit questions are not already known. | |
| context | No | Private context for smart follow-ups. Summarize relevant non-sensitive host-conversation context and append any extra context the creator provides. Never shown to respondents. | |
| questions | No | Explicit questions to ask the respondent. Use this whenever questions already exist; preserve them exactly. | |
| persistent | No | ||
| followUpMode | No | For exactly one question, set this only after asking the creator "Want smart follow-up questions?" Use deep_dive for yes or none for no. For multiple questions, use none unless explicitly requested. | |
| responseMode | No | ||
| responseLimit | No | Use "one" for a form intended for one named person/client. Use "multiple" for forms, surveys, feedback, customers, users, and public/embedded links. | |
| questionContext | No | ||
| creationSessionUrl | No | ||
| max_total_questions | No | Optional compatibility setting. Omit for adaptive one-question smart follow-ups. | |
| max_followups_per_question | No | Optional compatibility setting. Omit for adaptive one-question smart follow-ups. |
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 does mention 'immediately after creator confirmation' and 'optional smart follow-ups', which are useful behavioral traits. However, it doesn't disclose side effects (persistent forms, publishing implications), auth/permission needs, or whether publication is reversible. Partial coverage of a tool that clearly has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the core purpose and key characteristics. It's appropriately concise without waste. Could arguably be front-loaded more clearly but overall it's tight.
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?
This is a complex tool: 13 parameters, nested objects, conditional enums (followUpMode depends on creator response), and no output schema. The description covers none of the setup flow, prerequisites, or conditional logic that many schema descriptions hint at (e.g., followUpMode requires asking the creator first). For a tool this multi-faceted with no annotations and no output schema, the description is notably under-specified.
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 54%, so the description needs to compensate significantly. The description mentions key concepts (voice-first, smart follow-ups, creator confirmation) but doesn't explain most of the 13 parameters (goal, title, persistent, responseMode, creationSessionUrl, questionContext have no schema descriptions). The high parameter count with only 54% coverage means much is left undocumented. However, several schema-level descriptions (followUpMode, responseLimit, questions) are quite detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it publishes voice-first feedback/cancellation/feature request/survey/research forms after creator confirmation. It's specific about verb (publish), resource (feedback forms), and timing (after creator confirmation). However, it doesn't differentiate from sibling create_form or create_ask — the relation to those tools is unclear.
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 ('immediately after creator confirmation') but offers no explicit when-to-use vs alternatives. With siblings like create_form and create_ask existing, there's no guidance on when to pick this over them. The schema descriptions help somewhat but not in the description text itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_formCreate Superforms FormBInspectPublish a voice-first form link immediately after creator confirmation, collect human answers, and pipe responses back to the agent.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| title | No | ||
| prompt | No | Plain-English ask or request. Use only when explicit questions are not already known. | |
| context | No | Private context for smart follow-ups. Summarize relevant non-sensitive host-conversation context and append any extra context the creator provides. Never shown to respondents. | |
| questions | No | Explicit questions to ask the respondent. Use this whenever questions already exist; preserve them exactly. | |
| persistent | No | ||
| followUpMode | No | For exactly one question, set this only after asking the creator "Want smart follow-up questions?" Use deep_dive for yes or none for no. For multiple questions, use none unless explicitly requested. | |
| responseMode | No | ||
| responseLimit | No | Use "one" for a form intended for one named person/client. Use "multiple" for forms, surveys, feedback, customers, users, and public/embedded links. | |
| questionContext | No | ||
| creationSessionUrl | No | ||
| max_total_questions | No | Optional compatibility setting. Omit for adaptive one-question smart follow-ups. | |
| max_followups_per_question | No | Optional compatibility setting. Omit for adaptive one-question smart follow-ups. |
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. The description is a single sentence that conveys the high-level lifecycle ('publish', 'collect', 'pipe back') but omits material behaviors: that confirmation from the creator is a prerequisite step, that the form is voice-first by default, potential side effects like creating a persistent shareable link, or any rate limits/authorization requirements. With 13 parameters and no annotations, this level of transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose well. However, for a 13-parameter tool with complex workflow semantics and no annotations, the brevity works against it — it fails to earn its space by covering the important operational details that an agent needs to invoke it correctly. Being too short is a deficiency, not a virtue, in this context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no annotations, no output schema, nested objects, and 46% of parameters undocumented in the schema, the description is far too thin. The confirmation-workflow prerequisite, the voice-first nature, the 'smart follow-ups' semantics present in the schema, and the distinction from similar creation tools are all absent. The single sentence provides only the most surface-level picture and is inadequate for correct invocation of this complex 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 54%, and 6 of 13 parameters lack descriptions (goal, title, persistent, responseMode, questionContext, creationSessionUrl). The description itself adds NO parameter-level information whatsoever — it is entirely about the tool's overall function. The schema does have useful guidance for key params (questions, followUpMode, responseLimit), but the uncovered parameters remain undocumented by both schema and description, and the description doesn't compensate for those gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Publish a voice-first form link') and the resource ('form'), and its outcome ('collect human answers, pipe responses back to agent'). It distinguishes itself as a 'voice-first' form creation tool among siblings, and implies the confirmation/approval workflow. However, it does not explicitly contrast with sibling tools like create_ask or create_feedback_form, leaving some ambiguity about when each is preferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on the workflow: 'immediately after creator confirmation' and 'pipe responses back to the agent'. This gives the agent a sense of when the tool is intended to be invoked. However, it gives no explicit when-not-to-use guidance or named alternatives (e.g., when to prefer create_ask or create_feedback_form instead), leaving the agent to infer boundaries among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_form_responsesGet My Form ResponsesARead persisted raw responses for a form owned by the connected Superforms account. No per-form agent token is required.
| Name | Required | Description | Default |
|---|---|---|---|
| askId | Yes | ||
| since | No | Optional ISO timestamp cursor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by noting that no per-form agent token is required, which is a behavioral permission detail not covered by annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the purpose in the first sentence. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers purpose and a key auth detail but lacks information about return format, error handling, or behavior of the 'since' parameter. It is adequate but not fully 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?
The description does not add any meaning beyond the input schema. Schema description coverage is only 50% (only 'since' has a description). The tool description does not explain 'askId' or 'since' further, missing an opportunity to compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'persisted raw responses' for a form owned by the connected account. It distinguishes from siblings like 'get_responses' by implying ownership scope. The phrase 'No per-form agent token is required' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the tool is for forms owned by the connected Superforms account and that no per-form agent token is needed. However, it does not explicitly compare to alternative sibling tools like 'get_responses' or state when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_responsesGet Superforms ResponsesCFetch persisted raw responses for a Superforms ask. This is the MCP equivalent of the HTTP bridge answers endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| askId | Yes | ||
| since | No | ||
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds minimal context: 'persisted raw responses' clarifies data freshness, but no additional behavioral details like pagination or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are appropriately sized and front-loaded with the core action. However, underspecification reduces effectiveness; a bit more detail would improve value without being overly verbose.
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 three parameters (one optional) and no output schema or parameter descriptions, the description should provide richer context about usage, return format, and parameter roles. It lacks these essentials, leaving the agent underinformed.
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 0% (no comments on parameters), and the description does not explain any of the three parameters (askId, since, agentToken). The description must compensate for missing schema info but fails entirely.
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 fetches persistent raw responses for a Superforms ask, and provides an analogy to the HTTP bridge endpoint. It distinguishes from siblings like 'get_my_form_responses' enough to hint at different resources (ask vs form).
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 such as 'get_my_form_responses' or 'list_asks'. No exclusions or context provided for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
join_creation_sessionJoin Superforms Creation SessionBInspectJoin a Superforms homepage creation handoff session before creating the real form. Pass agentName with the client name, such as Codex, Claude Code, Claude, ChatGPT, or Cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| agentName | No | ||
| creationSessionUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions joining a handoff session but does not describe side effects, permissions, or state changes. Insufficient detail for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. No wasted words, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and low schema coverage, the description fails to provide enough context. Missing return value, prerequisites, or how to obtain creationSessionUrl.
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?
Description adds value for agentName by explaining its purpose and giving examples. However, creationSessionUrl is not described, and schema coverage is 0%, so overall contribution is partial.
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 action 'Join' and the resource 'creation session'. It distinguishes from sibling tools like create_form by focusing on joining an existing session rather than creating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context: use before creating a real form, and how to specify agentName. However, it lacks explicit when-not-to-use or comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_asksList Superforms AsksAList recent asks for a provided private agent token.
| Name | Required | Description | Default |
|---|---|---|---|
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint (false). The description adds the behavioral hint 'recent' (time constraint) and clarifies the token requirement, adding value beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. It is appropriately concise, though it could benefit from a bit more detail on the time scope ('recent').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only one parameter. The description does not clarify what 'recent' means, what the response includes, or any additional context about the token. For a simple tool, this lack of detail leaves gaps in agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'agentToken' has 0% schema description coverage. The tool description mentions 'provided private agent token' but does not explain the parameter's format, origin, or expected values, leaving the agent to infer meaning from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'asks' (Superforms Asks), and specifies it is 'for a provided private agent token,' which distinguishes it from sibling tools like list_my_forms.
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 an agent token is available, but does not explicitly state when to use this tool versus alternatives (e.g., list_my_forms for personal forms, create_ask for creation). No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_formsList My SuperformsAList forms owned by the connected Superforms account, including response counts and latest response timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds context by stating that it returns response counts and latest timestamps, which is beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded with the main action, and contains no redundant words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description fully explains what the tool does and what information it returns. It is complete for an agent to understand its usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so description does not need to provide semantic meaning. Baseline 4 is appropriate as there is no need to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'list', the resource 'forms owned by the connected Superforms account', and includes specific details about what is returned (response counts and latest timestamps). This clearly distinguishes it from siblings like 'list_asks' and 'get_my_form_responses'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing owned forms with response stats, but it does not explicitly state when to use this tool versus alternatives such as 'list_asks' or 'get_my_form_responses'. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_creation_sessionUpdate Superforms DraftAInspectUpdate a homepage creation handoff draft with the current form title, questions, and settings before the user clicks Set live.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| title | No | ||
| context | No | Private smart-follow-up context. Summarize relevant non-sensitive host-conversation context and append any extra context the creator provides. Never shown to respondents. | |
| questions | No | Current draft questions to show in the live form preview. | |
| followUpMode | No | ||
| responseMode | No | ||
| responseLimit | No | Use one for a named person/client. Use multiple for feedback forms, surveys, customers, users, and public links. | |
| creationSessionUrl | Yes | ||
| max_total_questions | No | Use 20 for deep-dive interviews. | |
| max_followups_per_question | No | Use 0 by default. Use 1 only when smart follow-ups are explicitly requested. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'update', which implies mutation, but does not explain side effects (e.g., whether it overwrites existing data, if permissions are needed, or what happens if the session is already live). It also doesn't describe the response or errors. The timing caveat 'before Set live' is helpful but insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb 'Update'. It is concise with no filler, making the core purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 10 parameters, 3 enums, and no output schema. The description only covers the basic update action and timing. It omits behavioral details (return value, error conditions, prerequisites like session state), making it incomplete for an agent to fully understand consequences and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. The description mentions 'form title, questions, and settings', which maps to title, questions, and settings-related params (followUpMode, responseMode, etc.), providing some context beyond the raw schema. However, it does not describe all parameters like 'goal', 'creationSessionUrl', or the enum details, leaving gaps that the schema's own descriptions partially fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Update'), the resource ('homepage creation handoff draft'), and the specific context ('before the user clicks Set live'). It distinguishes itself from sibling creation tools (create_form, create_ask) by focusing on updating an existing draft rather than creating new ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: updating the draft before the user clicks 'Set live'. It implies the tool is for pre-publication edits, but it doesn't explicitly mention alternatives or exclusions (e.g., when not to use it). This is clear context without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_askWatch Superforms AskAReturn as soon as an individual answer is saved, including answers received while an agent was reconnecting and while the form remains in progress. Use since for durable per-answer catch-up; the HTTP bridge also exposes an SSE stream endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| askId | No | ||
| since | No | ISO timestamp cursor from the last response the agent processed. | |
| timeoutMs | No | Maximum wait in milliseconds, capped at 120000. | |
| agentToken | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish this as a safe, read-only, idempotent operation. The description adds behavioral detail beyond annotations by explaining it returns answers collected during agent reconnection and while the form is still in progress. It also clarifies the durable catch-up semantics of 'since'. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value. The first sentence gives the core behavior, the second provides parameter guidance and an alternative endpoint. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior and the meaning of 'since', but it does not explain timeout behavior, error cases, or what exactly is returned beyond 'an individual answer'. Given the tool's complexity and the lack of an output schema, it is reasonably complete but leaves some operational details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 40%, so the description should compensate. It does add meaning to 'since' ('durable per-answer catch-up'), but it does not explain 'url', 'askId', or 'agentToken' beyond what their names imply. The description partially bridges the gap but not fully, making this a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action ('Return as soon as an individual answer is saved') and adds specific context about reconnection and in-progress forms. However, it does not explicitly differentiate from the sibling tool 'watch_my_form_responses' by noting that this is for asks, not form responses, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some usage guidance: 'Use since for durable per-answer catch-up' and mentions the SSE stream endpoint as an alternative. But it does not explicitly state when to use this tool over get_responses or watch_my_form_responses, leaving the usage context partially implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_my_form_responsesWatch My Form ResponsesAReturn any existing individual answers immediately, or wait briefly until the respondent saves their next answer, even while the form remains in progress.
| Name | Required | Description | Default |
|---|---|---|---|
| askId | Yes | ||
| since | No | Optional ISO timestamp cursor. | |
| timeoutMs | No | Maximum wait in milliseconds, capped at 120000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail: it returns existing answers immediately, waits for the next save, and works even while the form is in progress. This goes beyond the annotation hints and clarifies the true watch semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary behavior ('Return any existing individual answers immediately') and packs the waiting behavior and in-progress nuance without fluff. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and strong annotations, the description sufficiently outlines the core behavior and fits with the schema's timeoutMs and since parameters. It doesn't cover timeout edge cases or response format, but that is not critical given the structured schema and safety annotations.
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 67% with only askId lacking a description. The description does not explicitly explain askId, but the overall behavior implies it refers to the form/ask identifier. It adds no direct parameter-level meaning beyond what the schema already provides, so the baseline score 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 what the tool does: returns existing individual answers immediately or waits for the next answer from the respondent, even on an in-progress form. This distinguishes it from simple retrieval tools like get_my_form_responses or get_responses by emphasizing the watch/wait behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it (when you want existing answers immediately or need to wait for the next one) but does not explicitly state when not to use it or name alternative tools. The sibling names imply alternatives, but the description itself lacks an explicit contrast.
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!
