MarTech MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: campaigns vs offers, search vs get, performance vs details vs assets. No ambiguity between tools.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., get_campaign, search_offers), making them predictable and easy to parse.
Tool Count5/5
8 tools is appropriate for a read-focused MarTech server, covering listing, searching, performance, and assets without feeling sparse or bloated.
Completeness4/5
Covers retrieval and performance analytics for campaigns and offers, plus assets and top offers. Lacks write operations (create/update/delete), but the server appears designed for read-only insights.
Average 3.6/5 across 8 of 8 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It fails to disclose behavioral traits like pagination, ordering, authorization, rate limits, or the meaning of 'segment'. For a search tool, this is critically insufficient.
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 a single sentence, which is efficient but under-specified. It lacks critical information that could be added without much bloat, making it inadequate despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, 0% param coverage, and 3 parameters, the description is highly incomplete. It does not cover return values, pagination, or behavior, leaving agents with insufficient context to use the tool effectively.
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 explains 'query' and 'segment' but not 'limit'. No details on format or constraints, leaving agents guessing about valid inputs.
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 ('search'), the resource ('campaigns'), and the method ('by free-text query and/or segment'). It distinguishes from sibling tools like 'get_campaign' (fetches single) and 'search_offers' (different resource).
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 tool vs alternatives (e.g., search_offers, get_campaign_performance). The description only implies use cases via 'free-text query and/or segment' but offers no exclusions or context.
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 are provided, so the description must disclose behavioral traits. It only states the tool 'returns matching offers' but omits details like read-only nature, pagination, sorting, error handling, or any prerequisites. This is insufficient for a search operation.
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 a single sentence with no waste, efficiently conveying the core purpose and return fields. It could be improved by including parameter or behavior details, but it remains appropriately sized for a simple tool.
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?
Given no output schema, no annotations, and 4 parameters with 0% schema coverage, the description lacks completeness. It does not explain return structure, pagination behavior, or how limit affects results, which are critical for a search tool.
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 the description must compensate. It mentions 'free-text query, category, and/or segment' corresponding to query, category, and segment parameters, but omits the limit parameter entirely. It adds no further meaning beyond parameter names, leaving gaps in understanding.
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 searches marketing offers by free-text query, category, and/or segment, and specifies the returned fields (title, copy, image, CTAs). This distinguishes it from sibling tools like get_offer (single offer retrieval) and search_campaigns (different resource type).
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 searching offers, but provides no explicit guidance on when to use this tool versus alternatives like get_offer or get_top_offers. No exclusions or recommended contexts are given.
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, the description carries full burden for behavioral disclosure. It only states the purpose and optional filtering, not whether the operation is read-only, authentication needs, or behavior with missing parameters (e.g., default limit). Minimal context beyond purpose.
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?
Single sentence, front-loaded with the core action and ranking metric. Every word adds value; no fluff.
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 and no annotations, the description is minimal. It covers purpose and param usage but omits output format, default limit, and behavioral details. Adequate for a simple list tool but could be more complete.
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 description coverage is 0%. The description explains the 'segment' and 'placement' parameters as filters, but does not explain 'limit' (though it is implied by 'top'). Adds some meaning but not fully compensates for the lack of schema descriptions.
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 retrieves top offers ranked by CTR, with optional filtering by segment and placement. This distinguishes it from siblings that retrieve individual entities or performance data.
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 when needing ranked top offers, but does not explicitly state when to use this tool versus alternatives like search_offers or get_offer_performance. No when-not-to-use guidance is 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?
With no annotations, the description partially discloses behavior: it states the tool computes aggregates (implying read-only), but does not mention permissions, error handling, latency, or dependencies. Adequate but not comprehensive.
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 with no filler, efficiently conveying the tool's purpose and key outputs. It is well-structured and front-loaded.
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 simple tool with one input and no output schema, the description sufficiently covers core functionality and return values (impressions, clicks, CTR, unique reach). However, it lacks details on data aggregation period or filtering, which would enhance completeness.
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 description coverage is 0%, and the description adds context ('for a campaign') but does not detail the 'campaignId' parameter format or constraints. Since there is only one parameter, the minimal added meaning is acceptable but not compensatory beyond 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 clearly states the tool computes aggregate performance for a campaign and lists specific metrics (impressions, clicks, CTR, unique reach), using a specific verb and resource. It distinguishes from sibling tools like get_offer_performance by specifying 'campaign'.
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 tool vs alternatives. It does not mention when not to use it or provide explicit comparisons to sibling tools such as 'get_campaign' or 'get_offer_performance'.
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 behavioral burden. It states it 'gets' assets, implying read-only, but does not disclose permissions, error handling, pagination, or response format. The description is minimal and leaves significant behavioral details unspecified.
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 concise sentence of 12 words, with no redundant information. It front-loads the core purpose and parameter behavior efficiently.
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 the tool's simplicity (one string parameter, no output schema), the description adequately covers the basic purpose and parameter. However, it omits details about return format, pagination, and error states, leaving some gaps for an agent to infer.
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 description adds meaning beyond the input schema by specifying that the 'offer' parameter accepts an Offer ID or name. This compensates for the 0% schema coverage, though it does not clarify how to distinguish between the two inputs or provide format hints.
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 'get', the resource 'creative assets', and the context 'linked to an offer', with two lookup methods. It effectively distinguishes from sibling tools like 'get_offer' and 'search_offers', which focus on offer data rather than assets.
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 retrieving assets by offer, but lacks explicit guidance on when to choose this tool over alternatives. Among siblings, it is the only asset-specific tool, but no 'when not to use' or prerequisite conditions are mentioned.
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 are provided, so the description carries full burden. It only describes what the tool returns but does not disclose behavioral traits such as that it is read-only, side effects, authorization requirements, rate limits, or error behavior. For a likely read-only operation, this is a significant gap.
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 that is front-loaded with the action and resource, and efficiently lists the included sub-resources. Every part adds value without waste.
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 tool retrieves a single record with nested data and no output schema, the description reasonably covers the return content by listing specific fields. It lacks mention of potential filtering, pagination, or performance implications, but for a get-by-id tool, it is fairly complete.
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?
The description adds meaning by stating the 'id' parameter can be a Campaign ID or name, which is not in the schema. However, with 0% schema description coverage, more clarity on format or constraints would be beneficial. The description provides some compensation.
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 verb 'Get' and the resource 'a single campaign's full record', and lists specific included sub-resources (offers, segments, attribution IDs, placements). This distinguishes it from siblings like search_campaigns (listing) and get_campaign_performance (performance 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 implies when to use (when you need the full record of a single campaign) and indirectly contrasts with siblings, but does not explicitly state when not to use or provide alternative tool names. The context of sibling tools makes the usage fairly clear.
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. It explicitly states the tool returns 'computed performance', indicating a read-only analytical operation. It lists specific metrics and the optional breakdown. However, it does not mention authorization needs, rate limits, or return structure beyond metrics.
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, concise sentence that efficiently communicates the tool's purpose and optional feature without redundancy or extra words.
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 (2 simple parameters, no output schema, no annotations), the description is adequate. It covers the core purpose and optional breakdown. It does not explain return format or pagination, but for a simple metrics tool, this is sufficient.
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?
The schema has 2 parameters (offerId, by). Schema description coverage is 0%, but the description adds value by explaining the 'by' parameter allows breakdown by segment or placement. The required offerId is self-explanatory. This provides minimal additional meaning over 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 the verb 'get computed performance', the resource 'offer', and specific metrics (impressions, clicks, CTR, unique reach). It also mentions optional breakdown by segment or placement, which distinguishes it from sibling tools like 'get_offer' that likely return offer details rather than aggregated metrics.
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 retrieving offer performance metrics but does not explicitly state when to use this tool versus alternatives or when not to use it. Sibling tool names provide some context, but no direct guidance on exclusions or prerequisites.
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 the full burden. It correctly states 'get' implying read-only, but does not disclose rate limits, authentication needs, or any side effects. The claim 'full record' is informative but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. Every part earns its place.
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 required parameter, no output schema), the description adequately states the tool retrieves the full record. It could be more specific about the returned fields, but the phrase 'full record' is reasonably clear.
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 coverage is 0%, so the description must add meaning. It explains that the 'id' parameter can be either an Offer ID or an exact name, significantly clarifying usage beyond the bare schema type.
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 a single offer's full record using an ID or exact name. It differentiates from siblings like get_offer_performance (performance data) and search_offers (search by criteria) by specifying the action and resource.
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 indicates when to use the tool—when you have an Offer ID or exact name. It provides clear context but lacks explicit exclusions or alternatives, though siblings are implicitly differentiated.
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:

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

Score Badge

Copy to your README.md:

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

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/appalchapa/martech-mcp-server'

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