Hevo 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 action and object (list, get, create, enable, disable, resync, update pipeline config, update source config). The two update tools are clearly separated by scope (pipeline-level vs source-level) with descriptions that prevent confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: list_pipelines, get_pipeline, create_pipeline, enable_pipeline, disable_pipeline, resync_pipeline, update_pipeline_config, update_source_config. The naming style and verb choice are uniform.
Tool Count5/5
With 8 tools, the server covers the essential pipeline management operations without bloat. Each tool serves a distinct, necessary purpose for managing Hevo pipelines.
Completeness4/5
The surface covers list, get, create, enable/disable, resync, and update operations, which are core to pipeline management. The only notable gap is the absence of a delete_pipeline tool, which is a minor lifecycle gap that agents can work around by disabling pipelines.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.8/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
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

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 states that the pipeline is 'running,' which implies a precondition, but it does not reveal what happens when the tool is invoked, whether the action is reversible, what occurs to in-flight runs, or what errors may arise. No side effects or state changes are described beyond the action itself.
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 front-loads the action and adds a clarifying synonym. There is no redundant or unnecessary wording, making it appropriately sized for a simple tool. Every word earns its place.
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?
For a tool with one parameter, no annotations, and no output schema, the description is too sparse to be contextually complete. It lacks usage guidance, behavioral effects, prerequisites, error conditions, and a distinction from sibling tools. These gaps could lead an agent to misuse the tool or fail to handle edge cases.
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?
The schema has 0% description coverage for the only parameter, and the tool description does not mention pipeline_id at all. The parameter name is self-explanatory, and the schema defines the type union (integer or string), but the description provides no guidance on how to obtain the pipeline ID or any constraints beyond the schema. The description does not compensate for the lack of parameter information.
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 action ('Disable') and the target ('a running pipeline') with a clarifying synonym ('pause'). It is specific enough to be understood independently, and it is implicitly the opposite of the sibling enable_pipeline. However, it does not explicitly differentiate itself from other pipeline management tools like update_pipeline_config.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that it should be used to temporarily pause a pipeline, nor does it mention prerequisites (e.g., the pipeline must be running) or contrast with enable_pipeline or update_pipeline_config. The description simply states the action without usage 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 carry the burden of disclosure. It only mentions modification without addressing permissions, side effects, reversibility, or whether changes are immediate. For a mutation tool, 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, front-loaded sentence with no redundant information. Every word contributes to understanding the tool's purpose.
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?
This is a mutation tool with no annotations and no output schema. The description explains what it modifies but lacks return behavior, prerequisites, and effect on pipeline state. The nested config object and lack of schema coverage on pipeline_id suggest more context is needed for confident use.
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 describes 'config' as source-specific with partial updates. The description adds concrete examples of source settings, augmenting the schema's generic phrasing. However, it does not fully document possible fields or provide guidance on pipeline_id, so it only moderately compensates for the 50% schema 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?
The description uses a specific verb 'Modify' and resource 'SOURCE configuration of an existing pipeline' to clearly state the tool's function. Concrete examples (host, port, database, credentials) establish scope and naturally differentiate it from the sibling update_pipeline_config.
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 for when to use the tool (modifying source-specific pipeline settings) but does not explicitly mention alternatives or exclusions. Since the sibling update_pipeline_config exists, explicit guidance on when not to use this tool would be stronger.
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 the full burden of behavioral disclosure. It does not mention side effects (e.g., creation is immediate, run_now default), permissions, idempotency, or return value. The only behavioral hint is that the shape of source/destination depends on type, which is more of a parameter nuance than a 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?
Three sentences, front-loaded with purpose, and each sentence earns its place. The pointer to external documentation avoids bloating the description with inline schema details.
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 description is minimal and relies heavily on the provided schema and an external URL. It does not describe expected outcomes, error conditions, or the response shape. Given the tool's nested objects and no output schema, this is a moderate level of completeness, acceptable but with clear gaps.
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 schema already covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by explicitly noting that source/destination shapes are type-dependent and gives examples (MYSQL, POSTGRES, etc.), plus a link to full schemas. This enriches parameter understanding 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 the tool's action ('Create a new Hevo pipeline') with a specific verb and resource. It is immediately distinguishable from sibling tools (list, get, enable, etc.), all of which are different operations.
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 the tool is used when creating a pipeline, but does not explicitly say when to use it over alternatives or when not to use it. It offers no exclusions or alternative guidance, though the distinct action makes the intent reasonably clear.
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 carry the full burden. It states the action but does not disclose edge-case behaviors such as what happens if the pipeline is already active, error handling, permissions required, or idempotency. For a state-changing operation, this is insufficient.
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, well-structured sentence that is front-loaded with the action and purpose. It is concise with no wasted words, effectively conveying the essential information.
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 tool is simple with one parameter and no output schema, so the description covers the main use case adequately. However, it could be enhanced by clarifying behavior in cases where the pipeline is not paused, but given the simplicity, it is mostly 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%, and the description does not mention the pipeline_id parameter at all. While the parameter name is self-explanatory, the description adds no additional meaning about how to obtain or format the ID, leaving the schema as the only source of information.
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 function: 'Enable (resume) a paused pipeline.' It uses a specific verb ('Enable') and resource ('pipeline'), and differentiates from siblings by indicating this is for resuming paused pipelines, which is the opposite of disable_pipeline.
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 usage context: it is for paused pipelines that need to be resumed. It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough that a user would know to use this when a pipeline is paused. However, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the partial-update behavior ('Send only fields to change'), but doesn't mention what happens to omitted fields, authorization requirements, or whether the pipeline is affected during the update. This is a minimal disclosure for a mutation tool.
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 with two clauses. It front-loads the verb 'Modify' and includes the key usage instruction. No wasted words.
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 the tool's complexity (6 parameters, nested objects, no output schema, no annotations), the description is too sparse. It doesn't explain the return value, the effect on the pipeline, or the purpose of the extra field. It is adequate only for a very simple mutation tool, which this is not.
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 coverage is very low (17%). The description lists some field names (name, schedule, query mode, auto-mapping) but omits the required pipeline_id and provides no detail on schedule structure or query_mode allowed values. The 'extra' field is mentioned only in the schema, not the description. It adds some meaning but leaves critical 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 modifies pipeline-level config and lists the specific fields (name, schedule, query mode, auto-mapping). It distinguishes from siblings like update_source_config by specifying 'pipeline-level', and from create/enable/disable tools by using 'modify'.
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 instruction 'Send only fields to change' gives clear partial-update guidance and implies the tool is for modifying existing pipelines rather than creating or enabling/disabling. However, it doesn't explicitly name alternatives or state when not to use it, so it stops short of a 5.
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 behavioral disclosure burden. It implies a read-only operation via 'Get' and discloses that the result includes both configuration and status, but it does not mention error handling, permissions, or side effects. This 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, immediately front-loaded with the verb, resource, and scope. It contains no unnecessary words and is highly efficient.
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 simple single-pipeline getter with one parameter, the description is sufficiently complete. It explains the purpose and the high-level return content ('full configuration and status'), which partially compensates for the lack of an output schema.
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 input schema fully documents the single parameter pipeline_id with type and description (100% coverage). The tool description adds no further parameter semantics, so the baseline score of 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 uses a specific verb 'Get' with a clear resource 'pipeline' and scope 'single', distinguishing it from sibling tools like list_pipelines. It precisely states what the tool returns: full configuration and status.
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?
Usage context is implied by the phrase 'single pipeline' which contrasts with list_pipelines, but there is no explicit when-to-use guidance or mention of alternatives. The description suggests using it for detailed inspection of a specific pipeline without stating 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 provided, the description carries full responsibility for behavioral disclosure. It clearly warns that drop_and_load=true is destructive (drops tables) and that the default false preserves and updates differences. This highlights the key risk of the tool.
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 two sentences long, front-loads the core action, and is entirely free of filler. Every sentence adds essential information about the resync behavior and its destructive alternative.
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's simplicity (2 params, no output schema, no annotations), the description covers the main behavioral difference and default mode. It lacks details like return values or preconditions, but those are less critical for this straightforward mutation tool. The description is reasonably complete for an agent to decide and invoke it correctly.
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 input schema covers drop_and_load with a description, but pipeline_id has no schema description. The tool description implies pipeline_id identifies the pipeline to resync ('Resync a pipeline'), which provides context. Overall, the description adds moderate value beyond the schema, but does not fully compensate for the undocumented pipeline_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?
The description clearly identifies the action ('Resync a pipeline by restarting its historical load') with a specific verb and resource. It distinguishes itself from sibling tools like list_pipelines, create_pipeline, and update_pipeline_config by focusing on the resync operation.
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 clarifies when to use the tool by explaining the two modes: destructive (drop_and_load=true) and non-destructive (default). It doesn't explicitly state alternatives, but the unique operation and sibling names imply it is the correct tool for resyncing a pipeline, not for general CRUD or config updates.
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 carries the transparency burden. It discloses the operation ('List') and the fields returned, but does not mention potential large result sets, pagination, or any filtering/scope limitations. The read-only nature is implied but not explicitly stated.
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 resource, and every word adds value. No fluff or repetition.
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 parameter-less list operation with no output schema, the description is complete: it states what is listed and the fields returned. Sibling tools provide the broader context, and no additional behavioral details are necessary for this simple function.
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?
There are zero parameters, so the schema fully defines the input expectations. Per the baseline for 0 params, a score of 4 is appropriate; the description does not need to explain parameters that don't exist.
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 uses a specific verb 'List' and identifies the exact resource: 'all data pipelines in the Hevo account.' It also enumerates the fields returned (id, name, source/destination type, status), which clearly distinguishes it from sibling tools like get_pipeline or create_pipeline.
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 clearly states the use case: listing all pipelines in the account, which is appropriate for overview scenarios. It does not explicitly name alternatives or exclusions, but the context of sibling tools makes when-to-use unambiguous.
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:

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

Score Badge

Copy to your README.md:

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

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