Provides tools to manage email marketing via Kit.com (formerly ConvertKit), including subscribers, tags, sequences, broadcasts, forms, custom fields, and webhooks.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Kit Server list subscribers with tag 'newsletter'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that connects AI assistants like Claude to the Kit.com (formerly ConvertKit) email marketing platform. Manage your email lists, subscribers, broadcasts, sequences, and more through natural language.
This project is deprecated and no longer maintained. Kit now ships official, first-party MCP servers that supersede it with broader API coverage and managed authentication. Please migrate — see below.
This community server was built before Kit offered its own MCP. Kit now maintains official servers that cover far more of the Kit API v4 surface (including analytics, commerce, segments, and bulk operations), handle auth for you, and stay current with API changes. New and existing users should migrate.
Use case | Official server | URL |
Act on your Kit account — subscribers, tags, sequences, broadcasts, analytics, commerce… | Kit MCP |
|
Give a coding agent live access to Kit's developer docs + API | Kit Developer Docs MCP |
|
# Remove this deprecated server (if you added it as "kit")
claude mcp remove kit
# Add the official operational Kit MCP
claude mcp add --transport http kit https://app.kit.com/mcp
# Optional: add Kit's developer-docs MCP for building integrations
claude mcp add --transport http kit-docs https://developers.kit.com/mcpOfficial setup guides (Claude Desktop, Cursor, Windsurf, Cline, and more): https://developers.kit.com/mcp/kit-developer-docs-mcp/mcp/overview
Related MCP server: Sequenzy MCP Server
If you run a newsletter or email marketing on Kit.com, this MCP server lets you:
Manage subscribers - List, create, update, and organize your email subscribers
Handle tags efficiently - Create tags, add/remove tags from subscribers, list subscribers by tag
Work with sequences - View email sequences and add subscribers to automated sequences
Create broadcasts - Draft and manage email campaigns
Analyze your list - Query subscriber data with filters (status, date ranges, custom fields)
Automate workflows - Let Claude handle repetitive email marketing tasks
Category | Tools |
Account | Get account information |
Subscribers | List, get, create, update, manage tags |
Tags | List, create, update, delete, get subscribers by tag |
Sequences | List, get, add subscribers |
Broadcasts | List, get, create, update, delete |
Forms | List, get, add subscribers |
Custom Fields | List available fields |
Webhooks | List, create, delete |
Account
kit_get_account - Get Kit.com account information
Subscribers (7 tools)
kit_list_subscribers - List subscribers with filters (status, date ranges, pagination)
kit_get_subscriber - Get a specific subscriber by ID
kit_create_subscriber - Create a new subscriber
kit_update_subscriber - Update subscriber details
kit_get_subscriber_tags - Get all tags for a subscriber
kit_add_tag_to_subscriber - Add a tag to a subscriber
kit_remove_tag_from_subscriber - Remove a tag from a subscriber
Tags (6 tools)
kit_list_tags - List all tags
kit_get_tag - Get a specific tag
kit_create_tag - Create a new tag
kit_update_tag - Rename a tag
kit_delete_tag - Delete a tag
kit_list_tag_subscribers - List all subscribers with a specific tag
Sequences (3 tools)
kit_list_sequences - List all email sequences
kit_get_sequence - Get sequence details
kit_add_subscriber_to_sequence - Add subscriber to a sequence
Broadcasts (5 tools)
kit_list_broadcasts - List all broadcasts
kit_get_broadcast - Get broadcast details
kit_create_broadcast - Create a new broadcast
kit_update_broadcast - Update a broadcast
kit_delete_broadcast - Delete a broadcast
Forms (3 tools)
kit_list_forms - List all forms
kit_get_form - Get form details
kit_add_subscriber_to_form - Add subscriber via form
Custom Fields (1 tool)
kit_list_custom_fields - List all custom fields
Webhooks (3 tools)
kit_list_webhooks - List configured webhooks
kit_create_webhook - Create a new webhook
kit_delete_webhook - Delete a webhook
Node.js 18+
A Kit.com account
Your Kit.com API key (v4 API)
npx kit-mcp-serverOr install globally:
npm install -g kit-mcp-servergit clone https://github.com/aplaceforallmystuff/mcp-kit.git
cd mcp-kit
npm install
npm run buildLog in to Kit.com
Navigate to Settings > Developer
Create a new API key or copy an existing v4 API key
Add to your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"kit": {
"command": "node",
"args": ["/path/to/mcp-kit/dist/index.js"],
"env": {
"KIT_API_KEY": "your-api-key-here"
}
}
}
}claude mcp add kit -e KIT_API_KEY=your-api-key-here -- node /path/to/mcp-kit/dist/index.jsOr add to ~/.claude.json:
{
"mcpServers": {
"kit": {
"command": "node",
"args": ["/path/to/mcp-kit/dist/index.js"],
"env": {
"KIT_API_KEY": "your-api-key-here"
}
}
}
}Once configured, you can interact with Kit.com through natural language:
"Show me all active subscribers from the last 30 days"
"Create a new subscriber with email user@example.com and tag them as 'newsletter'"
"What tags does subscriber@example.com have?"
"List all my tags and how many subscribers each has"
"Create a tag called 'VIP Customers'"
"Add the 'engaged' tag to all subscribers who signed up this month"
"Show me all my email sequences"
"Add user@example.com to the welcome sequence"
"Create a draft broadcast with subject 'Weekly Update' and preview text 'This week in AI...'"
"List all my recent broadcasts and their stats"
"Show me all active forms"
"Add a subscriber to my main signup form"
# Run in development mode (watches for changes)
npm run dev
# Build for production
npm run build
# Run the built version
npm startEnsure you have set the KIT_API_KEY environment variable in your MCP configuration.
Your API key is invalid or expired. Generate a new one from Kit.com Settings > Developer.
Your API key doesn't have permission for this operation. Check that you're using a v4 API key with appropriate scopes.
The resource (subscriber, tag, broadcast, etc.) was not found. Verify the ID is correct.
Invalid request data. Check that email addresses are valid and required fields are provided.
This server uses the Kit.com API v4. All tools support pagination where applicable using per_page and after cursor parameters.
This project is deprecated and not accepting contributions. Please use Kit's official MCP servers instead.
MIT License - see LICENSE for details.
Add a subscriber to a form (creates subscriber if doesn't exist)
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | The form ID | |
| Yes | The subscriber's email address | ||
| first_name | No | The subscriber's first name | |
| fields | No | Custom field values |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the key behavioral trait of creating a subscriber if missing. However, it does not mention whether adding an already-subscribed subscriber is idempotent, any error conditions, or rate limits. Still, the main side effect is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action and note. No wasted words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It does not explain return values, error handling, or behavior for duplicate additions. For a tool that may create resources, more context would be beneficial, but it's adequate for a simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is described in the schema. The description does not add meaning beyond the schema, such as constraints or relationships. Baseline is 3, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a subscriber to a form' and adds an important side effect: 'creates subscriber if doesn't exist'. It distinguishes this tool from sibling tools like kit_add_subscriber_to_sequence and kit_add_tag_to_subscriber.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: adding a subscriber to a form, with automatic creation. However, it does not explicitly mention when not to use it or provide comparisons to siblings. The context of sibling tools helps, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a subscriber to an email sequence
| Name | Required | Description | Default |
|---|---|---|---|
| sequence_id | Yes | The sequence ID | |
| Yes | The subscriber's email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden but only states the basic action; missing details on side effects, rate limits, or required authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded purpose; but could incorporate additional context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is too minimal; lacks explanation of effects (e.g., what happens to subscriber) and any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described, so baseline is 3; description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a subscriber to an email sequence' uses a specific verb and resource, clearly distinguishing it from siblings like kit_add_subscriber_to_form or kit_add_tag_to_subscriber.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no context provided for prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a tag to a subscriber
| Name | Required | Description | Default |
|---|---|---|---|
| subscriber_id | Yes | The subscriber ID | |
| tag_id | Yes | The tag ID to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only indicates a write operation. Lacks details on idempotency, side effects, or what happens if the tag already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (5 words), front-loaded, and no wasted words. Slightly too brief, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 required string parameters, and the description adequately states its function. However, absence of output schema and behavioral details leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a tag to a subscriber' clearly states the action and resources, distinguishing it from siblings like 'kit_remove_tag_from_subscriber' and 'kit_add_subscriber_to_form'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., adding subscriber to form/sequence). No context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new broadcast (email campaign) in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | The email subject line | |
| content | No | The email content (HTML supported) | |
| description | No | Internal description for the broadcast | |
| public | No | Whether the broadcast should be public | |
| preview_text | No | Preview text shown in email clients | |
| send_at | No | ISO date when to send the broadcast |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits like idempotency, authorization requirements, rate limits, side effects, or what happens on success/failure. The agent gains no behavioral insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential purpose without any unnecessary words or fluff. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description should explain what the return value is (e.g., the created broadcast object) or mention any prerequisites. It lacks this information, making it incomplete for an agent to understand the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description in the input schema. The tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline without adding extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('broadcast (email campaign)') and includes the platform name 'Kit.com', making it easy to distinguish from sibling tools like 'kit_list_broadcasts' or 'kit_update_broadcast'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to create a broadcast versus updating or listing one. 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.
Create a new subscriber in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| email_address | Yes | The subscriber's email address | |
| first_name | No | The subscriber's first name | |
| state | No | Subscriber state (default: active) | |
| fields | No | Custom field values as key-value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states 'create' implying mutation, but omits details like duplicate email handling, state defaults, or side effects (e.g., welcome emails). This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At one sentence, it is extremely concise and front-loaded. However, it may be too terse for a tool with four parameters, sacrificing helpfulness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should cover return values and error conditions. It does not, leaving the agent to guess the response format or failure modes. Incomplete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain custom field usage or state implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new subscriber, distinguishing it from update/list siblings. However, it does not differentiate from other create tools in the same suite (e.g., create tag, create broadcast) except by resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like updating an existing subscriber or adding a subscriber to a form/sequence. The agent receives no 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.
Create a new tag in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name for the new tag |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description does not disclose any behavioral traits (e.g., idempotency, error handling if tag name exists). For a create operation, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Could be improved by adding a second sentence on return value or usage hint, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with one parameter and no output schema, the description is minimally adequate. Lacks details on return value or error cases, but covers basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for 'name' parameter. Description adds no extra meaning beyond what schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Create', resource 'tag', and platform 'Kit.com'. Distinguishes from sibling tools like kit_delete_tag or kit_update_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. For example, does not mention that tags should be created before adding to subscribers, or that kit_update_tag modifies existing tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new webhook in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| target_url | Yes | The URL to receive webhook events | |
| event_name | Yes | The event name (e.g., subscriber.subscriber_activate) | |
| tag_id | No | Tag ID for tag-specific events | |
| form_id | No | Form ID for form-specific events | |
| sequence_id | No | Sequence ID for sequence-specific events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as idempotency, uniqueness constraints, or side effects. The agent is left uninformed about important operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool with 5 parameters and no output schema. It does not explain what happens after creation, how to confirm success, or any prerequisites, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the input schema (100% coverage), so the description adds no additional meaning beyond what is already available. The baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Create' and the resource 'webhook', clearly distinguishing it from sibling tools like kit_delete_webhook and kit_list_webhooks. However, it does not elaborate on the webhook's role or event handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kit_delete_webhook or other create tools. The description is purely functional with no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a broadcast from Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| broadcast_id | Yes | The broadcast ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose side effects (e.g., irreversibility, dependencies like sent vs. draft broadcasts) beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no output schema and no annotations, the description omits crucial context like confirmation requirements or whether deletion is reversible, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions; the tool description adds no additional meaning beyond 'The broadcast ID to delete'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'broadcast', and it distinguishes from sibling tools like 'create' and 'update'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., archiving) or what prerequisites exist (e.g., broadcast state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a tag from Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| tag_id | Yes | The tag ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose effects like cascading deletions, permissions needed, or reversibility. For a destructive operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words. Efficiently conveys the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple operation with one parameter, but lacks details about return value, side effects, or confirmation. Without annotations or output schema, some context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single parameter with a basic description. The description adds no additional context beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Delete') and resource ('tag') with the platform ('Kit.com'). Distinguishes from sibling tools like kit_create_tag and kit_update_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., kit_remove_tag_from_subscriber). No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a webhook from Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_id | Yes | The webhook ID to delete |
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 only indicates deletion but does not disclose permissions, reversibility, side effects, or error behavior. The agent has insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action. Every word is necessary and directly conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description, combined with the schema, is minimally sufficient but lacks behavioral details like idempotency or confirmation of success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the single parameter. The description reiterates the parameter name but adds no extra meaning like format or source. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a webhook from Kit.com', which is a specific verb+resource. It distinguishes from sibling tools like kit_create_webhook and other delete tools, though it does not elaborate on scope or alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the Kit.com account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Get information,' implying a read operation but lacking details on authentication, rate limits, or what information is included. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded verb and resource, no unnecessary words. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal context, the description is adequate for a simple tool but could be more informative about what information is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema coverage, the description adds no extra meaning beyond the empty schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'account', and it distinguishes itself from sibling tools that target specific entities like subscribers or broadcasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or any prerequisites. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific broadcast by ID
| Name | Required | Description | Default |
|---|---|---|---|
| broadcast_id | Yes | The broadcast ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the basic operation, omitting details on side effects, permissions, error handling, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is efficient for a simple get tool. However, it lacks any structured breakdown or additional context that could enhance usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, single-parameter tool with no output schema, the description is adequate but minimal. It does not hint at the return value or any special behavior, leaving the agent to infer from the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the description 'The broadcast ID' already in the schema. The tool description adds no additional meaning beyond what the schema provides, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get a specific broadcast by ID' clearly states verb (Get), resource (broadcast), and qualifier (by ID). Distinguishes from sibling tools like kit_list_broadcasts and kit_create_broadcast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Usage is implied for retrieving a single broadcast by ID, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific form by ID
| Name | Required | Description | Default |
|---|---|---|---|
| form_id | Yes | The form ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It lacks details on behavior: is it read-only? What happens if form not found (returns null/error)? Any authentication or rate limits? No mention, leaving agent uninformed about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence, no filler. Every word is meaningful for the basic purpose. Appropriate for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one param, no output schema, no annotations), the description is adequate but minimal. It tells the basic action but omits return value, error behavior, or any additional context that could help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with parameter description 'The form ID'. The description adds no extra meaning beyond that. Baseline 3 is appropriate since schema already documents parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'specific form', and the identifier 'by ID'. It distinguishes from sibling 'kit_list_forms' which lists all forms, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Missing context like 'Use to retrieve a single form when you know its ID; for all forms use kit_list_forms'. No exclusions or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific sequence by ID
| Name | Required | Description | Default |
|---|---|---|---|
| sequence_id | Yes | The sequence ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details like return format, error handling, or side effects beyond a simple retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is fairly complete, though it could mention prerequisites or response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond 'the sequence ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a specific sequence by ID'), distinguishing it from sibling tools like 'kit_list_sequences' (list all) and 'kit_add_subscriber_to_sequence' (add subscriber).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to list sequences first to obtain an ID, or when to use other lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific subscriber by ID
| Name | Required | Description | Default |
|---|---|---|---|
| subscriber_id | Yes | The subscriber ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'Get', implying a read operation, but fails to mention error handling, idempotency, or return value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the key information. However, it is slightly too sparse, omitting any additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is mostly adequate but lacks details on error states or return format, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter (subscriber_id). The description adds no new meaning beyond the schema's 'The subscriber ID', so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a specific subscriber by ID'), making it distinct from sibling tools like list_subscribers, create_subscriber, and update_subscriber.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not differentiate when to use this tool versus alternatives (e.g., list subscribers) or mention prerequisites like having the subscriber ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all tags for a specific subscriber
| Name | Required | Description | Default |
|---|---|---|---|
| subscriber_id | Yes | The subscriber ID |
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 the operation is read-only but does not disclose return format, pagination, or error handling (e.g., if subscriber ID is invalid). Minimal behavioral context beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool with no output schema, the description covers the core purpose. It could mention that the result is a list of tags, but the purpose is adequately conveyed for selection and basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter has a clear description). The tool description reinforces the parameter role ('for a specific subscriber') but adds no new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all tags for a specific subscriber' clearly specifies the action (get) and resource (tags for a subscriber), distinguishing it from sibling tools like kit_get_tag (single tag) and kit_list_tags (all tags in account).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or exclusions are provided. However, the purpose is clear and the sibling context implies usage for retrieving tags associated with a subscriber, rather than adding or removing tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific tag by ID
| Name | Required | Description | Default |
|---|---|---|---|
| tag_id | Yes | The tag ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states 'Get', implying a read operation, but fails to mention what happens if the tag does not exist, authentication requirements, or any side effects. This is insufficient for a safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description omits return value information. There is no output schema, so the agent cannot anticipate the response structure. The description should at least mention that the tool returns a tag object or an error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema's 'The tag ID'. No extra semantics for the parameter are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific tag by ID' clearly states the verb 'Get', the resource 'tag', and the method 'by ID', effectively distinguishing it from siblings like kit_list_tags or kit_get_subscriber_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like kit_list_tags for listing all tags or kit_get_subscriber_tags for tags of a subscriber. The description lacks context about the tool's role in the broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all broadcasts (email campaigns) in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Number of results per page | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'List all broadcasts'. It does not disclose that pagination is cursor-based, the behavior when no parameters are provided, or any rate limits. For a read operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence that front-loads the purpose. However, it could be slightly more structured with a brief note on pagination, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no output schema) and complete schema coverage, the description is minimally adequate but does not provide extra context like default pagination limits or result format. It could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described. The description adds no additional meaning beyond what the schema already provides, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'List' and the resource 'broadcasts (email campaigns)', which clearly distinguishes it from sibling tools like 'kit_get_broadcast' (for a single broadcast) or 'kit_create_broadcast'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'kit_get_broadcast' for a single broadcast) or on prerequisites like pagination handling with the 'after' cursor. The description lacks context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all custom fields defined in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose that this is a read-only operation, nor any potential side effects, authentication needs, or rate limits. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key info. No wasted words; appropriate for a simple 0-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema; description does not hint at return structure (e.g., array of custom field objects). Adequate but could be more complete given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline score for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list', resource 'custom fields', and scope 'all defined in Kit.com'. No sibling tool with similar purpose, so no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives, but context implies usage for retrieving custom fields. Sibling tools are about other entities, so no direct conflict.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all forms in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by form status | |
| per_page | No | Number of results per page | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no description of behavioral traits (e.g., read-only, permissions). The description implies a safe list operation but lacks explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words. Could include more details but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 3 optional parameters and no output schema, the description is minimal but functional. Lacks details on pagination and status filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning. Baseline 3 is appropriate as the schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'forms', distinguishing it from sibling list tools like kit_list_broadcasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many list siblings, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all email sequences in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Number of results per page | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'List all email sequences'. It does not disclose pagination behavior, rate limits, or any side effects. The description is insufficient for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the core purpose. While efficient, it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with optional parameters and no output schema, the description is incomplete. It does not explain the return format, pagination, or how to use the 'after' cursor, leaving a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters documented). The description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all email sequences in Kit.com. It distinguishes from sibling tools like kit_get_sequence (single) and other list tools by specifying 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., kit_get_sequence for a specific sequence). No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subscribers from Kit.com with optional filters. Returns paginated results.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by subscriber status | |
| created_after | No | Filter subscribers created after this ISO date | |
| created_before | No | Filter subscribers created before this ISO date | |
| sort_field | No | Field to sort by | |
| sort_order | No | Sort order | |
| per_page | No | Number of results per page (max 100) | |
| after | No | Cursor for pagination - get results after this cursor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool lists subscribers and returns paginated results, but lacks details on behavioral traits like rate limits, authentication requirements, or whether the operation is read-only. This is minimal but acceptable for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences, front-loading the purpose and pagination behavior. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return structure. It mentions 'paginated results' but not fields of a subscriber. However, sibling tools like kit_get_subscriber may provide context. With 7 optional parameters and no required ones, the description is mostly complete but lacks return field details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no further meaning beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'subscribers', clearly defining the tool's function. It distinguishes from sibling tools like kit_get_subscriber (single subscriber) and kit_create_subscriber (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filters and pagination but does not explicitly guide when to use this tool vs alternatives. For example, it does not say 'for listing all subscribers with filters, use this tool' vs 'for a single subscriber, use kit_get_subscriber'. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tags in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Number of results per page | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like read-only nature, rate limits, or that pagination is supported (implied by parameters but not mentioned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two pagination parameters and no output schema, the description is somewhat complete but lacks context about the return structure or pagination behavior. Could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all tags in Kit.com' uses a specific verb ('List') and resource ('tags'), clearly distinguishing it from siblings like 'kit_get_tag' (single tag) and 'kit_list_tag_subscribers' (tags with subscribers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as 'kit_get_tag' for a single tag or pagination handling. The description only states what the tool does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all subscribers with a specific tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag_id | Yes | The tag ID | |
| per_page | No | Number of results per page | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool lists subscribers but omits that results are paginated (implied by per_page and after parameters) and does not mention any read-only or side-effect behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded, but it is under-specified for a tool with three parameters. Additional details about pagination or return format would improve usefulness without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description is minimally complete but lacks information on pagination behavior and the structure of the returned subscriber list. This gap reduces completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters. The description adds no extra meaning beyond what is in the schema, meeting the baseline for a tool with high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists subscribers filtered by a specific tag, distinguishing it from related tools like kit_list_subscribers (which lists all subscribers) and kit_get_subscriber_tags (which retrieves tags for a subscriber).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kit_list_subscribers or kit_get_subscriber_tags. The description does not specify context like required permissions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all webhooks configured in Kit.com
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No | Number of results per page | |
| after | No | Cursor for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'List all webhooks', without disclosing read-only nature, potential rate limits, or authentication needs. Minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no wasted words. It efficiently conveys the core purpose, though it may be slightly too terse for a tool with pagination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description omits details about pagination behavior, return format, or whether 'all' implies potential multiple pages. Lacks completeness for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning or usage context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all webhooks configured in Kit.com', using a specific verb and resource. It distinguishes from sibling tools like kit_create_webhook and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are provided. The context from the tool name and siblings implies it's for listing webhooks, but there is no guidance on when to choose this over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a tag from a subscriber
| Name | Required | Description | Default |
|---|---|---|---|
| subscriber_id | Yes | The subscriber ID | |
| tag_id | Yes | The tag ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a mutating action but lacks details on idempotency, error handling (e.g., removing a non-existent tag), or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It could benefit from additional structure, but for its brevity it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no output schema, the description is minimally complete. However, it lacks details on behavior like error states, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds no additional meaning beyond the action, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and identifies the resource 'tag from a subscriber'. It clearly distinguishes from siblings like kit_add_tag_to_subscriber and kit_get_subscriber_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., tag must be attached) or suggest checking existing tags first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing broadcast
| Name | Required | Description | Default |
|---|---|---|---|
| broadcast_id | Yes | The broadcast ID to update | |
| subject | No | New subject line | |
| content | No | New content | |
| description | No | New description | |
| public | No | Whether the broadcast should be public | |
| preview_text | No | New preview text | |
| send_at | No | New send time (ISO date) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It merely states 'Update an existing broadcast' without indicating idempotency, mutability, permissions, or what fields are overwritten. This is insufficient for an agent to understand effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero unnecessary words. It is front-loaded and efficient, fitting in a single brief sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema or annotations, the description is too minimal. It does not explain return values, errors, or any post-update behavior, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 7 parameters with descriptions, so baseline is 3. The tool description adds no additional meaning beyond the schema, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('an existing broadcast'), making the purpose unambiguous. However, it does not elaborate on the scope or distinguish between partial and full updates, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like kit_create_broadcast or kit_delete_broadcast. The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing subscriber
| Name | Required | Description | Default |
|---|---|---|---|
| subscriber_id | Yes | The subscriber ID to update | |
| email_address | No | New email address | |
| first_name | No | New first name | |
| fields | No | Custom field values to update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose key behavioral traits: idempotency, error handling for missing subscriber_id, what happens if the subscriber does not exist, or whether the update is partial or full. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words), but it sacrifices informativeness. While short, it does not front-load critical context. A few more sentences would improve utility without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (including a nested object), no output schema, and no annotations, the description is inadequate. It does not explain the overall purpose, required fields beyond the schema, or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a basic description. However, the tool description adds no additional meaning beyond the schema (e.g., explaining how 'fields' relates to custom fields or the update semantics). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing subscriber' clearly states the action and resource, but it does not differentiate from sibling update tools like kit_update_broadcast or kit_update_tag. It lacks specificity about what aspects of a subscriber are updatable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kit_create_subscriber or other update tools. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing tag's name
| Name | Required | Description | Default |
|---|---|---|---|
| tag_id | Yes | The tag ID to update | |
| name | Yes | The new name for the tag |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Update an existing tag's name', omitting details like idempotency, error behavior if tag doesn't exist, or side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, it could be more structured by adding a brief statement about usage or behavior. It is not verbose, but lacks some front-loaded context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, simple parameters, and no output schema, the description is minimally viable. However, it lacks context about success/failure responses and any required permissions, which are important for a mutating operation without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have descriptions in the schema. The tool description does not add extra meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), resource (existing tag), and attribute (name). It distinguishes from sibling tools like kit_create_tag, kit_delete_tag, and kit_get_tag, which handle different operations on tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., whether the tag must exist) or any conditions that would make this tool inappropriate. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.2kit_add_subscriber_to_formkit_add_subscriber_to_sequencekit_add_tag_to_subscriberkit_create_broadcastkit_create_subscriberkit_create_tagkit_create_webhookkit_delete_broadcastkit_delete_tagkit_delete_webhookkit_get_accountkit_get_broadcastkit_get_formkit_get_sequencekit_get_subscriberkit_get_subscriber_tagskit_get_tagkit_list_broadcastskit_list_custom_fieldskit_list_formskit_list_sequenceskit_list_subscriberskit_list_tag_subscriberskit_list_tagskit_list_webhookskit_remove_tag_from_subscriberkit_update_broadcastkit_update_subscriberkit_update_tagEach tool has a clear and distinct purpose, targeting specific resources like subscribers, tags, broadcasts, forms, sequences, webhooks, and custom fields. No tools overlap in functionality.
All tools follow a consistent 'kit_verb_noun' pattern with underscores, using uniform verbs such as create, get, list, update, delete, add, and remove. There are no deviations or mixed conventions.
With 29 tools, the count is slightly high but appropriate for a comprehensive email marketing platform. Each tool addresses a specific operation, and the scope covers major entities without being excessive.
The tool set provides CRUD for subscribers, tags, broadcasts, and webhooks, but lacks create/update/delete for forms and sequences, delete for subscribers, and full management of custom fields. Some gaps exist for a complete lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI to your Attio CRM. Manage contacts, companies, deals, and sales pipelines. Create tasks…
AI-controlled email ops for campaigns, contacts, segments, analytics, and sending.
Build and send email, SMS, and push straight from your AI agent.
List and create Keap contacts, companies, tasks, opportunities, orders, tags and campaigns.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aplaceforallmystuff/mcp-kit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
