meridian-edge-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: get_consensus retrieves aggregated probabilities, get_markets lists available markets, get_opportunities finds divergence events, get_settlements shows concluded outcomes, and get_signals tracks directional moves. There is no overlap in functionality, and the descriptions make each tool's unique role immediately apparent.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get_' as the prefix (e.g., get_consensus, get_markets, get_opportunities). This uniformity makes the tool set predictable and easy for an agent to navigate without confusion.
Tool Count5/5
With 5 tools, this server is well-scoped for its domain of prediction market data. Each tool serves a specific, non-redundant function, covering real-time consensus, active markets, divergence opportunities, settlements, and signals, which aligns with typical data retrieval needs in this context.
Completeness4/5
The tool set provides comprehensive coverage for querying prediction market data, including active, settled, and divergent events, as well as signals. A minor gap is the lack of tools for creating or interacting with markets (e.g., placing bets or managing accounts), but this is reasonable for a read-only data server focused on consensus and analysis.
Average 3.9/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context about what signals represent ('notable directional moves in prediction market consensus') and details on direction and status, which is useful. However, it lacks information on potential rate limits, authentication needs, or error handling, leaving gaps in behavioral understanding for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by details on signals, parameters, and returns. Each sentence adds value, such as explaining signal indicators and parameter specifics, without unnecessary fluff. It could be slightly more concise by integrating the 'Args' and 'Returns' sections more seamlessly, but overall it's 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?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is fairly complete. It covers the purpose, parameter semantics, and return format, and the presence of an output schema means it doesn't need to detail return values extensively. However, it lacks usage guidelines and some behavioral context, which slightly reduces completeness for effective agent use.
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 significant meaning beyond the input schema, which has 0% description coverage. It explains the 'limit' parameter's purpose ('Number of signals to return'), range ('1–10'), and default value ('default 5'), effectively compensating for the schema's lack of descriptions. This provides clear semantic context for the single parameter.
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 recent market signals showing direction of price moves.' It specifies the verb ('Get') and resource ('market signals'), and distinguishes them as 'notable directional moves in prediction market consensus.' However, it doesn't explicitly differentiate from sibling tools like get_consensus or get_markets, which likely provide related but different market data.
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 what signals indicate, but doesn't specify scenarios for using get_signals over sibling tools such as get_consensus or get_markets, nor does it outline any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: real-time nature, aggregation from multiple regulated markets, and what data is returned (probabilities, trends, confidence/spread). However, it doesn't mention rate limits, authentication needs, error conditions, or whether this is a read-only operation (though 'get' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: purpose first, then returns explanation, followed by parameter details in a clear Args/Returns format. Every sentence adds value with no redundancy. The length is appropriate for a tool with 2 parameters and clear functionality.
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 moderate complexity, 2 parameters with 0% schema coverage, no annotations, but with output schema present, the description is reasonably complete. It explains what consensus means, what parameters do, and what data is returned. The output schema means return values don't need explanation, but some behavioral context (like rate limits) is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains both parameters: 'sport' with specific enum values (NBA, NFL, MLB, NHL, MLS, POLITICS) and behavior when omitted, and 'limit' with range (1-20) and default. This adds significant meaning beyond the bare schema, though it doesn't cover all possible edge cases.
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 real-time prediction market consensus probabilities' with specific details about what consensus means (aggregated from multiple regulated markets). It distinguishes from siblings by focusing on consensus rather than raw markets, opportunities, settlements, or signals. However, it doesn't explicitly contrast with each sibling tool.
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 parameter explanations (filter by sport or get all active events), but doesn't explicitly state when to use this tool versus alternatives like get_markets or get_opportunities. The context is clear (real-time prediction market consensus), but no explicit guidance on tool selection among siblings 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'active prediction markets currently being tracked' and 'markets that are open and being monitored for consensus,' which adds context about filtering and monitoring status. However, it lacks details on permissions, rate limits, or error handling, which are important for a read operation with no annotation coverage.
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 and front-loaded: the first sentence states the purpose, followed by usage guidance, and then structured sections for Args and Returns. Every sentence earns its place with no wasted words, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with 2 parameters) and the presence of an output schema (which handles return values), the description is fairly complete. It covers purpose, usage, parameters, and return format. However, with no annotations, it could benefit from more behavioral context like error cases or performance hints, but the output schema reduces the need for extensive return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning beyond the schema by specifying that 'sport' filters by listed sports (NBA, NFL, etc.) or can be omitted, and 'limit' has a range (1–20) with a default of 10. This provides clear semantics, though it doesn't fully detail all possible values or constraints beyond the basics.
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 active prediction markets currently being tracked' specifies the verb (get) and resource (active prediction markets). It distinguishes from siblings by mentioning 'before querying consensus' which hints at get_consensus, but doesn't explicitly differentiate from all siblings like get_opportunities or get_settlements.
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: 'Use this to see what events are currently available before querying consensus' suggests when to use this tool (to see active markets) and hints at an alternative (get_consensus). However, it doesn't explicitly state when not to use it or mention other siblings like get_opportunities or get_settlements, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns ('Formatted list of divergence opportunities ranked by score') and provides some behavioral context about what divergence opportunities represent. However, it doesn't disclose important behavioral traits like rate limits, authentication requirements, error conditions, or pagination behavior that would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by clear sections for arguments and returns. Every sentence earns its place by providing essential information without redundancy. The formatting with clear section headers (Args, Returns) enhances readability while maintaining conciseness.
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 moderate complexity, 3 parameters with 0% schema coverage, no annotations, but with an output schema, the description is mostly complete. It thoroughly documents all parameters and explains the tool's purpose and context. The main gap is lack of behavioral details like rate limits or error handling, but the output schema reduces the need to describe return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation. It explains all three parameters (min_score, sport, limit) with their purposes, default values, valid ranges, and specific sport options. The description adds significant value beyond the bare schema, which only provides titles and types without any semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get events') and resources ('prediction markets'), explaining what divergence opportunities are and how they're scored. It distinguishes from sibling tools like get_consensus, get_markets, get_settlements, and get_signals by focusing specifically on events with market disagreement rather than consensus, market listings, settlements, or signals.
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 this tool ('events where prediction markets show notable divergence' and 'where information is still being incorporated'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The context is sufficient to understand its application without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns ('recently settled events', 'verified outcomes', 'settlement history with outcomes and verification status'), though it doesn't mention potential limitations like rate limits, authentication requirements, or data freshness. The description doesn't contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It begins with a clear purpose statement, provides usage context, and then documents parameters and returns in labeled sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with output schema), the description is mostly complete. It covers purpose, usage, parameters, and returns adequately. The existence of an output schema means the description doesn't need to detail return values extensively, though it could benefit from mentioning any behavioral constraints like rate limits.
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 meaningful context beyond the input schema, which has 0% description coverage. It explains that 'limit' controls the 'Number of settled events to return' and provides the valid range (1-10) and default value (5), which aren't in the schema. This fully compensates for the schema's lack of 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's purpose with specific verbs ('Get recently settled prediction market events') and resource ('with verified outcomes'). It distinguishes from siblings by focusing specifically on settled events with outcomes, unlike tools like 'get_markets' or 'get_consensus' which likely show different data.
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 this tool ('Useful for checking how recent consensus predictions compared to actual results'), which implicitly suggests it's for post-event analysis rather than active market monitoring. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
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:

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

Score Badge

Copy to your README.md:

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

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