Sealmetrics MCP Server

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes targeting specific analytics domains like conversions, traffic, funnels, and pages. However, 'get_conversions' and 'get_microconversions' could cause some confusion as microconversions are a subset of conversions, though descriptions clarify the difference.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'get_' or 'generate_' prefixes, using snake_case throughout. This predictable naming makes it easy for agents to understand and select tools without ambiguity.
Tool Count5/5
With 8 tools, this server is well-scoped for analytics and tracking purposes. Each tool covers a distinct aspect of the domain, such as accounts, conversions, traffic, and performance, without being overly sparse or bloated.
Completeness4/5
The tool set covers core analytics workflows including data retrieval for conversions, traffic, funnels, and ROAS, plus account management and pixel generation. A minor gap is the lack of update or configuration tools for settings, but agents can still perform most common tasks effectively.
Average 3.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a tracking pixel but lacks details on side effects (e.g., whether it triggers an API call, stores data, or requires authentication), performance considerations (e.g., rate limits), or output format (e.g., HTML/JavaScript code). The mention of 'ready for Google Tag Manager' implies integration but does not specify behavioral traits.
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, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy and wastes no words, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
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 has 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain what the tool returns (e.g., the pixel code format), potential errors, or integration steps with Google Tag Manager. For a tool that likely outputs code or a URL, the lack of output details is a significant gap, leaving the agent uncertain about the result.
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 has 100% description coverage, providing clear documentation for all 5 parameters (e.g., 'event_type' with enum values, 'ignore_pageview' with usage context). The description does not add any additional semantic meaning beyond the schema, such as explaining parameter interactions or providing examples. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.
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 tool's purpose: 'Generate a Sealmetrics tracking pixel for conversions or microconversions, ready for Google Tag Manager.' It specifies the verb ('Generate'), resource ('tracking pixel'), and context ('for conversions or microconversions'), but does not explicitly differentiate from sibling tools like 'get_conversions' or 'get_microconversions', which appear to be read-only data retrieval tools rather than pixel generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the tool is 'ready for Google Tag Manager,' which hints at a deployment context, but does not specify scenarios, prerequisites, or comparisons with sibling tools. For example, it does not clarify if this should be used for real-time tracking versus historical data retrieval from the sibling tools.
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 the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read operation, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what the output looks like (e.g., format, structure). For a data retrieval tool with zero annotation coverage, this leaves important behavioral traits undisclosed.
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, efficient sentence: 'Get funnel analysis showing progression through conversion stages.' It is front-loaded with the core purpose and contains no unnecessary words or redundant information, making it highly concise and well-structured for quick understanding.
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 complexity of a funnel analysis tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, data format, or how the analysis is presented, which are crucial for an agent to use the tool effectively. The description alone fails to provide sufficient context for proper tool invocation and result interpretation.
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 has 100% description coverage, providing details for all three parameters (account_id, date_range, report_type). The description adds no additional parameter semantics beyond what's in the schema, such as explaining the meaning of 'funnel analysis' in relation to these inputs. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 tool's purpose: 'Get funnel analysis showing progression through conversion stages.' It specifies the verb 'Get' and the resource 'funnel analysis' with the scope of 'progression through conversion stages.' However, it doesn't explicitly differentiate from sibling tools like 'get_conversions' or 'get_microconversions,' which might also relate to conversion data, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'get_conversions' or 'get_traffic_data,' leaving the agent without context for tool selection. This is a significant gap in usage instructions.
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 the full burden of behavioral disclosure. It describes what the tool does but doesn't cover important traits like whether it's read-only, requires authentication, has rate limits, returns paginated data, or what the output format looks like. For a tool with 5 parameters and no output schema, 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, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does and includes key metrics, making it easy to understand at a glance. Every part of the sentence 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?
Given the complexity (5 parameters, no output schema, no annotations), the description is incomplete. It explains the purpose but lacks behavioral details, usage context, and output information. For a tool that likely returns time-series data with multiple metrics, more guidance on interpretation or limitations would be helpful.
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 mentions 'over time' which aligns with the 'date_range' and 'time_unit' parameters, and 'revenue, conversions, and clicks' which relate to the output but not directly to input parameters. With 100% schema description coverage, the schema already documents all parameters well, so the description adds minimal value beyond what's in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 tool's purpose: 'Get ROAS (Return on Ad Spend) evolution over time with revenue, conversions, and clicks.' It specifies the verb ('Get'), resource ('ROAS evolution'), and key metrics included. However, it doesn't explicitly differentiate from sibling tools like 'get_conversions' or 'get_traffic_data' that might also provide related metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_conversions' or 'get_funnel_data' that might overlap in functionality, nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit 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 carries the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe key behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements (implied by account_id but not stated), or what the output format looks like (e.g., pagination details beyond schema). For a tool with 10 parameters and no annotations, this leaves significant gaps in understanding how it behaves.
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 concise and front-loaded, stating the core purpose in the first sentence and adding filtering context in the second. Both sentences earn their place by clarifying scope and usage. However, it could be slightly more structured by explicitly separating purpose from filtering details, but it remains efficient with zero waste.
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 complexity (10 parameters, no output schema, no annotations), the description is incomplete. It doesn't address behavioral aspects like authentication, rate limits, or output format, which are crucial for a tool with many filtering options. Without annotations or an output schema, the description should do more to compensate, but it falls short, leaving the agent with insufficient context for effective 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 input schema has 100% description coverage, providing detailed documentation for all 10 parameters. The description adds minimal value beyond the schema by mentioning content group examples (e.g., 'Blog Content', 'Product Catalog'), which are already covered in the schema's description for 'content_grouping'. It doesn't explain parameter interactions or provide additional context, so the baseline score of 3 is appropriate given the schema does the heavy lifting.
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 tool's purpose: 'Get page performance metrics including views and entry pages.' It specifies the verb ('Get') and resource ('page performance metrics'), and mentions key metrics like views and entry pages. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_traffic_data' or 'get_funnel_data', which might also involve performance 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 provides some implied usage context by mentioning filtering by content groups (e.g., 'Blog Content', 'Product Catalog'), which suggests it's useful for analyzing specific site sections. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_traffic_data' or 'get_funnel_data', nor does it provide exclusions or prerequisites. The guidance is present but not comprehensive.
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 the full burden. It mentions authentication ('authenticated user') but lacks details on rate limits, pagination, sorting, error handling, or response format. For a list-retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get list of Sealmetrics accounts') and adds essential context ('available to the authenticated user'). There is zero waste, making it easy for an agent to parse quickly.
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 (0 parameters, no output schema), the description is minimally adequate. It covers the basic purpose but lacks behavioral details (e.g., response structure, limitations) that would help an agent use it effectively. Without annotations or output schema, more context would improve completeness.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce unnecessary complexity.
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 ('Get list') and resource ('Sealmetrics accounts'), specifying they are 'available to the authenticated user'. It distinguishes from siblings by focusing on accounts rather than conversions, traffic, or performance data. However, it doesn't explicitly differentiate from potential account-related tools that might exist elsewhere.
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 is provided on when to use this tool versus alternatives. The description implies it's for retrieving accounts, but it doesn't specify scenarios (e.g., setup, auditing) or exclusions (e.g., not for detailed account metrics). Without context, the agent must infer usage based on sibling tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool 'Answers questions like...' which suggests a query/read operation, but doesn't explicitly state whether this is a read-only tool, what permissions are required, rate limits, or what format the data returns. For a 9-parameter tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the core purpose and one providing usage examples. Both sentences earn their place by adding value, though the structure could be slightly improved by front-loading more behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with no annotations and no output schema, the description provides adequate purpose and usage examples but lacks important behavioral context about permissions, rate limits, and return format. The schema covers parameters well, but the description doesn't compensate for the missing annotation and output information.
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 description coverage is 100%, so all parameters are well-documented in the schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 tool's purpose: 'Get conversion/sales data from Sealmetrics' with specific examples of questions it can answer. It identifies the resource (conversion/sales data) and source (Sealmetrics), but doesn't explicitly differentiate from sibling tools like get_funnel_data or get_microconversions.
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 provides usage context through example questions ('How many sales this month?' or 'Show conversions from Google Ads yesterday'), which implies when to use this tool for conversion/sales queries. However, it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools.
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 the full burden of behavioral disclosure. While it mentions what data is retrieved (traffic/acquisition), it doesn't describe key behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or what the output format looks like. For a data retrieval tool with 10 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 extremely concise and front-loaded: it states the core purpose in the first sentence and follows with illustrative examples. Every sentence earns its place by clarifying use cases without unnecessary elaboration. The structure is efficient and zero-waste, making it easy for an agent to quickly grasp the tool's intent.
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 (10 parameters, no annotations, no output schema), the description is incomplete. It adequately explains the 'what' (traffic/acquisition data) but lacks critical context such as behavioral traits (e.g., read-only nature, pagination behavior hinted at by parameters), output format, or error handling. For a data retrieval tool with this many parameters and no structured output documentation, the description should provide more guidance on what to expect from the tool's operation.
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 description coverage is 100%, meaning all parameters are well-documented in the input schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain parameter interactions or provide usage examples for specific combinations). Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to given the schema's completeness.
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 tool's purpose: 'Get traffic/acquisition data from Sealmetrics.' It specifies the type of data (traffic/acquisition) and the source (Sealmetrics), and provides concrete examples of questions it can answer. However, it doesn't explicitly differentiate this tool from its siblings like 'get_funnel_data' or 'get_pages_performance', which likely retrieve different types of analytics data from the same platform.
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 provides implied usage guidance through example questions ('How much traffic from SEO yesterday?' or 'Show me Google Ads performance this month'), which suggests this tool is for traffic and acquisition metrics. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_funnel_data' or 'get_conversions', nor does it mention any prerequisites or exclusions. The guidance is helpful but not comprehensive.
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 mentions retrieving data but doesn't disclose behavioral traits such as rate limits, authentication needs (implied by account_id), pagination behavior (hinted by limit/skip parameters but not explained), or what happens if filters yield no results. The example question adds some context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: the first states the purpose and source, the second provides a concrete usage example. It's front-loaded with key information and has zero waste, making it easy to scan and understand quickly.
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 complexity (9 parameters, no annotations, no output schema), the description is adequate but has clear gaps. It covers the purpose and gives an example, but lacks details on behavioral aspects like error handling, response format, or how filters interact. Without annotations or output schema, more context on what the tool returns would be helpful.
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 100%, so the schema fully documents all 9 parameters. The description adds minimal value beyond the schema by mentioning examples like 'add-to-cart' and 'newsletter-signup' for the label parameter, but doesn't provide additional semantics for other parameters. Baseline 3 is appropriate as the schema does the heavy lifting.
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 tool retrieves 'microconversion data (add-to-cart, signups, etc.) from Sealmetrics' with a specific example question. It distinguishes from siblings like 'get_conversions' by focusing on microconversions, though it doesn't explicitly contrast with all siblings. The verb 'Get' is clear but could be more specific like 'Retrieve' or 'Fetch'.
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 through the example question 'How many add to carts from Google Ads yesterday?' which suggests filtering by label and date. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_conversions' or 'get_funnel_data', nor does it provide exclusions or prerequisites. The guidance is contextual but not comprehensive.
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:

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

Score Badge

Copy to your README.md:

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

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