agent-cold-email
Server Details
Agent-native cold-email infrastructure: domains, mailboxes, warmup, sequences, replies via 17 tools
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- YS-projectcalc/agent-cold-email
- GitHub Stars
- 0
- Server Listing
- agent-cold-email
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/5 across 17 of 17 tools scored. Lowest: 3.8/5.
Most tools have clearly distinct purposes, though campaign_results and metrics serve similar roles (single vs. account-wide), and pause/pause_all are overlapping but differentiated by scope. Overall, agents can reliably distinguish tools.
Tool names are mostly verb_noun (e.g., launch_campaign, configure_dashboard) or noun for data retrieval (e.g., inbox, metrics). The convention is largely consistent with snake_case, but a few nouns like 'activity' and 'thread' are not imperative.
17 tools cover the full cold email workflow without unnecessary duplication. The number feels well-scoped for provisioning, campaign management, inbox triage, and monitoring.
The tool set covers core workflows (setup, launch, monitor, triage) but lacks a resume tool for paused campaigns and does not allow editing campaign steps or managing leads, representing notable gaps.
Available Tools
17 toolsaccountAInspect
Account overview: brand, plan, status, billingState, resource counts, usageCents, quota, deliverability (loop state: paused/throttled mailboxes, burning domains, auto-replacements, recentActions[]), and teardown (reclaim summary once canceled, else null). Use metrics for counts, infrastructure_status for per-mailbox health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It implies a read-only overview but does not explicitly state if the tool mutates state or requires special permissions. It mentions 'teardown (reclaim summary once canceled, else null)' hinting at destructive context but does not clarify operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence well-packed with information, but slightly dense. It front-loads the overview and references other tools efficiently, though could benefit from bullet points for readability.
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 comprehensively lists all returned fields (brand, plan, status, billingState, resource counts, usageCents, quota, deliverability details, teardown) and cross-references sibling tools for specialized data, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage. No parameter documentation is needed, and the description focuses on return data instead, which 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 tool provides an 'Account overview' listing specific fields (brand, plan, status, etc.) and distinguishes from siblings like 'metrics' and 'infrastructure_status' by instructing when to use those instead.
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 tells when to use alternatives: 'Use metrics for counts, infrastructure_status for per-mailbox health.' This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
activityAInspect
Unified activity feed: campaign events (sent/reply/bounce/...) merged with deliverability loop actions (pause/throttle/replace-domain). Cursor-paginated → { items[], nextCursor }; each item { id, kind:'event'|'deliverability', label, ts, target, detail }. Filters: kind, limit (default 50, max 200). Use inbox for replies only.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| cursor | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses pagination (cursor-based, returns items and nextCursor), item structure (id, kind, label, ts, target, detail), and merging of two event types. Does not discuss authentication or rate limits, but for a read feed this is acceptable.
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?
Concise single paragraph with clear structure: purpose, pagination behavior, item format, filter details, and usage hint. Every sentence adds value, no waste.
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 adequately explains the return format and filtering. Lacks error handling or rate limits, but for a simple read feed this is sufficient. Distinguishes well from sibling tools.
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 0%, but the description explains all three parameters: kind (lists enum values 'event' and 'deliverability'), limit (default 50, max 200), and cursor (implied by pagination description). This goes well beyond the bare 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?
Clearly states it is a unified activity feed merging campaign events and deliverability actions. Specifies cursor-pagination and item structure. Differentiates from sibling 'inbox' for replies.
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?
Provides a clear alternative: 'Use inbox for replies only.' Mentions filters: kind and limit. Lacks explicit when-not-to-use, but the alternative is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
campaign_resultsAInspect
Outcome counts for ONE campaign. Input: campaignId (from launch_campaign). Returns { campaignId, sent, reply, bounce, complaint, unsubscribe, failed, soft_bounce } — bounce = HARD only, soft_bounce separate, opens not tracked. 404 if unknown. Use metrics for account-wide totals, list_campaigns for every campaign at once.
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | The campaign id returned by launch_campaign. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses exact return fields, clarifies bounce definitions (HARD vs soft_bounce), states opens not tracked, and mentions 404. Could add idempotency or auth requirements, but overall 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 efficient sentences. Front-loaded with purpose, followed by return structure and usage notes. No 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 simplicity (1 param, no output schema), description fully covers what the tool does, what it returns, error cases, and how it relates to sibling tools. Complete for its 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 the schema already describes campaignId as 'The campaign id returned by launch_campaign.' The description says the same: 'Input: campaignId (from launch_campaign).' No new semantic value added beyond 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?
Description clearly states 'Outcome counts for ONE campaign.' The verb+resource pair is specific. It distinguishes from siblings by naming alternatives: 'Use metrics for account-wide totals, list_campaigns for every campaign at once.'
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 input: campaignId from launch_campaign, and gives when-not-to-use scenarios (metrics for totals, list_campaigns for all campaigns). Also notes 404 if unknown, guiding error handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
configure_dashboardAInspect
Write a saved dashboard view. action = create (needs name+layout) | update (needs id+rev+layout; optional name renames) | promote (id → default) | delete (id). update is rev-CAS: a stale rev returns { currentRev, currentLayout } to rebase and retry. Optional note. Read the current rev+layout via get_dashboard first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Required for update/promote/delete. | |
| rev | No | Required for update — the rev this edit is based on; stale vs. the view's CURRENT rev returns a structured conflict with currentRev/currentLayout to rebase onto. | |
| name | No | Required for create. Optional for update — pass it to rename the view; omit to leave the name unchanged. | |
| note | No | Optional human-readable note recorded alongside this edit (edited_by_note). | |
| action | Yes | ||
| layout | No | Required for create/update. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the rev-CAS mechanism and conflict response for updates, and mentions the optional note. However, it does not explain the effects of delete or promote actions (e.g., what happens to default view), leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 3 lines) and front-loaded with the core action list. The pipe-separated action definitions are efficient, though slightly dense. Every sentence adds value, but could benefit from clearer formatting for readability.
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 (6 params, nested layout, no output schema), the description covers the main actions, conflict handling, and prerequisite reading via get_dashboard. It lacks details on success returns and error cases beyond conflict, but is fairly complete for a mutation tool.
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 83%, and the description adds nuance: update's optional rename, conflict detail for rev, and note's purpose ('edited_by_note'). It provides meaning beyond the schema, though not exhaustive.
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 'Write a saved dashboard view' and enumerates four distinct actions (create, update, promote, delete), providing a specific verb+resource. It distinguishes itself from the sibling get_dashboard by implying that reading should be done via that tool.
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 advises reading current rev/layout via get_dashboard first, and explains the parameter requirements for each action (e.g., 'create (needs name+layout)', 'update (needs id+rev+layout; optional name renames)'). It also describes the conflict handling for stale revs, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dashboardAInspect
Read saved dashboard views. No id → list all: [{ id, name, isDefault, rev, editedBy }]. With id → that view's full layout + rev (pass this rev as the CAS base to configure_dashboard update). Views are both agent- and human-editable; write them with configure_dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Omit to list every saved view (summary); pass a view id for its full layout + rev. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears transparency. Explains read-only nature, return formats for both cases, and that views are editable by agents/humans via configure_dashboard.
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 key info, no redundant phrases. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains return values for both cases. Also mentions relationship with configure_dashboard, making it complete for a simple read tool.
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 description adds meaningful context: explains the behavior difference based on id presence and the purpose of rev, which goes beyond 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?
Description clearly states it reads saved dashboard views. Distinguishes between listing all (no id) and getting full layout (with id), which differentiates from sibling tool configure_dashboard for writing.
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?
Provides clear guidance on when to omit id (list) vs include id (full view), and how to use the returned rev with configure_dashboard. Could be stronger by explicitly stating when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inboxAInspect
Unified reply inbox across mailboxes. Cursor-paginated → { threads[], nextCursor }; each row: threadId, campaignName, leadEmail, subject, mailboxEmail, label, lastEventType, markStatus. Filters: mailbox, campaign, label, read, includeNonreply (bounces/OOO, default true), archived (exclude|include|only). Use thread for one thread's history.
| Name | Required | Description | Default |
|---|---|---|---|
| read | No | ||
| label | No | ||
| limit | No | ||
| cursor | No | ||
| mailbox | No | ||
| archived | No | exclude | |
| campaign | No | ||
| includeNonreply | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes pagination (cursor-paginated) and response structure, adding context beyond schema. No annotations, but description covers read-only behavior implicitly; no mention of side effects or permissions.
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: purpose, response format, filters. No redundancy, front-loaded with core info.
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?
Covers purpose, pagination, row fields, and filters. Lacks limit description and authentication context, but sufficient for a read tool with good sibling differentiation.
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?
Despite 0% schema coverage, description explains most filters (mailbox, campaign, label, read, includeNonreply, archived) and their defaults. Missing limit and cursor details, but cursor is implied by pagination.
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 returns a 'unified reply inbox across mailboxes' with pagination and row structure. Differentiates from sibling 'thread' by noting 'Use thread for one thread's history.'
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 advises when to use thread instead, implying when to use inbox. Lists filters, but no explicit 'when not to use' beyond the single sibling distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
infrastructure_statusAInspect
Warmup + provisioning progress per mailbox. Returns { domains, mailboxes, sendReady, mailboxHealth[] }; each mailbox: warmupDay, dailyCap, sentToday, sendReady, delivStatus (healthy/throttled/paused), complaint/bounce/softBounce rates, reputationScore + placementRate, lastPolledAt. Use account/metrics for account-wide rollups.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It transparently details the return structure and fields, implying a read-only operation. However, it does not explicitly state that there are no side effects or mention any authorization or rate limits, which would make it a 5.
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 concise sentences with no wasted words. First sentence summarizes purpose and output type, second details fields and usage guidance. Every sentence earns its place.
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 tool with no input schema and no output schema, the description fully documents the return structure and field semantics. It also ties in sibling context. No gaps remain for an agent to invoke 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?
No parameters exist, and schema coverage is 100%. Per calibration rules, baseline is 4. Description adds no parameter info because none is 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 it shows warmup and provisioning progress per mailbox, and lists return fields. It distinguishes from sibling tools by specifying 'Use account/metrics for account-wide rollups', giving a specific verb-less but clear purpose.
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 tells when not to use this tool by directing to account/metrics for account-wide data. This provides clear context for selecting the right tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
label_threadAInspect
Set or clear a triage LABEL on an inbox thread — the same chip the dashboard shows. Inputs: threadId, label (string; pass label:null to clear). Distinct from mark (read/unread/archived state): a label is a free-form category, not a read flag. Filterable via inbox's label param.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | ||
| threadId | Yes | The thread id, e.g. from inbox() or campaign events. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool sets or clears a label and how to clear via null. However, it does not specify whether a label replaces or appends to existing labels (multiple labels?), nor any side effects. 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?
Two concise sentences plus one additional sentence about filterability. Front-loaded with main purpose, no wasted words. 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?
Given low complexity, 2 parameters, no output schema, and no annotations, description covers purpose, parameters, distinction from sibling, and filtering. Missing detail on whether labels are additive or replaceable, but overall mostly 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 50% (only threadId described). Description adds meaning for the 'label' parameter beyond schema by explaining how to use null to clear. For threadId, schema already provides description, so description adds value by grouping parameters together.
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 'Set or clear a triage LABEL on an inbox thread', specifying the verb (set/clear) and resource (label on thread). It distinguishes from the sibling tool 'mark' by explaining the difference between a label and a read flag, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use the tool (set/clear labels), explicitly distinguishes from the 'mark' tool, and mentions the label is filterable via inbox's label param. No explicit when-not or alternatives, but the distinction is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
launch_campaignAInspect
Create and activate a campaign on a lead list. You supply name, offer, leads[], sequence[] (per step: subject, body, delayDays), sendWindow, timezone, stopOnReply — the platform does not write copy. Steps schedule up front; suppressed leads are skipped. Returns { campaignId }. Resend the same idempotencyKey on retry to avoid a duplicate.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| leads | Yes | ||
| offer | Yes | ||
| sequence | Yes | ||
| timezone | No | UTC | |
| sendWindow | No | ||
| stopOnReply | No | ||
| idempotencyKey | No | Optional idempotency key: resend the SAME key when retrying this call so a dropped-response retry is not applied twice (no duplicate campaign/provision/send). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: platform does not write copy, steps scheduled up front, suppressed leads skipped, returns campaignId, idempotencyKey for retry. Missing details on error handling or rate limits.
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 no wasted words: first sentence defines action and parameters, second adds behavioral notes, third explains idempotency. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter overview, key behaviors, and return value. Missing details on scheduling mechanics (timezone, sendWindow effects), validation or error scenarios, and output schema not provided. Adequate but has gaps.
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 13% (low), and the description adds high-level meaning for name, offer, leads, sequence, sendWindow, timezone, stopOnReply, and idempotencyKey. It explains sequence structure but omits details on optional fields, default values, or constraints for some parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates and activates a campaign on a lead list, specifying required components (name, offer, leads, sequence). It implies differentiation from siblings like list_campaigns and campaign_results, but does not explicitly distinguish them.
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 lists what parameters to supply and mentions idempotencyKey for retries, implying use when creating/activating a campaign. It provides clear context but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_campaignsAInspect
List every campaign at once: [{ campaignId, name, status, counts{sent,reply,bounce,complaint,unsubscribe,failed,soft_bounce} }], newest first — no per-campaign lookup needed. Use campaign_results for one campaign's counts, metrics for account-wide totals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format, ordering, and that no per-campaign lookup is needed. However, it does not mention potential pagination or rate limits.
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, well-structured, front-loaded with the output format. 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?
No output schema, but description fully specifies the return value. Tool is simple (list all), and description covers key aspects. References sibling tools for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% (empty). Baseline 4 is appropriate since description adds value by explaining the output.
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 lists all campaigns with specific fields and order (newest first). It distinguishes from sibling tools like campaign_results and metrics.
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 this tool (list every campaign) and when to use alternatives (campaign_results for one campaign, metrics for account-wide totals).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
markAInspect
Set a thread's READ-STATE for inbox triage. Inputs: threadId, status = 'read' | 'unread' | 'archived' (archived hides it from the default inbox; refetch with inbox archived='include'/'only'). Returns { marked: true }. 404 if unknown. This is the read/archive flag ONLY — use label_thread for a triage label chip, reply to respond.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| threadId | Yes | The thread id, e.g. from inbox() or campaign events. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains that 'archived' hides from default inbox, how to refetch with inbox parameter, mentions return value { marked: true }, and 404 for unknown threads. Clearly states it's only the read/archive flag.
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. First sentence states purpose. Second lists inputs and behavior. Third distinguishes from siblings. Front-loaded and no 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?
No output schema, but description covers return value and error (404). Distinguishes from siblings. Provides enough context for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 params with 50% coverage (only threadId has description). Description adds meaning: explains possible status values and their effects (read, unread, archived), and how to refetch archived threads. Also clarifies threadId source. Adds value beyond 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?
Description clearly states it sets a thread's READ-STATE for inbox triage. It uses specific verb 'set' and resource 'thread's READ-STATE'. It distinguishes from siblings label_thread and reply explicitly.
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 this tool (read/archive flag) and when not (use label_thread for labels, reply for responding). Provides clear guidance on refetching archived threads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
metricsAInspect
Account-wide outcome totals across ALL campaigns: { sent, reply, bounce, complaint, unsubscribe, failed, soft_bounce } — same shape as campaign_results but summed tenant-wide (bounce = hard only, opens not tracked). Use campaign_results for one campaign, list_campaigns per-campaign, or account for billing/quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that bounce is hard only, opens not tracked, and shape same as campaign_results. No annotations provided, but description adds sufficient behavioral context for a read-only aggregate.
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, no redundant words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a parameterless aggregate tool with clear output description and differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description need not add parameter info. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides account-wide outcome totals across all campaigns with specific metrics. Distinguishes from siblings like campaign_results and 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?
Explicitly tells when to use this tool vs alternatives: 'Use campaign_results for one campaign, list_campaigns per-campaign, or account for billing/quota.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pauseAInspect
Pause ONE campaign: its status → 'paused', so the tick schedules no further steps (already-sent mail is unaffected; there is no resume tool). Input: campaignId. Returns { paused: true }. 404 if not found. Use pause_all to pause every active campaign at once.
| Name | Required | Description | Default |
|---|---|---|---|
| campaignId | Yes | The campaign id returned by launch_campaign. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: status change, scheduler impact, no effect on sent mail, no resume capability, return value, and 404 error.
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, all essential, no wasted words. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides all necessary context: input, output, error handling, and behavioral notes.
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?
Single parameter campaignId is well-described in the schema (100% coverage). The description adds minimal extra meaning beyond naming the 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?
Clearly states the action ('Pause ONE campaign'), the effect on status and scheduler, and that sent mail is unaffected. Distinguishes from sibling pause_all.
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 mentions the absence of a resume tool and directs to pause_all for bulk pausing. Could be more explicit about alternatives but covers the main sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pause_allAInspect
Pause EVERY active campaign for the tenant at once (each active status → 'paused'; the tick then schedules no further sends). No inputs. Returns { pausedAll: true }. Use pause to pause a single campaign by id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the action: changes each active status to 'paused', no further sends, no inputs, and return value. Lacks details on reversibility or side effects, but sufficient for a simple batch operation.
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, front-loaded with key action, 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 no parameters and no output schema, description fully covers behavior, return value, and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; description confirms no inputs, which is adequate baseline 4.
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 explicitly states 'Pause EVERY active campaign for the tenant at once' and distinguishes from sibling 'pause' tool.
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?
Clearly indicates when to use (batch pause) and when not to ('Use pause to pause a single campaign').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replyAInspect
Send a reply on an existing thread, from the mailbox that sent it. Inputs: threadId, body. Returns { messageId }. Idempotent: identical retries collapse to one send — pass a stable idempotencyKey (else a body hash is used) so a dropped-response retry can't double-send. 404 if no sending mailbox is on record for the thread.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| threadId | Yes | The thread id, e.g. from inbox() or campaign events. | |
| idempotencyKey | No | Optional idempotency key: resend the SAME key when retrying this call so a dropped-response retry is not applied twice (no duplicate campaign/provision/send). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: idempotent execution via idempotency key or body hash, and the 404 error case. This goes beyond the schema, though it does not mention any side effects or permissions.
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, front-loaded purpose, no redundant information. Every sentence adds value: purpose, inputs/return, idempotency details, error condition.
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 explains the return value ({messageId}), idempotency, and a key error condition. It covers the essential context for a reply operation without being overly verbose.
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 67% (descriptions for threadId and idempotencyKey). The description lists inputs but adds only minimal extra meaning for body; the idempotency key context is useful. Baseline 3 is appropriate as the description does not fully compensate for the missing body 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?
The description clearly states the tool sends a reply on an existing thread from the sending mailbox, with a specific verb and resource. It distinguishes well from siblings like 'inbox' or 'thread' by indicating it operates on an existing thread from the sender's perspective.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'thread' or 'launch_campaign'. The only usage hint is the 404 error condition when no sending mailbox exists, but no direct comparison or condition-based selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
setup_infrastructureAInspect
Provision sending infrastructure: buy branded lookalike domains, create mailboxes, start warmup. Inputs: brand, primaryDomain, domains + inboxesEach counts, persona, physicalAddress, senderIdentity. Async — returns { jobId }; poll infrastructure_status for progress. Resend the same idempotencyKey on retry to avoid double-provisioning.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | ||
| domains | Yes | ||
| persona | Yes | ||
| inboxesEach | Yes | ||
| primaryDomain | Yes | ||
| idempotencyKey | No | Optional idempotency key: resend the SAME key when retrying this call so a dropped-response retry is not applied twice (no duplicate campaign/provision/send). | |
| senderIdentity | Yes | ||
| physicalAddress | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the async nature, return of jobId, and idempotency pattern to avoid double-provisioning. It does not address rate limits or authorization, but covers the key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. The second sentence provides essential usage details (async, jobId, idempotency). 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 complexity (8 parameters, async, no output schema), the description covers purpose, inputs, async behavior, idempotency, and polling guidance. It is sufficient for an agent to understand and use the tool 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 only 13% (only idempotencyKey documented). The description compensates by listing all parameters and clarifying that 'domains + inboxesEach counts' indicates quantities. It adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: provisioning sending infrastructure including buying domains, creating mailboxes, and starting warmup. It uses specific verbs and resource nouns, and distinguishes itself from sibling 'infrastructure_status' for polling.
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 that the tool is async, returns a jobId, and recommends polling infrastructure_status. It also explains idempotency key usage for retries. However, it does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
threadAInspect
Full message history for ONE thread. Input: threadId (from inbox). Returns { threadId, campaignId, leadId, leadEmail, mailboxEmail (null before first send), messages[] }, each message { type (sent/reply/bounce/...), ts, messageId, metadata }, oldest first. 404 if unknown. Use inbox to LIST threads; reply to respond; mark/label_thread to triage.
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | Yes | The thread id, e.g. from inbox() or campaign events. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format, ordering (oldest first), null mailboxEmail, and 404 error. Lacks explicit read-only statement but implied.
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 clear structure, front-loading purpose. Slightly dense but 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 simple tool (1 param, no output schema), the description fully explains output structure, error case, and ordering—everything an agent needs.
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 one param. Description adds context about where the threadId comes from ('from inbox' or campaign events), enhancing schema info.
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 'Full message history for ONE thread' with input and output details, and differentiates from siblings like inbox and reply.
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 tells when to use (get history for one thread) and when not, naming alternatives: inbox to list, reply to respond, mark/label_thread to triage.
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!
Your Connectors
Sign in to create a connector for this server.