Tally MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as create_tally_form for form creation and get_form_submissions for data retrieval, but some overlap exists, like update_form_settings and update_form_status, which could be confused as both modify form properties, though their descriptions clarify specific focuses.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as create_tally_form, get_form_submissions, and update_tally_webhook, with no deviations in style or convention, making them predictable and readable.
Tool Count3/5
With 23 tools, the count is borderline high for a form management server, as it includes many specialized tools like validate_multiple_choice_logic, which might be excessive for core operations, but it's not extreme and covers a broad scope.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for Tally forms, including creation, retrieval, updating, and deletion of forms, submissions, and webhooks, along with advanced features like conditional logic and validation, leaving no obvious gaps.
Average 3/5 across 23 of 23 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, if there are rate limits, or what happens upon success/failure. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Delete a webhook') that directly states the action. It is front-loaded and wastes no words, making it easy to parse quickly. Every word earns its place by conveying the core purpose without redundancy.
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 deletion operation, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success confirmation, error messages), behavioral aspects like side effects, or usage context. This leaves the agent with insufficient information to use the tool effectively beyond basic parameter input.
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 clear parameter descriptions for 'formId' and 'webhookId'. The tool description adds no additional parameter semantics beyond what's in the schema. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no param info in the description.
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 'Delete a webhook' clearly states the verb (delete) and resource (webhook), making the basic purpose understandable. However, it lacks specificity about what kind of webhook (e.g., Tally webhook) and doesn't differentiate from sibling tools like 'delete_tally_form' or 'delete_form_submission', which also perform deletion operations on different resources.
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 (e.g., needing an existing webhook), exclusions, or related tools like 'get_tally_webhooks' for listing webhooks or 'create_tally_webhook' for creating them, leaving the agent to infer usage context.
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. 'Configure' implies a mutation/write operation, but the description doesn't specify whether this requires special permissions, if changes are reversible, potential side effects (e.g., email sending), or rate limits. It lacks critical context for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or fluff. It's appropriately sized for a configuration tool with well-documented parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after configuration (e.g., success response, error conditions), whether notifications are sent immediately, or how this interacts with other form settings. The 100% schema coverage helps with inputs, but behavioral and output context is missing.
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 (formId, ownerNotifications, respondentNotifications) and their nested properties. The description mentions 'form owner and respondents' which aligns with the two notification objects, but adds no meaningful semantic details beyond what the schema provides. 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.
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: 'Configure email notifications for form owner and respondents.' It specifies the verb ('configure'), resource ('email notifications'), and target audience ('form owner and respondents'). However, it doesn't explicitly differentiate this tool from sibling tools like 'update_form_settings' or 'update_tally_form' that might also modify form configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing form), exclusions, or comparisons to sibling tools like 'update_form_settings' that might handle broader form modifications. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions 'validation' and 'form flow control,' it doesn't specify what happens during creation (e.g., whether it's idempotent, what permissions are needed, if it modifies existing structures, or what errors might occur). For a creation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's front-loaded with the main action and resource. However, it could be slightly more structured by explicitly separating purpose from constraints or outcomes.
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 creating conditional logic (involving multiple parameters with specific structures like arrays and enums) and no annotations or output schema, the description is incomplete. It doesn't explain what 'properly structured' means, what validation entails, or what the tool returns upon success/failure, leaving the agent with insufficient context for reliable 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 schema already documents all 4 parameters thoroughly with descriptions and enums. The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters or providing examples. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and resource ('conditional logic blocks') with additional context about validation and form flow control. However, it doesn't explicitly differentiate from sibling tools like 'validate_form_logic_flow' or 'validate_multiple_choice_logic' which might handle similar validation aspects.
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_conditional_logic_templates' (which might provide templates) or 'validate_form_logic_flow' (which might validate existing logic). There's no mention of prerequisites, dependencies, or specific use cases that would help an agent choose this tool over others.
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 this is a creation tool, implying a write operation, but doesn't cover permissions, side effects, error handling, or what happens upon success. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, potential errors, or behavioral nuances like idempotency. The high schema coverage helps with inputs, but overall context for safe and effective use is lacking.
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 fully documents the two parameters (title and description). The description adds no additional parameter information beyond what's in the schema, such as format constraints or examples. This meets the baseline for high schema coverage but doesn't provide extra 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 ('Create') and resource ('new Tally form'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_tally_form' or 'get_tally_form_templates' beyond the basic verb, 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, when not to use it, or how it relates to siblings like 'update_tally_form' or 'get_tally_form_templates', leaving the agent with minimal context for decision-making.
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 'Create a new webhook' but fails to explain what this entails—such as whether it requires specific permissions, what happens on success/failure, if it's idempotent, or how webhooks function (e.g., real-time notifications). For a mutation tool with zero annotation coverage, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information, though it could benefit from additional context.
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 creating a webhook (a mutation operation with no annotations or output schema), the description is incomplete. It lacks details on behavioral aspects like permissions, error handling, or what the webhook does, and doesn't explain return values or side effects. For a tool that modifies system state, this minimal description fails to provide sufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage with clear descriptions for 'formId', 'url', and 'events'. Since the schema fully documents the parameters, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to, as the schema handles the semantics adequately.
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 ('Create') and resource ('new webhook for a form'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'delete_tally_webhook' or 'get_tally_webhooks' by focusing on creation. However, it doesn't specify what a 'webhook' entails in this context (e.g., event notifications), leaving some ambiguity compared to more detailed alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing form), exclusions, or comparisons to siblings like 'configure_form_notifications' or 'update_tally_webhook'. Without this context, users must infer usage from the tool name alone, which is insufficient for informed decision-making.
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. 'Delete' implies a destructive, irreversible mutation, but the description doesn't specify permissions required, whether deletions are permanent or recoverable, rate limits, or what happens upon success/failure. This is a significant gap for a destructive tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Delete a specific form submission'—making it appropriately sized and front-loaded. Every word earns its place by conveying the core action and target without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive mutation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or response format, leaving critical gaps for an AI agent to understand and invoke the tool correctly in 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?
Schema description coverage is 100%, with both parameters ('formId' and 'submissionId') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or relationships between parameters. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a specific form submission'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'delete_tally_form' or other deletion tools in the sibling list, which would require more specificity for 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. With sibling tools including 'delete_tally_form' and 'delete_tally_webhook', there's no indication of when to choose deletion of a form submission over deletion of an entire form or webhook, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, whether it affects related data (e.g., submissions), or what the response looks like. For a destructive tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded with the core action ('Delete a Tally form'), making it immediately scannable and efficient. Every word earns its place by conveying essential information without redundancy.
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 that this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like irreversible consequences, error conditions, or what happens to associated resources. For a tool that permanently removes data, this level of brevity leaves too many unanswered questions for safe 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%, with the single parameter 'formId' clearly documented in the schema as 'The ID of the form to delete'. The description doesn't add any additional semantic context beyond what the schema provides, such as format examples or where to find the ID. With high schema coverage, the baseline 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 verb ('Delete') and resource ('a Tally form'), making the purpose immediately understandable. It distinguishes itself from siblings like 'delete_form_submission' and 'delete_tally_webhook' by specifying the type of resource being deleted. However, it doesn't specify whether this is permanent deletion or soft deletion, which would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the form ID), when not to use it (e.g., if the form has active submissions), or what happens after deletion. With siblings like 'update_form_status' that might offer alternative ways to manage forms, this lack of guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get's templates, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns paginated results, or what the output format looks like. For a tool with no annotation coverage, this leaves significant behavioral gaps, though it doesn't contradict any annotations.
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 that front-loads the core purpose and provides relevant examples. There's no wasted text, and it's appropriately sized for a simple tool. It could be slightly more structured by explicitly stating the parameter's role, but it's concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 1 parameter with full schema coverage, the description is incomplete. It lacks details on behavioral aspects like authentication needs, rate limits, or output format, which are crucial for an agent to use the tool correctly. The examples help but don't compensate for the missing contextual information.
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 parameter 'templateType' fully documented including its enum values. The description adds minimal value beyond the schema by listing example scenarios that partially overlap with the enum (e.g., 'progressive_disclosure', 'skip logic' vs 'simple_skip', 'branching_survey'). However, it doesn't explain parameter usage or semantics in depth, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'pre-built conditional logic templates', specifying what the tool does. It provides examples of common scenarios (progressive disclosure, skip logic, branching surveys), which helps distinguish it from siblings like 'create_conditional_logic_block' or 'validate_form_logic_flow'. However, it doesn't explicitly differentiate from all siblings, such as 'get_tally_form_templates', which might also involve templates.
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 mentions 'common scenarios' but provides no explicit guidance on when to use this tool versus alternatives. It doesn't specify prerequisites, exclusions, or when to choose this over other template-related tools like 'get_tally_form_templates'. The context is implied through the examples, but lacks clear usage rules or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get list of questions', implying a read-only operation, but does not specify if it requires authentication, returns paginated results, includes metadata, or handles errors. For a tool with no annotations, 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 with no wasted words, making it easy to parse. It is front-loaded with the core action and resource, which is ideal for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It does not explain what the returned list of questions includes (e.g., question text, types, options) or any behavioral aspects like error handling. For a tool with 1 parameter and no structured output, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 as 'The ID of the form'. The description adds no additional meaning beyond this, as it does not explain the format of 'formId' or provide context on where to obtain it. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'list of questions for a specific form', making the purpose understandable. However, it does not distinguish this tool from sibling tools like 'get_form_submission' or 'get_form_submissions', which also retrieve form-related data but for different resources, 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, such as 'get_form_submissions' (which might include questions along with submissions) or 'get_tally_form' (which could provide form details including questions). There is no mention of prerequisites, exclusions, or specific contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get details' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what 'details' include (e.g., response format, fields returned). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 front-loads the core purpose ('Get details of a specific form submission'). There is no wasted verbiage, repetition, or unnecessary elaboration, 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?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't address what 'details' entail (e.g., structured response, included fields), potential errors, or dependencies. While concise, it fails to provide sufficient context for an agent to understand the full scope of the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what the schema already provides (100% coverage). It doesn't explain the relationship between formId and submissionId, format expectations, or where to obtain these IDs. Since the schema descriptions fully document both parameters, the baseline score of 3 is appropriate—the description doesn't enhance parameter understanding but doesn't detract either.
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 ('Get') and resource ('details of a specific form submission'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'get_form_submissions' (plural) by specifying retrieval of a single submission. However, it doesn't explicitly contrast with other read operations like 'get_form_questions' or 'get_tally_form', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a formId and submissionId), nor does it differentiate from similar tools like 'get_form_submissions' (which likely lists multiple submissions) or other 'get_' siblings. Without any usage context, the agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It doesn't mention whether this is a read-only operation, what permissions are required, rate limits, or what the return format looks like. The description only states what the tool does at a high level without behavioral 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 a single, efficient sentence that communicates the core purpose without any wasted words. It's front-loaded with the essential information and contains no unnecessary elaboration or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how submissions are structured, error conditions, or behavioral constraints. The agent would need to guess about the output format and operational characteristics.
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 fully documents all three parameters (formId, limit, offset) with their types and descriptions. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for adequate coverage without adding 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 verb 'Get' and resource 'list of submissions for a specific form', making the purpose immediately understandable. It distinguishes from sibling tools like 'get_form_submission' (singular) by specifying it retrieves multiple submissions. However, it doesn't explicitly mention the pagination aspect which is part of the tool's functionality.
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 when to choose this over 'get_form_submission' (singular), nor does it provide context about prerequisites, permissions, or typical use cases. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get details') but doesn't specify if it requires authentication, rate limits, error handling, or what details are returned (e.g., metadata, settings). This is inadequate for a tool with potential complexity.
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 zero waste—it directly states the tool's purpose without redundancy. It's appropriately sized for a simple retrieval tool and front-loaded with 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' are returned (e.g., form structure, submissions, settings), which is critical for a retrieval tool. This gap makes it insufficient for an agent to understand the tool's full 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 description adds no parameter semantics beyond the input schema, which has 100% coverage and fully documents the 'formId' parameter. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Get details') and resource ('a specific Tally form'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_tally_forms' (plural) or 'get_form_questions', which might retrieve related but different information, preventing 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, such as needing a form ID, or compare it to siblings like 'get_tally_forms' for listing forms or 'get_form_questions' for form structure details, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get list' but doesn't specify whether this is a read-only operation, if it requires authentication, what the return format looks like (e.g., pagination, fields included), or any rate limits. For a list operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get list of Tally forms'. It's front-loaded with the core action and resource, with no wasted words or unnecessary elaboration, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal. While it states the purpose, it lacks context about the return value (e.g., what data is included in the list), behavioral traits, or differentiation from siblings. For even a simple tool, more completeness would help an agent use it effectively.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly doesn't mention any. A baseline of 4 is appropriate since there's nothing missing or misleading regarding parameters.
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 'Get list of Tally forms' clearly states the verb ('Get') and resource ('Tally forms'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_tally_form' (singular) or 'get_tally_form_templates', leaving ambiguity about scope and 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. With sibling tools like 'get_tally_form' (singular) and 'get_tally_form_templates', there's no indication of whether this tool retrieves all forms, active forms, or has other contextual differences that would inform selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' a list, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns paginated results, or details the output format. This leaves significant gaps for a tool that interacts with external data.
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, clear sentence with no wasted words, making it easy to parse and understand quickly. It efficiently conveys the core functionality without unnecessary elaboration.
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 lack of annotations and output schema, the description is insufficient for a tool that retrieves data from an external service. It doesn't explain what the returned list contains, how to handle errors, or any operational constraints, leaving the agent with incomplete information for reliable 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 'for a specific form', which aligns with the single parameter 'formId' in the schema. Since schema description coverage is 100%, the schema already documents the parameter fully, so the description adds minimal value beyond reinforcing the parameter's role, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and resource ('webhooks for a specific form'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling operations like 'get_tally_webhook' (singular) or other list operations, 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, such as when to retrieve webhooks versus form submissions or other form-related data. It lacks context about prerequisites or typical use cases, offering only basic functional information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Update' implying a mutation operation, but doesn't disclose behavioral traits such as required permissions, whether changes are reversible, rate limits, or error conditions. The description adds minimal context beyond the basic action, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and examples, making it easy to parse quickly. Every word earns its place without redundancy.
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 7 parameters, no annotations, and no output schema, the description is inadequate. It lacks behavioral context, usage differentiation from siblings, and details on what the update entails or returns. The high parameter count and mutation nature demand more completeness than provided.
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 fully documents all 7 parameters. The description adds no specific parameter semantics beyond implying settings like 'notifications' and 'closing options', which loosely map to some parameters but don't provide additional meaning. Baseline 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 action ('Update') and resource ('form settings') with examples ('notifications, closing options, etc.'). It distinguishes from siblings like 'update_form_status' by focusing on settings rather than status, but doesn't explicitly name alternatives. The purpose is specific but could be more precise about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_form_status' or 'configure_form_notifications'. The description mentions 'notifications' which overlaps with 'configure_form_notifications', creating ambiguity without clarification on differentiation. No prerequisites or exclusions are stated.
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 implies a mutation ('Update') but doesn't specify whether this requires authentication, what happens on success/failure, if changes are reversible, or any side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and lists the status values without unnecessary words. Every element earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like permissions, error handling, and return values, which are critical for safe and effective tool invocation in this 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?
Schema description coverage is 100%, so the input schema fully documents both parameters (formId and status with enum values). The description adds no additional semantic details beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('status of a form'), and specifies the possible status values (BLANK, PUBLISHED, DRAFT). However, it doesn't explicitly differentiate this tool from sibling tools like 'update_form_settings' or 'update_tally_form', which could handle similar form updates.
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 'update_form_settings' or 'update_tally_form', nor does it mention prerequisites such as form existence or permissions. It only lists the status options without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'update' implies a mutation operation, the description does not address critical behavioral aspects such as required permissions, whether the update is reversible, error handling, rate limits, or what happens to unspecified fields. This leaves significant gaps for a mutation tool with complex parameters.
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 and key updatable fields without any unnecessary words. It is well-structured and front-loaded, making it easy for an agent to quickly understand the core functionality.
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 the tool (5 parameters with nested objects, no annotations, and no output schema), the description is inadequate. It lacks behavioral transparency, usage guidelines, and details on the update operation's effects or return values, which are crucial for an agent to use this mutation tool correctly and safely.
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%, so the input schema already documents all parameters thoroughly. The description adds minimal value by listing the updatable fields (name, status, blocks, settings), but does not provide additional context, syntax, or format details beyond what the schema specifies. 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.
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 as updating an existing Tally form with comprehensive options including name, status, blocks, and settings. It specifies the verb 'update' and the resource 'Tally form', but does not explicitly differentiate it from sibling tools like 'update_form_settings' or 'update_form_status', which appear to handle more specific aspects of form updates.
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 such as 'update_form_settings' or 'update_form_status', nor does it specify prerequisites, exclusions, or appropriate contexts for usage, leaving the agent to infer usage from the tool name and 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it's an update operation (implying mutation), but doesn't disclose permissions required, whether it overwrites or merges settings, error conditions, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant 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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without being overly terse.
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 inadequate. It doesn't cover behavioral aspects like side effects, error handling, or response format, nor does it provide usage context. The 100% schema coverage helps with parameters, but overall completeness is poor given the tool's complexity.
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 parameters are fully documented in the schema. The description adds no additional parameter context beyond implying 'update' involves modifying fields. It doesn't explain relationships between parameters (e.g., that 'events' and 'url' are optional updates) or provide examples, so it meets the baseline but doesn't add 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 ('Update') and resource ('an existing webhook'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_tally_webhook' by specifying 'existing', but doesn't differentiate from other update tools like 'update_form_settings' or 'update_tally_form' beyond the resource type.
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 (e.g., needing a webhook ID), when not to use it, or how it differs from similar tools like 'configure_form_notifications' or 'create_tally_webhook' beyond the basic update action.
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 mentions identifying 'potential issues or dead ends' but doesn't specify what types of issues, whether the analysis is read-only, if it requires specific permissions, or what the output format might be. This leaves significant gaps for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('analyze and validate') without unnecessary words. Every part earns its place by specifying the resource and outcome, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing form logic flow), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'potential issues or dead ends' entail, the analysis methodology, or return values, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting the 'blocks' parameter as an array of form blocks. The description adds no additional parameter semantics beyond implying analysis of logical flow, so it meets the baseline of 3 without compensating for or contradicting the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('analyze and validate') and resource ('logical flow of a form'), distinguishing it from siblings like 'validate_multiple_choice_logic' which focuses on a specific logic type. However, it doesn't explicitly differentiate from all siblings (e.g., 'create_conditional_logic_block'), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'validate_multiple_choice_logic' or 'get_form_questions', nor does it mention prerequisites or exclusions. Usage is implied through the purpose but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions creating questions with conditional option sets but doesn't disclose behavioral traits such as whether this requires specific permissions, if it's a write operation (implied by 'create'), what happens on failure, or any rate limits. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Create questions with conditional option sets') and provides a concrete example ('like Q5/Q6 in complex surveys'). Every word earns its place with zero waste.
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 (creating dynamic questions with conditional logic) and the absence of annotations and output schema, the description is somewhat complete but lacks details on behavioral aspects and return values. It covers the purpose and hints at usage but doesn't fully compensate for missing structured data, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value by mentioning 'conditional option sets' and 'trigger field values', which aligns with the schema but doesn't provide additional syntax or format details beyond what's in the structured data.
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 creates questions with conditional option sets that change based on previous answers, providing a specific verb ('create') and resource ('questions with conditional option sets'). It distinguishes from siblings by focusing on dynamic question creation rather than form management, notifications, or logic validation, though it doesn't explicitly name alternatives.
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 for complex surveys with conditional logic (like Q5/Q6), suggesting context for dynamic question creation. However, it doesn't explicitly state when to use this tool versus alternatives like 'create_conditional_logic_block' or 'validate_multiple_choice_logic', nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or what the return format looks like (e.g., list of templates with details). For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get pre-built form templates') and includes relevant examples in parentheses. There's no wasted verbiage, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter) and high schema coverage, the description is adequate but incomplete. It lacks details on behavioral aspects (e.g., output format, permissions) and doesn't leverage the absence of an output schema to explain return values. For a simple retrieval tool, it meets minimum viability but could be more comprehensive.
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 a well-documented 'templateType' parameter including an enum of common form types. The description adds context by listing examples (contact forms, surveys, etc.) that align with the enum, but doesn't provide additional semantics beyond what the schema already covers. With high schema coverage, the baseline is 3.
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 ('Get') and resource ('pre-built form templates'), specifying the purpose as retrieving templates for common use cases. It distinguishes from siblings like 'get_tally_form' or 'get_tally_forms' by focusing on templates rather than actual forms. However, it could be more specific about what 'pre-built' entails (e.g., ready-to-use structures).
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 for common form types (e.g., contact forms, surveys), suggesting it's for starting points or inspiration. It doesn't explicitly state when to use this versus alternatives like 'create_tally_form' (for custom forms) or 'get_conditional_logic_templates' (for logic templates), leaving some ambiguity. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool validates logic to prevent errors, which implies a read-only, non-destructive operation, but doesn't specify what happens during validation (e.g., returns errors, warnings, or a pass/fail result), any rate limits, or authentication requirements. For a validation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 front-loads the core purpose and includes a specific example of common errors. There is no wasted text, and it directly communicates the tool's function without unnecessary elaboration.
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 complexity (2 parameters with nested objects, no output schema, and no annotations), the description is adequate but incomplete. It explains what the tool does but lacks details on validation outcomes, error handling, or usage context relative to siblings. For a validation tool with structured inputs, more behavioral context would enhance 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 both parameters ('triggerQuestion' and 'conditionalLogic') with descriptions. The description adds minimal value beyond the schema by hinting at validation rules (e.g., preventing 'equals' vs 'contains' errors), but doesn't provide additional syntax, format details, or examples. 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.
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: 'Validate conditional logic for multiple choice questions' with a specific goal to 'prevent common errors like using "equals" instead of "contains"'. It uses a specific verb ('validate') and resource ('conditional logic for multiple choice questions'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'validate_form_logic_flow', which appears related.
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 context by specifying 'multiple choice questions' and 'conditional logic', suggesting it should be used when validating such logic. However, it lacks explicit guidance on when to use this tool versus alternatives like 'validate_form_logic_flow' or other sibling tools, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'comprehensive information' but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what the return format looks like (e.g., list, object). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and purpose ('Get comprehensive information...'). It has no wasted words and directly communicates the tool's function, making it highly concise and well-structured.
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 has 0 parameters, 100% schema coverage, and no output schema, the description is adequate but incomplete. It specifies the purpose but lacks details on behavioral aspects like return format or usage constraints, which are important for a tool with no annotations. A higher score would require more context to compensate for the missing structured data.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. Baseline is 4 for zero parameters, as it avoids unnecessary details.
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 'Get' and the resource 'comprehensive information about all available Tally form block types and their structures', specifying this is for building forms. It distinguishes from siblings like 'get_form_questions' or 'get_tally_form_templates' by focusing on block types, though it doesn't explicitly name alternatives. A 5 would require explicit 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for building forms'), suggesting this tool is used when designing or constructing forms to understand available block types. However, it lacks explicit guidance on when to use this versus alternatives like 'get_tally_form_templates' or 'get_conditional_logic_templates', and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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-server MCP server](https://glama.ai/mcp/servers/cathrynlavery/tally-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/cathrynlavery/tally-mcp-server)

Score Badge

Copy to your README.md:

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

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/cathrynlavery/tally-mcp-server'

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