Tally MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear distinct purposes for core operations like create_form, get_form, list_forms, and manage_team, but there is significant overlap and confusion around deletion tools. The deprecated delete_form, bulk_delete_forms, and their preview/confirm counterparts create ambiguity, as agents might misselect between deprecated and active tools or misunderstand the multi-step workflow required for deletions.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., create_form, get_form, list_forms), which aids readability. However, there are minor deviations such as analyze_submissions (verb_noun) versus manage_team (verb_noun) and manage_workspace (verb_noun), which are consistent internally but slightly less so with others. The naming is generally predictable with only small inconsistencies.
Tool Count4/5
With 15 tools, the count is reasonable for managing Tally forms, submissions, and workspace settings, covering a broad scope. It is slightly high due to redundant deletion tools (deprecated and new workflow), but overall, it aligns well with the server's purpose without being overwhelming.
Completeness5/5
The tool set provides comprehensive coverage for Tally form management, including CRUD operations (create_form, get_form, modify_form, deletion workflow), submission handling (get_submissions, analyze_submissions), workspace and team management (manage_workspace, manage_team), and sharing (share_form). There are no obvious gaps; the deprecated tools are noted but replaced with a secure workflow, ensuring agents can handle all essential tasks.
Average 3.5/5 across 15 of 15 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under ISC License.
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 the full burden of behavioral disclosure. It mentions analysis and insights but fails to describe key traits such as whether this is a read-only operation, computational costs, rate limits, or output format. For a tool with no annotations, 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 a single, efficient sentence with no wasted words. It is front-loaded with the core purpose but could benefit from more detail given the lack of annotations and output schema. Overall, it is appropriately sized for its content.
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 (analysis function with no output schema) and lack of annotations, the description is incomplete. It does not explain what insights are provided, how results are returned, or behavioral aspects like performance. For a tool with no structured output or annotations, more context is needed to guide 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 100%, so the input schema fully documents both parameters (formId and analysisType with enum values). The description adds no additional meaning beyond what the schema provides, such as explaining the analysis types or formId usage. Baseline score of 3 is appropriate as the schema handles parameter documentation.
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's purpose as analyzing form submissions and providing insights, which is clear but vague. It specifies the resource (form submissions) and action (analyze) but lacks specificity about what 'insights' means or how it differs from sibling tools like get_submissions. No tautology or misleading elements are present.
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 does not mention sibling tools like get_submissions, which might retrieve raw data, or specify contexts where analysis is preferred over other operations. Usage is implied but not explicitly stated, leaving gaps for an AI agent.
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. 'Manage' implies mutation operations (inviting, removing, updating), but the description doesn't disclose critical behavioral traits: required permissions, whether changes are reversible, rate limits, or what happens on success/failure. For a tool with multiple mutation actions and no annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single phrase with zero wasted words. It's front-loaded with the core purpose, though this brevity comes at the cost of detail. Every word earns its place by conveying the essential scope, making it structurally efficient despite informational gaps.
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 (multiple mutation actions via 'action' enum) and lack of both annotations and output schema, the description is incomplete. It doesn't address behavioral risks, output expectations, or error conditions. For a tool that can invite, remove, or update permissions—potentially destructive operations—the description should provide more context to guide safe usage.
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 100%, so the schema already documents all three parameters with descriptions and enums. The description adds no additional meaning beyond the schema—it doesn't explain parameter relationships (e.g., 'email' is only needed for certain 'action' values) or provide context like format requirements. Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Manage team members and permissions' states the general purpose (verb+resource) but is vague about specific actions. It distinguishes from most siblings like 'create_form' or 'get_submissions' but doesn't clearly differentiate from 'manage_workspace' which might have overlapping functionality. The description lacks specificity about what 'manage' entails.
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, appropriate contexts, or exclusions. While the input schema's 'action' enum implies different use cases, the description itself offers no usage instructions, leaving the agent to infer from parameters 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 implies mutation ('manage') but doesn't disclose behavioral traits like permissions needed, whether actions are destructive, rate limits, or response formats. The description is too generic to inform the agent about critical operational aspects, such as which actions might modify data versus retrieve it.
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 a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. Every word earns its place, 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?
Given the tool's complexity (multiple actions, nested parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain the scope of actions, what 'settings' entails, or behavioral implications. For a tool with potential mutations and varied operations, more context is needed to guide 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 50%, with the 'action' parameter well-documented via enum and description, but 'settings' parameter lacks schema descriptions. The description adds no meaning beyond the schema; it doesn't explain what 'settings' includes or how actions interact with parameters. Baseline is 3 due to moderate schema coverage, but the description fails to compensate for gaps.
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 'Manage workspace settings and information' states a general purpose but is vague about specific actions. It mentions 'settings and information' but doesn't specify what management entails or differentiate from sibling tools like 'manage_team'. The verb 'manage' is broad and lacks specificity about the actual operations available.
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 for choosing between actions, or how it relates to sibling tools. For example, it doesn't clarify when to use 'manage_workspace' versus 'manage_team' or other workspace-related operations, leaving usage ambiguous.
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 'retrieve' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the 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 retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'details' are returned (e.g., form structure, metadata, or both), nor does it cover error cases or authentication requirements. Given the lack of structured data elsewhere, the description should provide more complete context.
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 input schema has 100% description coverage, with the single parameter 'formId' clearly documented. The description doesn't add any additional parameter context beyond what the schema provides, such as format examples or sourcing guidance. With complete schema coverage, the baseline score of 3 is appropriate.
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 ('Retrieve details') and resource ('specific Tally form'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'list_forms' or 'get_submissions', which would require more specific scope information to earn 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 'list_forms' (for multiple forms) or 'get_submissions' (for form responses). It also doesn't mention prerequisites or contextual constraints, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'retrieve' which implies a read operation, but doesn't cover aspects like whether it's safe (non-destructive), requires authentication, has rate limits, or what the return format looks like. For a tool with 4 parameters and no annotations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, 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?
Given the complexity of a retrieval tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain behavioral traits, usage context, or return values, leaving gaps that could hinder an AI agent's ability to use the tool effectively. More detail is needed to compensate for the lack of structured data.
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 input schema has 100% description coverage, so parameters like 'formId', 'limit', 'offset', and 'since' are well-documented in the schema. The description adds no additional semantic meaning beyond implying retrieval for a form, which is already covered by the tool name and schema. Baseline score of 3 is appropriate as the schema does the 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 verb 'retrieve' and the resource 'submissions for a specific form', making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'analyze_submissions' or 'list_forms', which might also involve submissions or forms, so it lacks 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. It doesn't mention siblings like 'analyze_submissions' for analysis or 'list_forms' for listing forms, nor does it specify prerequisites such as needing a form ID. This leaves the agent without context for 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. 'Modify' implies a mutation operation, but the description doesn't specify permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent 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 mutation tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It lacks behavioral context (e.g., side effects, permissions), usage guidance, and details on return values or error conditions, leaving the agent with incomplete information to use the 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?
Schema description coverage is 75%, with the 'fields' parameter lacking descriptions for its nested properties. The description adds no parameter-specific information beyond what the schema provides, such as format details or constraints. However, the schema does most of the work, so a baseline score of 3 is appropriate.
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 ('Modify') and resource ('an existing Tally form'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_form' (new forms) and 'delete_form' (removing forms), though it doesn't explicitly contrast with tools like 'get_form' or 'share_form'.
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 a form ID), when not to use it (e.g., for new forms), or how it differs from similar tools like 'create_form' or 'get_form' beyond the basic verb difference.
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 generates sharing links and embed codes, implying a read-only operation, but doesn't cover critical aspects like authentication requirements, rate limits, whether it modifies the form, or what the output looks like (e.g., URLs, HTML). This is a significant gap for a tool with potential sharing implications.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for the task, earning full marks for 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 (3 parameters, nested objects, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), doesn't fully explain parameters like 'customization', and provides no information on return values, 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 mentions 'sharing links and embed codes', which loosely relates to the 'shareType' parameter with its enum values (link, embed, etc.), adding some context beyond the schema. However, with 67% schema description coverage (only 'formId' and 'shareType' have descriptions), the 'customization' object and its sub-properties are undocumented in both schema and description, limiting added value.
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 ('Generate') and the resource ('sharing links and embed codes for a form'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'get_form' or 'modify_form' in terms of sharing-specific functionality, 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., form must exist), exclusions (e.g., not for editing), or comparisons to sibling tools like 'get_form' or 'modify_form', leaving 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. It states it 'lists all forms' but doesn't describe return format, pagination behavior, permission requirements, or rate limits. For a list operation with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple list operation and front-loads the essential information.
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 zero-parameter list tool without annotations or output schema, the description is minimally adequate but lacks important context. It doesn't explain what information is returned about each form, whether results are paginated, or how this differs from sibling tools, leaving the agent with incomplete understanding.
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 tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is appropriate for zero-parameter tools.
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 ('List') and resource ('forms in the workspace'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_form' or 'analyze_submissions', which would require specifying this lists ALL forms without filtering options.
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 'get_form' (for single form details) or 'analyze_submissions' (for form data analysis). It lacks any context about prerequisites, filtering limitations, or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs creation (a write operation) and handles automatic conversion of field definitions, which is useful behavioral context. However, it doesn't mention permissions needed, rate limits, error conditions, or what the response looks like (e.g., returns a form ID), leaving 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: the first states the core purpose and transformation, and the second clarifies the status default. It's front-loaded with the main action and avoids unnecessary details, though it could be slightly more structured (e.g., explicitly listing key parameters).
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?
Given the tool's complexity (4 parameters, mutation operation) and no annotations or output schema, the description is moderately complete. It covers the creation purpose and default behavior but lacks details on permissions, response format, error handling, or integration with sibling tools. For a creation tool with no structured safety hints, more context would be beneficial.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by noting the status field is optional and defaults to DRAFT, but doesn't provide additional semantics beyond what the schema specifies (e.g., it doesn't explain field interactions or constraints not in the schema). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new Tally form') and resource ('with specified fields and configuration'), distinguishing it from sibling tools like modify_form or delete_form. It also explains the transformation process ('converts simple field definitions into Tally's complex blocks-based structure automatically'), which adds unique value beyond just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the status field defaults to DRAFT, suggesting this is for initial form creation. However, it doesn't explicitly state when to use this tool versus alternatives like modify_form for updates, or provide guidance on prerequisites or constraints. The context is clear but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates the tool is deprecated and implies it may be less secure than alternatives, but doesn't detail behavioral traits like whether deletion is permanent, requires permissions, or has side effects. The deprecation warning adds some context but leaves key operational aspects 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 extremely concise and front-loaded with the critical deprecation warning, followed by clear alternative recommendations. Every sentence earns its place by conveying essential usage guidance without unnecessary details, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 deletion operation with no annotations and no output schema), the description is reasonably complete for a deprecated tool. It effectively communicates deprecation and alternatives, though it could better explain why it's deprecated (e.g., security risks) or behavioral implications. The lack of output schema is mitigated by the deprecation focus.
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 100%, with the single parameter 'formId' fully documented in the schema. The description adds no additional parameter information beyond what the schema provides, such as format examples or constraints. Baseline score of 3 is appropriate as the schema handles the 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 tool's purpose is for deletion ('delete') of a form resource, which is specific and matches the tool name. However, it doesn't distinguish from sibling tools like 'bulk_delete_forms' or 'preview_single_delete' beyond the deprecation warning, missing explicit differentiation in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when NOT to use this tool ('DEPRECATED') and names specific alternatives ('preview_single_delete' and 'confirm_single_delete'), including a rationale ('for secure deletion'). This clearly directs users away from this tool toward better options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 clearly states the destructive nature (bulk deletion), the human confirmation requirement, and the exact phrase needed. However, it doesn't mention rate limits, error handling, or what happens after confirmation, which are partially covered in the schema but could be highlighted in the description for clarity.
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 critical information (human confirmation requirement) in a single, efficient sentence. It avoids unnecessary details, but could be slightly more structured by separating the confirmation instruction from the automatic call warning for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, nested objects, no output schema, and no annotations), the description is reasonably complete. It covers the core purpose and usage constraints but lacks details on output behavior or error scenarios. Since there's no output schema, adding a hint about what to expect after confirmation would improve completeness.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema, mainly emphasizing the humanConfirmation requirement. It doesn't provide additional context for parameters like batchSize or options, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: to confirm bulk deletion after human confirmation. It specifies the exact phrase required ('DELETE ALL') and distinguishes it from automatic execution, making it highly specific and clear about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'DO NOT call this automatically - requires genuine human confirmation.' It also references a sibling tool (preview_bulk_delete) via the confirmationToken parameter, indicating when to use this tool versus alternatives like canceling or selecting individual items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively communicates critical behavioral traits: the tool is deprecated, requires a specific confirmation workflow, will reject calls without proper confirmation, and is kept for backward compatibility. However, it doesn't mention rate limits, authentication requirements, or error handling details.
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 concise. It front-loads the most critical information (deprecation status and alternative), then efficiently explains the workflow and current behavior. Every sentence earns its place with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, deprecated mutation tool with no annotations and no output schema, the description provides excellent contextual completeness regarding its current role and usage constraints. It adequately explains the workflow and limitations, though it could benefit from mentioning what happens when the tool is called correctly (e.g., what it returns).
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 100% schema description coverage, the baseline is 3. The description doesn't add any parameter-specific information beyond what's already documented in the schema. It mentions the confirmationToken requirement but doesn't provide additional context about parameter usage or interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a bulk deletion operation for forms, distinguishing it from sibling tools like delete_form (single deletion) and confirm_bulk_delete (confirmation step). The deprecation notice adds specificity about its current limited role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, detailed guidance on when to use this tool versus alternatives. It states it's deprecated, directs users to confirm_bulk_delete instead, explains the required confirmation workflow (preview_bulk_delete → confirm_bulk_delete), and clarifies that this tool will reject calls without proper confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes the tool's behavior: it's a deletion operation requiring explicit human confirmation, with specific input validation ('DELETE' to proceed, 'CANCEL' to abort). However, it doesn't mention potential side effects like irreversible deletion or error handling, leaving some behavioral aspects implicit.
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 front-loaded: a single sentence that clearly communicates the core requirement (human confirmation with exact phrase) and critical constraint (no automatic calls). Every word earns its place with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and no output schema, the description provides strong context about the confirmation requirement and safety constraints. However, it doesn't explain what happens after deletion (success/failure responses) or potential error conditions, leaving some contextual gaps despite the clear operational guidance.
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 100%, so the schema already documents all parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema (e.g., it doesn't explain the relationship between confirmationToken and formId). The baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: to confirm deletion of a single form after human confirmation. It specifies the exact action ('confirm single form deletion') and distinguishes it from sibling tools like 'bulk_delete_forms' and 'confirm_bulk_delete' by emphasizing 'single' deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidelines: it must only be called after human responds with the exact phrase 'DELETE', not automatically, and requires genuine human confirmation. This explicitly states when to use (after human confirmation) and when not to use (automatically), with no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively communicates this is a read-only preview operation (implied by 'SAFETY PREVIEW' and 'show exactly which forms would be deleted'), establishes it as a mandatory safety step before actual deletion, and specifies the human confirmation requirement. However, it doesn't mention potential rate limits, authentication needs, or what happens if no forms match the criteria.
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 concise with two sentences that each earn their place. The first sentence establishes the core purpose and safety context, while the second provides critical usage guidelines. There's zero wasted language, and the information is front-loaded with the most important safety warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preview tool with no annotations and no output schema, the description does an excellent job covering the essential context: purpose, safety role, and mandatory workflow. It clearly explains this is a preview step before actual deletion. The main gap is the lack of information about return values or output format, which would be helpful since there's no output schema.
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 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'form details' which relates to the 'showDetails' parameter, but doesn't provide additional semantic context. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('show exactly which forms would be deleted') and resources ('forms'), distinguishing it from siblings like 'bulk_delete_forms' (which performs the actual deletion) and 'preview_single_delete' (which previews single deletions). The description explicitly positions this as a safety preview before bulk deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'MANDATORY: Present form details to human and require explicit "DELETE ALL" confirmation before proceeding to confirm_bulk_delete.' It clearly states this is a preview step that must be completed before invoking the actual deletion tool, and names the alternative tool ('confirm_bulk_delete') that should be used next.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes the tool's behavior: it's a preview-only operation that requires human confirmation before any deletion occurs, implying it's non-destructive and interactive. However, it doesn't mention potential errors (e.g., invalid formId) or response format, leaving some gaps.
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 front-loaded with the core purpose in the first sentence, followed by a clear mandatory instruction. Both sentences are essential: the first defines the action, and the second specifies the required workflow. There is no redundant or verbose language, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (preview with human interaction), no annotations, and no output schema, the description is mostly complete. It covers the purpose, usage guidelines, and behavioral context (non-destructive preview with confirmation). However, it lacks details on error handling or the structure of the preview output, which could be useful for an 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 input schema has 100% description coverage, with 'formId' clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Preview a single form before deletion') and distinguishes it from siblings like 'confirm_single_delete' (which executes deletion) and 'preview_bulk_delete' (which handles multiple forms). It specifies the resource ('form') and the preparatory nature of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('before deletion') and provides a mandatory workflow: present details to a human and require explicit 'DELETE' confirmation before proceeding to 'confirm_single_delete'. It clearly distinguishes this from the execution step, offering direct alternatives and prerequisites.
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:

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

Score Badge

Copy to your README.md:

[![tally-mcp MCP server](https://glama.ai/mcp/servers/learnwithcc/tally-mcp/badges/score.svg)](https://glama.ai/mcp/servers/learnwithcc/tally-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/learnwithcc/tally-mcp'

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