moengage-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 targets a distinct operation: template analysis, building, localization, patching, publishing, updating; campaign creation, status changes, searching, metadata retrieval, statistics, child executions, testing; plus personalization previews and server info. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., analyze_template, create_campaign, search_templates). The naming is predictable and uniform across the entire tool surface.
Tool Count5/5
With 18 tools covering templates, campaigns, testing, personalization, and metadata, the count is well-scoped for a marketing automation MCP server. Each tool serves a clear purpose without redundancy or unnecessary complexity.
Completeness4/5
Core CRUD and lifecycle operations are covered for both templates and campaigns. However, there is no delete/archive tool for campaigns or templates, which is a minor gap. The missing deletion operations could cause agent failures in cleanup scenarios.
Average 4.4/5 across 18 of 18 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 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
This repository is licensed under MIT License.
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

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 of behavioral disclosure. It describes the patches format and the publish parameter, but does not cover auth requirements, error handling, or consequences of operations (e.g., overwriting text). The description is moderately transparent but lacks depth.
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 is concise, front-loaded with the main action, and uses clear bullet-like structure for the patches format. Every sentence adds value without redundancy.
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?
The tool has 6 parameters and an output schema (not shown). The description covers the core use case and patches format but omits details on required parameters (external_template_id, new_version, updated_by) and potential errors. While the output schema may compensate for return value info, the description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains the 'patches' format and the 'publish' parameter. It does not clarify 'external_template_id', 'new_version', 'updated_by', or 'subject', leaving significant gaps for a 6-parameter tool.
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 tool modifies specific text nodes in an existing template without full rebuild, which is a specific verb and resource. It distinguishes itself from the sibling tool 'update_template' by emphasizing targeted edits over a full rebuild.
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 description provides context for when to use this tool ('small copy edits') and contrasts with full rebuild, but does not explicitly name alternative tools (like 'update_template') or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that HTML is built internally but not returned, and that debug=True saves to temp file. It also details component types and return structure, providing good insight into behavior. However, it does not mention any side effects or limitations like file size.
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 description is well-structured, starting with purpose, then component types, then return preview details, and debug behavior. Each section adds value. Slightly lengthy but justified given the complexity; could trim redundant phrases.
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 3 parameters, 2 required, no annotations, and an existing output schema (not shown), the description covers the output structure extensively, including validation and expected fields. It lacks mention of error handling or prerequisites but is fairly complete for the tool's complexity.
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%, so the description must compensate. It explains component types and the debug parameter's effect well, listing possible component types. However, it does not detail the meaning of the 'title' parameter beyond being required, and the component schema is left to arbitrary additionalProperties.
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 tool's purpose: 'Build and validate email template, returning structured preview (NO HTML).' It uniquely distinguishes from siblings by focusing on building and validating templates, while siblings like compare_templates, localize_template, or patch_template_text have different functions.
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 does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools. It mentions the debug parameter for HTML inspection but lacks context on when to choose this tool over alternatives like analyze_template or get_personalized_preview.
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 are present, so the description carries the burden. It discloses that the tool returns per-node comparison with specific match types, giving a clear behavioral model. It could mention error handling or scope (text only), but the provided info is solid.
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 a bullet list, front-loaded with the primary purpose. Every word contributes value; no redundancy.
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?
The presence of an output schema reduces the need to describe return values fully. The description covers the main functionality and match types. It might omit that only text content is compared, but overall it is complete for the task.
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?
Both parameters are documented in the schema with descriptions. The description adds an example (EN vs ES) but no additional semantic detail beyond the schema. With 100% schema coverage, baseline 3 is appropriate.
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 it performs a structured diff of two templates' text content, with a concrete example (EN vs ES). The match types are enumerated, distinguishing it from siblings like analyze_template or localize_template.
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 for text comparison but does not explicitly state when to use this tool versus alternatives (e.g., analyze_template for broader analysis). No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It describes a read operation returning metadata, but does not mention that it is safe, idempotent, or has no side effects. The description is minimal but not misleading.
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 is a single sentence, front-loaded with the verb and result. Every word adds value, and there is no unnecessary information. It is appropriately sized for the tool's simplicity.
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?
For a tool with no parameters and an existing output schema, the description adequately explains what it does. It mentions specific return fields (data_center, dashboard URL). No additional context seems necessary for basic usage.
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 tool has no parameters, and schema coverage is 100%. The description does not need to add parameter info, and the baseline for zero-parameter tools is 4. No additional semantic value is required.
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 tool returns MCP server metadata, specifying 'data_center' and 'dashboard base URL'. It uses a specific verb and resource, and none of the sibling tools appear to provide server info, so it stands out.
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 does not explicitly guide when or when not to use this tool vs alternatives. However, given the tool's simplicity and unique purpose, usage context is implicit. No exclusions or conditions are mentioned.
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 effectively discloses key behaviors: translations must include node IDs and inner HTML only, Jinja rules, image override format, RTL support, source versioning, and the publish/force logic. It does not describe where the localized template is saved or permissions needed.
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 description is well-structured with bullet points for different sections (translations, Jinja, image_overrides, etc.). It is front-loaded with the main purpose. While slightly lengthy, every sentence provides value, making it effective.
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 complexity (15 params, 9 required) and no annotations, the description covers translations, image overrides, RTL, source version, and publishing behavior. Minor gaps exist for some required parameters and the exact storage destination. The presence of an output schema partially compensates for return details.
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?
Schema coverage is 0%, so the description carries the full burden. It adds meaning for translations, image_overrides, rtl, source_version, publish, and force (6 of 15 params). However, required parameters like source_external_template_id, target_template_id, target_template_name, target_template_version, subject, sender_name, created_by, and preview_text are not explained beyond their schema names.
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 tool's purpose: 'Create a localized version of an existing template for a target market.' It uses a specific verb ('localize') and resource ('template'), differentiating it from sibling tools like analyze_template or build_email_template.
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 description provides detailed usage context, including formatting rules for translations, Jinja, and image_overrides, as well as conditions for publish and force. However, it does not explicitly state when NOT to use this tool or compare it to alternatives like patch_template_text or update_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: runs TemplateValidator unless force=True, returns success status and preview, and explicitly states HTML is never exposed to agent 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?
The description is well-structured with a clear opening sentence and bullet-style details. It is moderately concise, though some sentences could be tighter.
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 11 parameters (8 required) and no schema descriptions, the description covers key behavioral aspects but lacks detail on parameter semantics. Output schema exists but is not summarized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only explains external_template_id, force, and debug. Other required parameters like title, components, template_name, etc. are not described, leaving significant gaps.
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 tool validates, builds, and updates an existing email template in MoEngage. It uses specific verbs and resource, distinguishing it from siblings like search_templates or create_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?
The description explains the prerequisite (obtain external_template_id via search_templates) and provides guidance for optional flags (force=True, debug=True). It implicitly differentiates from alternatives but does not explicitly state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that TemplateValidator runs by default, that HTML is never exposed to agent context, and specifies the return values (success status, external_template_id, structured preview). No contradictions.
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 is very concise with three short paragraphs. Each sentence adds value: main purpose, behavior details, and parameter guidance. 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?
Given 11 parameters and 8 required, the description lacks parameter explanations. It covers behavioral aspects and return values (aided by output schema), but is incomplete for understanding all inputs. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It only explains force and debug parameters, ignoring 9 others including required ones like title, components, template_id. This leaves agents without understanding of many parameters.
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 action: 'Validate, build, and publish an email template to MoEngage.' It identifies the specific resource and verb, and distinguishes from sibling tools like analyze_template or build_email_template by including validation and publishing.
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 description provides guidance on when to use force=True to bypass validation and debug=True to save HTML. It implies the tool is for publishing, but does not explicitly contrast with alternatives like build_email_template. However, the context is clear enough.
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?
The description discloses behavioral traits: returns different response shapes for success, API error, and validation failure. It explains the resolution of placeholders and lists supported expressions. No annotations are provided, so the description carries the full burden, which it handles well. Missing details on permissions or idempotency.
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?
The description is lengthy but well-structured with bullet points and examples. It front-loads the main purpose, but some details (e.g., supported expressions) could be more concise. It earns its length by providing essential examples, but could be tightened.
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?
Given no annotations and no schema descriptions, the description is complete. It covers all parameters, constraints (payload vs custom_template_data), error handling, rate limit, and return format. The output schema is not provided but the description explains the return structure adequately.
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%, so the description must fully compensate. It provides detailed explanations for each parameter with examples: personalization_details structure, payload format, custom_template_data usage, and user_details. It adds significant meaning beyond the raw schema.
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 tool's purpose: to get a personalized preview with placeholders resolved. It lists the channels and explains the core functionality, distinguishing it from sibling tools like analyze_template or build_email_template that deal with template creation or analysis.
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 description gives explicit usage constraints: 'Provide either payload OR custom_template_data — not both, not neither.' It also states the rate limit. However, it does not explicitly compare to sibling tools or say when to use this tool instead of others, though the purpose is clear.
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 must carry the burden. It explains the return structure (dict with success, templates, total, etc.) and pagination behavior. Does not mention authentication, rate limits, or potential side effects (but as a read operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized into sections (filters, sorting, pagination) with no wasted words. Every sentence provides essential information.
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?
Covers all 13 parameters, return structure, and usage nuance (include_html). Output schema exists but description still explains return fields. Comprehensive for a search 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%, so description compensates by thoroughly explaining each filter parameter, including match types, sorting, and pagination. Adds significant meaning beyond the raw schema.
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?
Clearly states 'Search templates in MoEngage API with advanced filtering and pagination.' The verb 'Search' and resource 'templates' are specific, and no sibling tool duplicates this functionality (e.g., search_campaigns is separate).
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?
Provides explicit guidance on when to set include_html=True vs False to avoid context overflow. However, it does not discuss when to prefer search_templates over sibling tools like analyze_template or compare_templates.
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 covers many behavioral aspects: rate limits, that MoEngage silently skips recipients without eligible devices, the return shape (success/failure with details), and validation failures. It explains parameter overrides (e.g., campaign_content_override replaces all auto-built content). However, it does not explicitly mention that sending test campaigns results in actual messages being sent (destructive in terms of external effect) or authentication needs.
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?
The description is very long (100+ lines) due to the high parameter count. It is structured with section headers and bullet-like lists, which aids readability. However, some information is repeated (e.g., default values mentioned both in parameter lists and inline notes), and the length could be reduced by relying more on schema descriptions if they were present.
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?
Given the high complexity (93 parameters, no schema descriptions, no annotations), the description is remarkably complete. It covers all parameters with their semantics, mutual exclusions, overrides, return values (success, error, notes), rate limits, platform-specific behaviors, and even edge cases like MoEngage silently skipping recipients. The output schema is fully described.
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%, so the description must fully compensate. It does so by explaining each parameter group (EMAIL, PUSH, SHARED) in detail, including required vs optional, defaults, mutual exclusivity (e.g., html_content and template_id), and behavioral effects (e.g., identifier_type bypasses auto-detection). It also provides examples for user_attributes and notes overrides.
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 tool's purpose: 'Send a test Email or Push campaign to specific recipients.' It identifies the verb 'send' and resource 'test campaign', distinguishing it from sibling tools like create_campaign. The specificity of 'test' differentiates it from regular campaign creation or update.
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 description provides extensive usage context, including channel-specific requirements (EMAIL vs PUSH), prerequisites (only API-created campaigns can be tested), rate limits (5/min, 25/hr, 100/day), and examples for user_attributes. However, it does not explicitly state when not to use this tool versus alternatives like create_campaign, though it implies it's for testing only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses behavioral traits: reachability_details only for scheduled campaigns, daily calculation with 24h cache, supported channels and statuses, error response format, rate limits (5/min, 25/hr, 100/day), pagination behavior (has_more heuristic), and field name differences versus search_campaigns. This is highly transparent.
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 description is well-structured with sections for different aspects (overview, filters, reachability, supported values, errors, rate limits, pagination, field differences). It is front-loaded with the main purpose. However, it is fairly long and contains some redundancy (e.g., listing channels twice), but overall it is efficiently organized.
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?
Given the tool's complexity (12 parameters, no annotations, but an output schema exists), the description is remarkably complete. It covers return structure, error cases, rate limits, pagination, edge cases like reachability conditions, field name differences, and prerequisites for date parameters. Only minor gaps in parameter explanations exist, but overall it provides a comprehensive 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?
The input schema has 12 parameters with 0% description coverage in the schema. The description compensates by explaining many parameters: created_date_from/to must be provided together, include_child_campaigns behavior, page/limit pagination, campaign_id error handling, and supported values for channels, delivery_type, and status. However, some parameters like created_by and tags are not explained.
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 tool gets detailed campaign metadata including reachability_details, and specifies it accepts the same filters as search_campaigns. It explicitly names the resource (campaign metadata) and the verb (get), distinguishing it from sibling tools like search_campaigns or get_campaign_stats.
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 description provides good context on when to use this tool (for detailed metadata, including reachability_details for scheduled campaigns) but does not explicitly state when not to use it or offer direct comparisons to siblings. The implied use case is clear, but it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: the tool is currently non-functional, details rate limits (100/min), pagination behavior, error responses, and the structure of returned data. This is comprehensive.
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 description is lengthy but well-structured: starts with a critical warning, then explains parameters, output fields, pagination, rate limits, and return format. Every sentence adds value, though it could be slightly more concise.
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?
Given no output schema is provided, the description includes detailed output structure, error handling, and rate limits. It covers all aspects: purpose, parameters, constraints, behavior, and cancellation status, making it completely adequate for the tool's complexity.
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%, but the description thoroughly explains all seven parameters, including formats, constraints (e.g., max 10 campaign IDs, date range limits), and required fields. It adds full meaning beyond the schema.
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 it retrieves campaign performance statistics from MoEngage, using specific verbs and resources. It distinguishes itself from sibling tools like create_campaign or update_campaign by focusing on stats retrieval and also notes the current unavailability.
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 description explicitly states that both start_date and end_date are required and the max date range is 30 days. It also provides guidance on pagination and rate limits. However, it does not contrast with alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: caching behavior (15-min TTL), compression ratio (~8:1), that HTML is not returned but cached, and the detailed return structure. No contradictions.
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 bullet points for returns and a clear warning. The description is moderately concise; a bit of redundancy ('Both parameters are required') could be trimmed, but overall effective.
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?
Given the complexity and presence of an output schema, the description is complete. It explains the tool's role among siblings, return values, and caching behavior, leaving no major gaps for an agent to misunderstand.
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 has 2 parameters with 0% description coverage, but the description adds substantial meaning by explaining that together they pin the exact revision and emphasizing the importance of version. This compensates well, though it could explicitly define external_template_id.
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 tool fetches a template, parses HTML, and returns a structured content map. It uses specific verb+resource ('Fetch existing template from MoEngage, parse HTML, return structured content map') and distinguishes from sibling tools like localize_template and patch_template_text.
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?
Explicitly states both parameters are required and warns against omitting version, explaining the consequence of fetching the wrong revision. Provides context for caching (15-min TTL) and relation to subsequent tools, offering clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. Discloses batch processing behavior, per-campaign result handling, detailed error responses for API failures and validation errors, and rate limits. The constraint 'Only campaigns created via the API can have their status changed' is an important behavioral trait.
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?
Description is well-organized with clear sections, bullet points, and structured examples. Every sentence adds necessary information; no redundancy or filler. The format is easy to parse quickly.
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 tool with multiple action types, state constraints, rate limits, and a returned output schema, the description covers all relevant aspects. Success and error responses are fully documented. No gaps are apparent.
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%, but description fully compensates by explaining the action enum values with their validity contexts and specifying the campaign_ids range (1-10). This adds meaning well beyond the bare schema property definitions.
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?
Description clearly states the verb 'Change the lifecycle state' and specifies the resource (campaigns) with a batch size constraint (1-10). Actions STOP, PAUSE, RESUME are precisely defined. Easily distinguished from siblings like create_campaign or update_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?
Provides detailed conditions for each action (e.g., STOP only for ONE_TIME campaigns in SCHEDULED state, PAUSE/RESUME for specific delivery types). Includes rate limits and the constraint that only API-created campaigns are eligible. Lacks explicit mention of when not to use the tool, but the guidance is comprehensive and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: rate limits (5/min, 25/hr, 100/day), return values (success/error responses), and the effect of dict overrides on auto-built sub-objects. No contradictions.
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 is well-structured with clear sections (REQUIRED, EMAIL CONTENT, PUSH CONTENT, etc.) and front-loaded with the core purpose. Despite its length, every sentence serves a purpose due to the tool's complexity.
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?
Given the tool's high complexity (114 parameters, no schema descriptions, no annotations), the description is remarkably complete. It covers all essential aspects: required parameters, channel-specific content, scheduling, segmentation, UTM, dict overrides, rate limits, and return values.
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%, but the description compensates thoroughly by explaining each parameter's purpose, required/optional status, defaults, constraints (e.g., mutual exclusivity), and grouping them logically. This adds critical meaning beyond the schema's names and types.
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 explicitly states 'Create an Email or Push campaign in MoEngage', clearly identifying the verb and resource. It distinguishes from sibling tools like update_campaign and search_campaigns by focusing on creation.
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 description provides clear context on when to use this tool (creating campaigns) and extensive parameter-level guidance for different channels and delivery types. However, it does not explicitly contrast with siblings or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: PATCH semantics, status-based restrictions (STOPPED/ARCHIVED rejected, ACTIVE/SCHEDULED blocked fields), sub-object replacement with dict overrides, and response structure including cache_warning. Very transparent.
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?
Well-structured with clear sections and headers, front-loaded with key PATCH semantics and status restrictions. Every sentence adds value given the complexity; no wasted text.
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?
Covers all aspects: input parameters with semantics, PATCH behavior, status restrictions, rate limits, and multiple response formats. Output schema exists but description also clarifies context and error cases. Very complete for a complex 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?
With 0% schema description coverage, the description provides extensive semantic meaning for all 115 parameters, grouping them logically, explaining defaults, mutual exclusivity (e.g., html_content vs template_id), and conditions (e.g., platforms required for push). Far exceeds baseline.
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 begins with 'Update an existing campaign using PATCH semantics', clearly stating the verb and resource. It distinguishes from sibling tools like create_campaign and change_campaign_status by emphasizing incremental update.
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?
Provides clear guidance on when updates are allowed via status restrictions and rate limits. However, lacks explicit comparison to sibling tools like change_campaign_status or create_campaign, which would help an agent choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It fully discloses return structure (fields, status values), sorting, pagination behavior, error format, and includes a note about undocumented rate limit. This exceeds typical transparency expectations.
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 bullet points and clear sections, front-loading the primary purpose. Slightly verbose with items like 'Rate limit: not explicitly documented' which could be omitted, but overall efficient and organized.
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?
Given the output schema exists, the description still adds value by detailing field meanings (e.g., status values are mixed-case), pagination mechanics, and error handling. No gaps remain for a tool with 3 parameters and no annotations.
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?
Parameter explanations add significant meaning beyond the bare schema. For parent_campaign_id, it explains version ID resolution. For page and limit, it provides defaults, maximums, and behavior. This compensates for the 0% schema description coverage.
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?
Clearly states the tool's purpose: 'Get child executions for a periodic or business-event-triggered campaign.' The verb 'Get' and the specific resource 'child executions' are well-defined, and the conditions (periodic or business-event-triggered) distinguish it from siblings that do not have this specialization.
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?
Explicitly guides when to use: 'only works for PERIODIC and BUSINESS_EVENT_TRIGGERED parent campaigns. Calling it on a ONE_TIME campaign returns no results.' Also notes supported channels (Email and Push only). This provides clear context and exclusion, though no alternatives among siblings are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses zero results handling, pagination heuristic (has_more may false-positive), rate limits (5/min, 25/hr, 100/day), and that it returns full raw objects without curation. Also mentions error response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, then a bullet list of parameters, followed by notes on date range, rate limit, pagination, and field differences. It is slightly long but every sentence adds value, so it earns a 4.
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?
Given 13 parameters (0 required), no output schema shown but the description includes return format and error response. It covers inputs, behavior, errors, rate limits, pagination, and cross-references to sibling tool. Very complete.
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%, but the description lists each parameter with valid values (e.g., delivery_type enums, statuses), behavior (name substring match, case-insensitive), and constraints (date range must be together). This adds significant meaning beyond the bare schema.
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 starts with 'Search MoEngage campaigns with optional filters and pagination,' clearly stating the verb (search), resource (campaigns), and scope. It distinguishes itself from siblings like get_campaign_meta and search_templates by focusing on search with multiple filters.
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 guidance: all filters combine with AND logic, zero results not an error, date range requires both fields, pagination details, rate limits, and field name differences vs get_campaign_meta. It tells the agent exactly how to use it and what to expect.
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:

[![moengage_mcp MCP server](https://glama.ai/mcp/servers/poddubnyoleg/moengage_mcp/badges/card.svg)](https://glama.ai/mcp/servers/poddubnyoleg/moengage_mcp)

Score Badge

Copy to your README.md:

[![moengage_mcp MCP server](https://glama.ai/mcp/servers/poddubnyoleg/moengage_mcp/badges/score.svg)](https://glama.ai/mcp/servers/poddubnyoleg/moengage_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/poddubnyoleg/moengage_mcp'

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