keila-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. Tools are organized by resource type (campaign, contact, segment, sender, form) and action (create, get, list, update, delete, schedule, send), making it easy for an agent to select the correct one. Overlap is minimal, such as create_campaign and send_campaign being clearly separated in workflow.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with verbs like create, get, list, update, delete, schedule, and send paired with nouns like campaign, contact, segment, sender, and form. There are no deviations in style or convention, making the set predictable and readable.
Tool Count5/5
With 17 tools, the count is well-scoped for an email marketing platform, covering core CRUD operations for campaigns, contacts, and segments, plus essential utilities like listing senders and forms, and campaign-specific actions like scheduling and sending. Each tool earns its place without bloat or redundancy.
Completeness5/5
The tool surface provides complete CRUD/lifecycle coverage for the domain of email marketing. It includes create, get, list, update, and delete for campaigns, contacts, and segments, plus specialized actions like schedule_campaign and send_campaign, and supporting tools like list_senders and list_forms. There are no obvious gaps that would hinder agent workflows.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description only mentions basic return value without disclosing uniqueness constraints, idempotency, or error conditions like existing contact conflicts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Docstring format with Args/Returns sections is structured and concise with no redundant text, though extremely terse given context poverty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic CRUD operation with param list and return mention, but given zero schema descriptions and no annotations, lacks depth on behavioral edge cases and field constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Args section compensates for 0% schema description coverage by listing parameters and optionality, but provides minimal semantic detail beyond field names (e.g., no email format validation rules).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Create) and resource (contact) with system context (Keila), though lacks explicit differentiation from update_contact sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus update_contact, no prerequisites mentioned, and no error handling guidance for duplicate emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions return value ('updated contact record') but omits mutation safety details, error behavior (e.g., what if contact_id not found), side effects, or reversibility concerns critical for an update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Uses docstring format (Args/Returns) which is slightly verbose for MCP but information is front-loaded. The Returns section earns its place given the lack of output schema, though the structure could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for basic parameter documentation but insufficient for an update operation with no annotations. Missing error handling details, authentication requirements, and guidance on how to handle partial updates (unset vs unchanged fields).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates effectively by documenting all 4 parameters: contact_id includes an example format ('c_12345'), and optional fields (email, first_name, last_name) are explicitly marked with their purpose ('New email address', etc.).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Update) and resource (contact) clearly. The word 'existing' helps distinguish from the 'create_contact' sibling, though it doesn't explicitly contrast with other siblings like 'delete_contact' or 'get_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus 'create_contact' or prerequisites like needing to obtain a contact_id first. No mention of partial update semantics (PATCH vs PUT) or idempotency expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a 'Confirmation message' return value but fails to disclose critical destructive traits: whether deletion is permanent/irreversible, if it cascades to contacts/segments, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The Google-style docstring format (Args/Returns) is slightly verbose for MCP but efficiently organizes information without redundant sentences. Each section serves a distinct purpose, though a more narrative style might scan better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with an output schema, as it acknowledges the return value. However, it lacks safety warnings appropriate for a destructive operation and omits context about side effects (e.g., scheduled sends being cancelled).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting the single parameter with both semantic meaning ('The campaign ID') and a concrete example value ('mc_12345'), clarifying the expected format beyond the schema's bare type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('campaign'), providing a clear verb-object structure. However, it does not differentiate from siblings like 'update_campaign' (which could modify vs remove) or explain the permanence of the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., pausing vs deleting) or prerequisites (e.g., campaign state requirements). It merely states what the tool does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return value ('Confirmation message'), but fails to mention destructive permanence, side effects on related campaigns, or required permissions. Slightly better than having no behavioral info, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Uses an efficient docstring structure (Args/Returns) with minimal verbosity. Every line conveys necessary information. Slightly terse given the behavioral risks of deletion, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with described output, but insufficient for a destructive operation lacking annotations. Missing critical context about whether deletion is permanent, cascades to campaigns, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (property lacks description), but the tool description compensates effectively by providing an example ID format ('c_12345') in the Args section, clarifying the expected string pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Delete) and resource (contact) clearly. However, it is extremely minimal and lacks any scoping details (e.g., permanent deletion vs. archival) that would elevate it to a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus update_contact, nor prerequisites like verifying the contact exists. No mention of error conditions or irreversibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Compensates by detailing return structure (dict with 'data' containing campaign objects with specific fields), which is helpful. However, missing operational details like pagination behavior, result limits, or whether deleted/draft campaigns are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-section structure is appropriate: clear action statement followed by Returns documentation. The Returns section is necessary given lack of output schema. No redundant or filler text, though 'in Keila' could be assumed from context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes return structure adequately compensating for missing output schema. However, given the many sibling tools available, lacks contextual guidance for proper tool selection and doesn't address scale concerns (how many is 'all'?).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters with 100% coverage (empty object). Description correctly offers no parameter semantics since none exist to describe. Baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'List all campaigns in Keila' with clear verb and resource scope. However, lacks explicit distinction from sibling get_campaign (single retrieval) or mention that this returns unfiltered complete lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance, prerequisites, or alternatives. Doesn't advise when to use this versus get_campaign, or warn about potential performance implications of listing all campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Compensates partially by detailing return structure (dict with 'data' and 'meta') and contact fields. However, omits critical behavioral details: page size limits, whether results are sorted, read-only safety guarantees, and rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Uses structured Args/Returns format that efficiently organizes information. Front-loads the primary purpose. Slightly verbose construction but every sentence serves a purpose given the lack of output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 1-parameter read operation. Documents the return structure since no output schema exists. Missing: pagination size limits, sorting behavior, and maximum page bounds necessary for effective API consumption.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (page parameter lacks description field). Tool description successfully compensates by explaining 'page' is for 'pagination' and marking it 'optional', though could further clarify default behavior (e.g., first page when omitted).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('List') and resource ('contacts') with scope ('all... with pagination'). However, fails to differentiate from sibling 'get_contact' (presumably singular retrieval) or clarify when to use full list vs. individual fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus 'get_contact' for individual lookups, nor prerequisites like authentication requirements. No mention of when pagination is necessary or recommended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It partially satisfies this by documenting the return structure (dict with 'data' containing id, name, filter), but omits operational details like pagination behavior, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Brief two-sentence structure with minimal fluff. The 'Returns:' section is front-loaded and efficiently formatted, though slightly unconventional for MCP descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema exists, the description compensates by explaining return value structure. However, for a zero-parameter list operation with no annotations, it should clarify scope (e.g., 'all' vs paginated, user-scoped vs global) and empty result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, establishing baseline 4. Description correctly avoids unnecessary parameter documentation since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (List) and resource (contact segments) clearly. However, it does not differentiate from sibling list operations (list_contacts, list_campaigns) or clarify the relationship between segments and contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives (e.g., when to use list_segments vs list_contacts, or whether this requires prerequisites like existing contacts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Documents return structure ('dict with data') necessary since no output schema exists, but lacks critical behavioral context: pagination behavior, rate limits, and read-only safety confirmation (no annotations provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with purpose statement followed by return format, appropriate for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return structure is documented compensating for missing output schema, but lacks pagination guidance and domain-specific context expected for a list operation in an email marketing API (evidenced by campaign/contact siblings).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with 100% schema coverage. Description correctly adds no parameter details (none exist), meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('List') and specific resource ('signup forms'). Differentiates from siblings by resource type (campaigns, contacts, segments), though could better define what a 'signup form' is in this marketing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus sibling list operations (list_campaigns, list_contacts) or whether pagination/filtering is needed for large result sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only discloses return type ('The created segment record'). Missing critical behavioral details: whether the filter validates against existing contacts immediately, if segments are dynamic/static, error conditions, or side effects of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args/Returns sections. The filter examples are essential rather than wasteful given the opaque object type. Slightly formal with labeled sections but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic operation and parameters adequately, but lacks depth on segment behavior (dynamic evaluation vs static snapshot) and relationship to the contact database. Given nested object complexity and zero schema descriptions, needs more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema coverage. Provides human-readable descriptions for both parameters ('Segment name', 'Filter JSON object for matching contacts') and crucially includes concrete syntax examples for the complex nested filter object, clarifying the query language semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb (Create) + resource (contact segment) + mechanism (with a filter). Distinguishes effectively from siblings like create_contact (individual records) and create_campaign (messaging), establishing this creates filtered groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides rich filter syntax examples that implicitly guide usage, but lacks explicit when-to-use/when-not-to-use guidance versus alternatives like list_contacts or how segments relate to campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It adds valuable behavioral context by detailing the return value structure ('subject, body, sender, segment, and delivery status'), but omits safety characteristics (read-only implied by 'Fetch' but not stated), error conditions, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring-style structure (Args/Returns) is clear and front-loaded with the main purpose. Every sentence earns its place; however, the formatting is slightly mechanical and could be more integrated as prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one string parameter, no nested objects) and lack of output schema, the description provides adequate completeness by documenting both the input parameter (with example) and the expected return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by documenting the parameter in the Args section and providing a concrete format example ('mc_12345'), which adds essential semantic meaning missing from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Fetch'), resource ('campaign'), and scope ('single campaign by ID'). It implicitly distinguishes from sibling 'list_campaigns' by emphasizing 'single', though it does not explicitly name siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('by ID') suggesting it should be used when a specific campaign identifier is known, but provides no explicit guidance on when to prefer this over 'list_campaigns' or other campaign-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key business constraint (unsent-only updates) and mentions the return value ('The updated campaign record'), but fails to specify error behavior (what happens if campaign_id is invalid or already sent), idempotency properties, or whether null values clear fields versus leaving them unchanged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear Args/Returns sections. The constraint is front-loaded in the first sentence. No redundant words, though the Returns section is minimal given no output schema exists to supplement it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a partial-update mutation tool with 6 parameters. Given zero annotation coverage and no output schema, the description covers the essential parameters and basic return type, but lacks detail on error responses, detailed return structure, and complex validation rules that would be expected for a marketing campaign management tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. The Args section successfully documents all 6 parameters with concise semantic meaning (e.g., 'New subject line', 'New body content') and notes optionality, effectively filling the gap left by the undescribed schema. Deducted one point for minimal detail on validation rules or constraints beyond the example ID format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Update' with clear resource 'campaign'. The parenthetical constraint '(only unsent campaigns can be updated)' effectively distinguishes this from sibling tools like create_campaign, send_campaign, or schedule_campaign by defining the specific state (unsent) where this applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the critical limitation '(only unsent campaigns can be updated)', which defines when NOT to use the tool. However, it lacks explicit guidance on what to do instead if a sent campaign needs modification (e.g., 'create a new campaign instead') or when to prefer this over recreating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only partially succeeds. It discloses the return value ('updated campaign record with scheduled_for set') and datetime format requirements, but omits critical behavioral details like state transitions, idempotency, or valid campaign statuses for scheduling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure with clear Args and Returns sections. Every sentence earns its place: opening declaration, parameter documentation, and return value explanation with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good completeness for a 2-parameter tool without annotations or output schema: it explains the mutation behavior and return value. Minor gap: lacks mention of valid campaign states or error conditions (e.g., attempting to schedule already-sent campaigns).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by documenting both parameters with clear semantic meaning and format examples (e.g., 'mc_12345' for ID, ISO 8601 datetime with example).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Schedule) and resource (campaign) with scope (future delivery), effectively distinguishing it from sibling 'send_campaign' (immediate) and 'create_campaign' (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While 'future delivery' implicitly contrasts with immediate sending, the description lacks explicit guidance on when to use this versus 'send_campaign' or prerequisites (e.g., campaign must exist and be in a valid state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses the non-cascading nature (contacts preserved) and specifies the return value (Confirmation message), though it omits permission requirements or idempotency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient Args/Returns docstring structure. Main action is front-loaded, zero redundant text, and the structured parameter documentation adds value without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a single-parameter deletion tool. Covers operation scope, parameter format, and return value. Could be elevated to 5 with brief mention of error conditions or idempotency behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema description coverage. Adds semantic meaning via the Args block, specifically providing the ID format example 'sgm_12345' which is absent from the schema's title-only parameter definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Delete) + resource (segment). The clarification 'Does not delete the contacts in it' effectively distinguishes this from sibling delete_contact and defines scope boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit safety guidance by clarifying that contacts remain after deletion, but lacks explicit when-to-use guidance or comparison to update_segment/list_segments siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully documents the return structure (dict with id, email, first_name, last_name, status, data), which compensates for the missing output schema. However, it lacks details on error behavior (e.g., contact not found) or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring-style format with explicit Args and Returns sections is structured and scannable. While slightly more verbose than a single paragraph, every section earns its place by providing essential information not present in the structured schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple read operation with one parameter and no output schema, the description is adequately complete. It documents the input parameter and output structure sufficiently. A minor gap is the absence of error handling documentation, but this is acceptable for a basic getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the JSON schema property has no description. The description fully compensates by documenting the contact_id parameter with both semantics ('The contact ID') and a clear example value ('c_12345'), providing everything needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch a single contact by ID' provides a specific verb (fetch), resource (contact), and scope (single by ID). It clearly distinguishes this from the sibling list_contacts tool which handles multiple records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single contact by ID' implies usage for retrieving specific known records versus listing/filtering, offering implicit differentiation from list_contacts. However, there is no explicit guidance on when to use this versus create_contact or update_contact, or prerequisites like needing a valid ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It successfully warns that this 'sends real emails' (destructive/irreversible behavior) and documents the return value ('Delivery queued confirmation'). Missing explicit rate limits or auth requirements, but covers critical safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured docstring format with clear WARNING block upfront. The Args/Returns sections are efficient. Slightly formal structure but no wasted sentences—every element earns its place by conveying safety info, parameter format, or return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter mutation tool without annotations or output schema. The description supplies the missing parameter documentation and explains the return value (delivery confirmation). Could strengthen by mentioning that the campaign must exist (prerequisite) but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Critical compensation for 0% schema description coverage. The Args section provides the parameter description and crucial example format ('mc_12345'), without which the agent would have no guidance on the campaign_id format. Fully bridges the schema documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Send a campaign immediately' provides the verb (Send), resource (campaign), execution timing (immediately), and scope (to all contacts or segment contacts). The 'immediately' distinguishes it from the sibling tool schedule_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Contains strong safety guidance via the WARNING about real emails and validation needs. However, it doesn't explicitly name schedule_campaign as the alternative for non-immediate sending, requiring the agent to infer this from the 'immediately' keyword.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It successfully clarifies the creation vs. sending distinction and documents Liquid template support ({{ contact.first_name }}). Minor gap: lacks details on idempotency, validation errors, or rate limiting that would help an agent handle failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with logical flow: purpose statement, behavioral caveat, template syntax note, Args block, and Returns line. Information is front-loaded. The Args/Returns blocks are slightly verbose for MCP context but justified given complete lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema descriptions, no annotations, and no output schema, the description provides comprehensive coverage: explains the campaign object creation, recipient segmentation, templating capabilities, and return value. Could be improved by describing the campaign record structure in Returns, but sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (titles only). Description fully compensates by documenting all 6 parameters in the Args block, including critical details like optionality (segment_id, preview_text), format examples ('ms_12345', 'sgm_12345'), enumerated values for settings_type, and the reference to list_senders for sender_id semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Create a new email campaign') with clear resource type. Explicitly distinguishes from sibling tool send_campaign by stating 'Does NOT send it — use send_campaign after', preventing incorrect agent assumptions about immediate sending behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: 'Does NOT send it — use send_campaign after'. Also directs users to sibling tool list_senders with 'Use list_senders to find IDs', linking the tool to its necessary dependencies and prerequisite operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It compensates well by documenting the return structure ('A dict with 'data' (list of senders with id, name, from_email, reply_to)'), which provides crucial behavioral context. It does not, however, disclose rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains three efficient statements: purpose definition, usage context, and return structure. Every sentence earns its place. The content is front-loaded with the primary action, followed by usage guidance and return documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without annotations or formal output schema, the description is complete. It documents the output structure inline (dict with data array and specific fields), which compensates for the missing output schema. No additional behavioral details are critical for this read-only listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which establishes a baseline of 4 per calibration guidelines. With no parameters present, there is no semantic information required beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all configured senders' - a specific verb (List) plus resource (senders). It distinguishes from siblings (list_campaigns, list_contacts, etc.) by identifying the specific entity type and linking it to campaign creation workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use sender IDs when creating campaigns' provides clear contextual guidance linking this tool to the create_campaign sibling. However, it lacks explicit 'when not to use' guidance or mention of alternatives for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![keila-mcp MCP server](https://glama.ai/mcp/servers/gwbischof/keila-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gwbischof/keila-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gwbischof/keila-mcp'

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