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 4/5 across 13 of 13 tools scored. Lowest: 2.9/5.
The ask_pipeworx tool acts as a meta-tool that can answer questions using other tools, creating overlap and uncertainty about when to use it versus specific tools like resolve_entity or compare_entities. Additionally, memory tools (remember/recall/forget) seem unrelated to the Mailchimp domain, further blurring the tool set's purpose.
Tool names mix conventions: some use 'mailchimp_' prefix with underscores, others use plain verbs like 'forget' or noun phrases like 'discover_tools', and 'pipeworx_feedback' follows a different pattern. No consistent naming scheme is evident.
With 13 tools, the count is reasonable, but the server tries to serve two distinct domains (Mailchimp and Pipeworx) plus memory tools, making the set feel scattershot rather than focused. The count itself is borderline acceptable.
For the stated Mailchimp domain, only read operations are provided (list_audiences, get_audience, list_campaigns, get_campaign, list_members). No create, update, or delete operations exist, leaving significant gaps for typical Mailchimp workflows.
Available Tools
15 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.
compare_entitiesAInspect
Compare 2–5 entities side by side in one call. type="company": revenue, net income, cash, long-term debt from SEC EDGAR. type="drug": adverse-event report count, FDA approval count, active trial count. Returns paired data + pipeworx:// resource URIs. Replaces 8–15 sequential agent calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| values | Yes | For company: 2–5 tickers/CIKs (e.g., ["AAPL","MSFT"]). For drug: 2–5 names (e.g., ["ozempic","mounjaro"]). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses data sources (SEC EDGAR, FDA) and return type (paired data + URIs) but omits whether the operation is read-only, side effects, or rate limits. Adequate but not fully 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?
Three concise sentences with front-loaded purpose. No redundant information; each sentence provides distinct value: purpose, per-type details, and return format/efficiency benefit.
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 sufficiently outlines return data (paired data + URIs) and key fields per entity type. It could detail the output structure further, but for a comparison tool with clear schema, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear enum and array constraints. The description adds value by explaining what data is retrieved for each type (e.g., 'revenue, net income' for companies), going beyond the schema's basic parameter descriptions.
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 compares 2–5 entities side by side, differentiating by entity type (company or drug) and listing the specific data points compared. It distinguishes itself from siblings by highlighting the efficiency gain of replacing 8–15 sequential calls.
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 parallel comparison of entities, noting it replaces multiple sequential calls. However, it does not explicitly state when not to use it or mention alternative tools like ask_pipeworx for single-entity queries.
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.
entity_profileAInspect
Full profile of an entity across every relevant Pipeworx pack in one call. type="company": SEC filings (recent), latest revenue/income/cash from XBRL, USPTO patents (assignee match), recent news (GDELT), and LEI (GLEIF). Returns pipeworx:// citation URIs for everything. Replaces 10–15 sequential agent calls. For federal contracts call usa_recipient_profile directly (too slow to bundle).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today; person/place coming soon. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). Names not supported — use resolve_entity first if you only have a name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the tool returns citation URIs and replaces many sequential calls, but does not mention rate limits, authentication requirements, or error behavior. Adequate but missing some behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. Each sentence adds essential information without redundancy. It effectively communicates the tool's value and limitations in just a few lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple data sources) and simple input schema, the description covers what data is returned (SEC filings, XBRL, patents, news, LEI) and output format (pipeworx:// URIs). It also mentions it replaces many calls. However, it could mention if there are any limits on the response or additional usage notes. Still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining that type is only 'company' for now, and that value can be a ticker or CIK, explicitly noting that names are not supported and directing to resolve_entity. This exceeds the schema descriptions.
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 returns a full profile of an entity across multiple Pipeworx packs, with specific details for company type. It distinguishes itself from siblings like resolve_entity and usa_recipient_profile, making its purpose unmistakable.
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 (comprehensive entity profile) and when not to (federal contracts, use usa_recipient_profile directly). Also advises using resolve_entity first if only a name is available, providing clear guidance on alternatives.
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Audience/list ID |
| name | No | Audience name |
| stats | No | Audience statistics |
| _links | No | HAL links |
| contact | No | Contact information |
| modules | No | Enabled modules |
| visibility | No | Visibility setting |
| has_welcome | No | Welcome automation enabled |
| list_rating | No | List rating/reputation score |
| date_created | No | ISO date when audience was created |
| double_optin | No | Double opt-in enabled |
| beamer_address | No | Beamer address |
| use_archive_bar | No | Use archive bar |
| campaign_defaults | No | Default campaign settings |
| email_type_option | No | Email type option enabled |
| subscribe_url_long | No | Long subscribe URL |
| notify_on_subscribe | No | Notification email on subscribe |
| permission_reminder | No | Permission reminder text |
| subscribe_url_short | No | Short subscribe URL |
| marketing_permissions | No | Marketing permissions enabled |
| notify_on_unsubscribe | No | Notification email on unsubscribe |
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | Campaign ID |
| type | No | Campaign type |
| title | No | Campaign title |
| _links | No | HAL links |
| status | No | Campaign status |
| web_id | No | Web ID |
| list_id | No | Associated audience/list ID |
| reply_to | No | Reply-to email |
| settings | No | Campaign settings |
| tracking | No | Tracking configuration |
| from_name | No | From name |
| send_time | No | Send time ISO date |
| archive_url | No | Archive URL |
| create_time | No | ISO date when campaign was created |
| emails_sent | No | Number of emails sent |
| template_id | No | Template ID |
| preview_text | No | Preview text |
| subject_line | No | Email subject line |
| report_summary | No | Performance summary statistics |
| long_archive_url | No | Long archive URL |
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) |
Output Schema
| Name | Required | Description |
|---|---|---|
| lists | No | Array of audiences |
| _links | No | HAL links |
| constraints | No | API constraints |
| total_items | No | Total number of audiences |
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| _links | No | HAL links |
| campaigns | No | Array of campaigns |
| total_items | No | Total number of campaigns |
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| _links | No | HAL links |
| list_id | No | Associated audience/list ID |
| members | No | Array of audience members |
| total_items | No | Total number of members |
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.
pipeworx_feedbackAInspect
Send feedback to the Pipeworx team. Use for bug reports, feature requests, missing data, or praise. Describe what you tried in terms of Pipeworx tools/data — do not include the end-user's prompt verbatim. Rate-limited to 5 messages per identifier per day. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | bug = something broke or returned wrong data. feature = a new tool or capability you wish existed. data_gap = data Pipeworx does not currently expose. praise = positive note. other = anything else. | |
| context | No | Optional structured context: which tool, pack, or vertical this relates to. | |
| message | Yes | Your feedback in plain text. Be specific (which tool, what error, what data was missing). 1-2 sentences typical, 2000 chars max. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It includes a rate limit (5 messages per identifier per day) and states the tool is 'Free.' These are key constraints. However, it does not detail what happens to the feedback after submission (e.g., storage, visibility) or what the response looks like, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three sentences that front-load the purpose, immediately list use cases with a key usage guideline, and end with a behavioral constraint. Every sentence is necessary and well-organized.
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 and the absence of an output schema, the description provides adequate context for correct invocation: purpose, parameter guidance, rate limit, and what not to include. It does not explain the return value or confirmation behavior, but for a feedback tool this is minor. The description is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already describes all parameters (type enum, context object, message length) with clear descriptions. The description adds no new parameter-specific information beyond restating the message length limit, so 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 starts with a clear verb+resource ('Send feedback to the Pipeworx team') and explicitly lists the types of feedback (bug reports, feature requests, missing data, praise). This distinguishes the tool from siblings like ask_pipeworx (for queries) or discover_tools (for exploration).
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 specifies exactly when to use the tool (for bug reports, feature requests, etc.) and provides a critical 'do not' (avoid including the end-user's prompt verbatim). While it does not explicitly name alternatives, the intended use is clearly separated from querying or discovery tools among siblings.
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.
recent_changesAInspect
What's new about an entity since a given point in time. type="company": fans out to SEC EDGAR (filings since), GDELT (news mentions in window), USPTO (patents granted since), in parallel. since accepts ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Returns structured changes + total_changes count + pipeworx:// URIs for each item. Use for "brief me on what happened with X" or change-monitoring workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today. | |
| since | Yes | Window start — ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Use "30d" or "1m" for typical monitoring. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains the parallel fan-out to three sources, the return format (structured changes + count + URIs), and the accepted date formats. For a read-only tool, this is transparent, though it does not mention error handling or limitations (e.g., only company type supported).
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 four sentences long, front-loaded with the core purpose, and every sentence adds information. There is no redundancy or fluff.
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 annotations and no output schema, the description covers inputs, behavior, output structure, and use cases. It is self-contained for a data retrieval tool, though it could mention potential errors for invalid inputs. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning: it explains the fan-out behavior for type='company', gives examples for 'since' (ISO and relative), and suggests typical values like '30d' or '1m'. This goes beyond the basic schema descriptions.
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 that the tool retrieves 'what's new about an entity since a given point in time' and specifies that for type='company' it fans out to SEC EDGAR, GDELT, and USPTO in parallel. It distinguishes itself from sibling tools like entity_profile (static profile) and compare_entities (comparison) by focusing on change monitoring.
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 provides use cases: 'brief me on what happened with X' or change-monitoring workflows. It explains the format of the 'since' parameter (ISO date or relative). However, it does not explicitly state when not to use the tool or mention alternatives among siblings.
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.
resolve_entityAInspect
Resolve an entity to canonical IDs across Pipeworx data sources in a single call. Supports type="company" (ticker/CIK/name → SEC EDGAR identity) and type="drug" (brand or generic name → RxCUI + ingredient + brand). Returns IDs and pipeworx:// resource URIs for stable citation. Replaces 2–3 lookup calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| value | Yes | For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., "ozempic", "metformin"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is a single call and returns specific fields, but it does not cover error conditions, rate limits, or authentication requirements. The description implies a read-only operation but lacks comprehensive 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?
The description is two sentences, front-loading the purpose and version details. Every word earns its place, with no redundancy or filler.
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 simplicity of the tool (2 parameters, no output schema, no annotations), the description provides a complete picture: what it does, how to use, and what it returns. It could be improved by describing the response format, but overall it is sufficient.
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. The description adds concrete examples (e.g., 'AAPL', '0000320193', 'Apple') and clarifies that v1 supports only 'company', which enhances understanding 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 the verb 'resolve' and the resource 'entity', specifying the outcome of getting canonical IDs. It also distinguishes itself by noting it replaces 2-3 lookup calls, differentiating from sibling tools that may require multiple steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use (when you have a ticker, CIK, or company name) and gives examples. However, it does not explicitly state when not to use or mention specific alternatives among siblings.
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!