Mailchimp
Server Details
Mailchimp MCP Pack — manage audiences, campaigns, and members via Mailchimp Marketing API.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-mailchimp
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 10 of 10 tools scored. Lowest: 2.9/5.
Most tools are clearly distinct, with Mailchimp tools targeting different resources (audiences, campaigns, members) and memory/query tools having separate purposes. However, 'ask_pipeworx' and 'discover_tools' both involve finding information, potentially causing some confusion.
Mailchimp tools use a consistent 'mailchimp_{verb}_{noun}' pattern, but memory tools use different verbs ('forget', 'recall', 'remember') and 'ask_pipeworx' and 'discover_tools' break the pattern entirely, mixing conventions.
10 tools is well-scoped for a Mailchimp integration that includes audience, campaign, and member management plus memory/query utilities. Each tool has a clear role, and the count feels appropriate.
The Mailchimp subset covers basic read and list operations but lacks create, update, or delete actions for audiences, campaigns, or members, which would be needed for full lifecycle management. Memory tools are complete, but the domain feels incomplete.
Available Tools
10 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description fully discloses that Pipeworx selects the right tool, fills arguments, and returns results. No annotations provided, so description carries full burden and does so effectively.
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?
Three concise sentences front-loaded with purpose, followed by examples. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is complete for a single-param tool with no output schema; it explains behavior and usage. Minor gap: no mention of limitations or error handling, but acceptable given simplicity.
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 description adds context on how to use the single parameter ('describe what you need') with examples, going beyond the schema's minimal description.
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 uses specific verbs ('ask', 'picks', 'fills', 'returns') and clearly states the tool answers natural language questions by selecting the best data source. It distinguishes from siblings by acting as a meta-tool that abstracts away other 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?
Description explicitly says to describe needs in plain English and provides examples. However, no guidance on when not to use or alternatives, but the tool is designed to be the primary entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool searches by natural language, returns relevant tools with names and descriptions, and is intended for discovery. Without annotations, this is sufficient, though it could mention that it does not execute tools or provide detailed usage beyond search results.
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?
Three sentences: first states the purpose, second adds return value details, third gives explicit usage guidance. No fluff, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search/discovery tool with no output schema, the description is complete: it explains what it does, what it returns, and when to use it. With 2 parameters and simple behavior, no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a natural language query example for the 'query' parameter, adding context beyond the schema description. The 'limit' parameter is only mentioned in the schema; the description does not add extra meaning, but schema coverage is 100%, so baseline is 3. The example earns an extra point.
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 'Search', the resource 'Pipeworx tool catalog', and the specific behavior 'by describing what you need'. It also distinguishes the tool from siblings by recommending it as a first step when many tools are available.
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 explicitly says 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task', providing clear guidance on when to use it and its role in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetAInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
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 states 'delete' which implies destructive action, but does not disclose whether deletion is irreversible, cascading effects, or required permissions. Adequate for a simple key-based delete.
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, minimal and direct. No wasted words.
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 (one required parameter, no output schema), the description is nearly complete. It explains what it does and how to specify the memory. Could mention if the key is case-sensitive or if it returns confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single required parameter 'key' described as 'Memory key to delete'. The description does not add new semantics beyond the schema, so 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 verb 'delete' and the resource 'stored memory', with 'by key' specifying the identifier. It distinguishes itself from sibling tools like 'remember' (store) and 'recall' (retrieve).
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 provided. The tool name and description imply a simple deletion action, but without context on when to forget versus other memory operations, guidance is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mailchimp_get_audienceCInspect
Get detailed settings and stats for a specific audience. Pass the audience ID (e.g., "abc123def456"). Returns name, member count, engagement metrics, and configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| _apiKey | Yes | Mailchimp API key | |
| list_id | Yes | Audience/list ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states it returns name, stats, and settings, but does not mention whether it is read-only, any rate limits, or error conditions. The mutation intent is not clear (read operation implied but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with key information. No fluff, but could include more details on return format without becoming too long.
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 incomplete. It does not explain the structure of the returned details, pagination, or error handling. For a tool with only 2 parameters, it should provide more context about what 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?
Schema coverage is 100%, so parameters are documented. The description adds no extra meaning beyond the schema; it simply says 'by ID' which matches the list_id 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 it gets details of a Mailchimp audience by ID, specifying return fields (name, stats, settings). This distinguishes it from sibling tools like mailchimp_list_audiences which lists all audiences.
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 mailchimp_list_audiences. No mention of prerequisites (e.g., needing to have list_id from list operation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mailchimp_get_campaignBInspect
Get full details of a campaign by ID (e.g., "abc123def456"). Returns settings, tracking configuration, performance stats, and send history.
| Name | Required | Description | Default |
|---|---|---|---|
| _apiKey | Yes | Mailchimp API key | |
| campaign_id | Yes | Campaign ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so description carries the burden. It states it returns 'campaign settings, tracking, and report summary', which gives some behavioral insight into what fields are returned. However, it doesn't disclose side effects (likely none), authentication requirements beyond the apiKey parameter, or any rate limits. With no annotations, a score of 3 is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose and the second lists return contents. No wasted words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema, no nested objects), the description is reasonably complete. It explains what it gets and the categories of returned data. Could be improved by noting that it requires a valid campaign_id from mailchimp_list_campaigns.
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 descriptions for both parameters ('Mailchimp API key' and 'Campaign ID'). The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate when schema already documents parameters well.
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 'Get details of a specific Mailchimp campaign by ID', which is a specific verb ('Get') and resource ('campaign details'). It distinguishes from siblings like mailchimp_list_campaigns (list vs. get) and mailchimp_get_audience (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. For example, it doesn't mention that you need to call mailchimp_list_campaigns first to get the campaign_id. The context of 'by ID' implies it's for a specific campaign, but no when-not-to-use or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mailchimp_list_audiencesAInspect
View all audiences in your account. Returns audience names, member counts, and engagement stats. Use mailchimp_get_audience for detailed settings.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of audiences to return (default 10, max 1000) | |
| offset | No | Offset for pagination (default 0) | |
| _apiKey | Yes | Mailchimp API key (ends with -dc, e.g., abc123-us21) |
Tool Definition Quality
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 returns 'audience name, member count, and stats', which gives some behavioral insight but does not disclose potential pagination limits (though count/offset are in schema) or any rate limiting or authentication details beyond the schema's apiKey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and key return fields. It is concise and to the point, with no unnecessary words.
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 is a list operation with no output schema and 3 parameters, the description is adequate but could be improved by mentioning pagination behavior or typical use cases. It covers the essential information but lacks depth for a fully self-contained description.
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 parameters are well-documented in the schema. The description does not add additional semantics beyond the schema; it simply states the overall purpose. 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 'List all audiences (lists) in your Mailchimp account' with a specific verb and resource. It differentiates from siblings like mailchimp_get_audience by indicating a list operation with summary stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all audiences, but no explicit when-to-use or alternatives are given. Siblings like mailchimp_get_audience suggest a more detailed single audience retrieval, but the description does not guide when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mailchimp_list_campaignsBInspect
View all email campaigns. Returns title, type (e.g., "regular", "automation"), status, and send timestamps. Use mailchimp_get_campaign for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of campaigns to return (default 10, max 1000) | |
| offset | No | Offset for pagination (default 0) | |
| status | No | Filter by status: save, paused, schedule, sending, sent | |
| _apiKey | Yes | Mailchimp API key |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the burden. It discloses that campaigns are listed and returns specific fields, but does not mention mutability (likely read-only), rate limits, or authentication details beyond the _apiKey parameter. The description is adequate but not exhaustive.
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: one sentence stating the purpose and one sentence listing returned fields. No wasted words.
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 that there is no output schema, the description does not fully explain the return structure (e.g., whether it's an array, pagination details). However, the tool is relatively simple and the schema covers parameters well. The description is minimally complete but could mention pagination or max count.
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 baseline is 3. The description adds no additional parameter meaning beyond the schema's own descriptions. For example, 'status' filter values are already listed in 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 the tool lists email campaigns from a Mailchimp account and specifies the returned fields (title, type, status, send time). This differentiates it from siblings like mailchimp_get_campaign (single campaign) and mailchimp_list_audiences (audiences).
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 does not explicitly state when to use this tool versus alternatives. However, the sibling names provide implicit context: use this for listing campaigns, while mailchimp_get_campaign is for a specific campaign. No guidance on filtering or prerequisites is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mailchimp_list_membersBInspect
Get subscribers in an audience by ID (e.g., "abc123def456"). Returns email addresses, subscription status, and custom merge fields.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of members to return (default 10, max 1000) | |
| offset | No | Offset for pagination (default 0) | |
| status | No | Filter by status: subscribed, unsubscribed, cleaned, pending, transactional | |
| _apiKey | Yes | Mailchimp API key | |
| list_id | Yes | Audience/list ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions returns (email, status, merge fields) and implies a read operation. However, it does not mention pagination behavior beyond schema hints, rate limits, or authorization requirements beyond the API key.
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 covering purpose and return fields. No fluff, but could be slightly more structured (e.g., separate sentence for returned fields).
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 5 parameters, full schema coverage, no output schema, and no annotations, the description is adequate but minimal. It explains the core function but lacks details on pagination, filtering behavior, and error conditions.
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 extra meaning beyond the schema, so 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 uses specific verbs and resources: 'List members (subscribers) of a specific Mailchimp audience.' It also specifies returned fields (email, status, merge fields), clearly distinguishing it from sibling tools like mailchimp_list_audiences and mailchimp_list_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing subscribers but does not explicitly state when to use this tool vs alternatives. It lacks guidance on prerequisites (e.g., list_id required) or situations where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains that memories are stored 'in the session or in previous sessions', providing context about persistence. No annotations provided, so description carries full burden; it adds value by clarifying scope. Would benefit from noting any size limits or expiration, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence states action and dual behavior, second provides usage context. Front-loaded with key information.
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 optional parameter and no output schema, the description is complete enough. It explains behavior with and without key. Could mention return format, but not essential given the tool's simplicity.
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 a single parameter 'key' described as 'Memory key to retrieve (omit to list all keys)'. Description adds context about retrieval vs listing, complementing schema well. No additional param info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a stored memory by key or lists all memories when key is omitted, using specific verb 'Retrieve' and resource 'memory'. Distinguishes from sibling tools like 'remember' and 'forget'.
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?
Explicitly states when to use (retrieve context saved earlier) and provides clear usage pattern: omit key to list all, include key for specific memory. Does not mention alternatives but given the tool's specific function, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral differences between authenticated (persistent) and anonymous (24-hour) sessions, which is useful context beyond the schema. No contradictions with annotations (none 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?
Three sentences, no fluff. First sentence defines action, second gives use cases, third adds behavioral nuance. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 2 required string params and no output schema. Description fully covers purpose, usage guidance, and behavioral notes. No gaps given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds practical context like example keys (subject_property, target_ticker) and value types (findings, addresses). This enriches the bare schema without redundancy.
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?
Clearly states it stores a key-value pair in session memory, with explicit use cases like saving findings, preferences, or context across calls. Distinguishes itself from siblings like 'forget' (deletion) and 'recall' (retrieval).
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?
Explicitly says when to use (save intermediate findings, user preferences, context across tool calls) but does not explicitly mention when not to use or alternatives. However, siblings like 'recall' and 'forget' imply complementary use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!