Merlin Energy

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: compare_competitor for competitive analysis, generate_proposal for proposal documents, generate_truequote for ROI analysis, get_benchmarks for market data, handle_objection for sales responses, and qualify_lead for lead assessment. The descriptions explicitly differentiate when to use each tool, preventing misselection.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as compare_competitor, generate_proposal, and qualify_lead. This predictable naming convention makes the tool set easy to navigate and understand, with no deviations in style or structure.
Tool Count5/5
With 6 tools, the server is well-scoped for its sales and energy domain, covering competitive analysis, proposal generation, ROI analysis, market data, objection handling, and lead qualification. Each tool earns its place without feeling excessive or insufficient for the apparent purpose.
Completeness4/5
The tool set provides strong coverage for sales workflows in the energy sector, including lead qualification, proposal generation, and competitive responses. A minor gap exists in follow-up or closing tools, such as scheduling meetings or contract management, but agents can work around this with the available tools.
Average 3.2/5 across 6 of 6 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 is passing
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 full burden for behavioral disclosure. It mentions output formats but doesn't describe what the generated document contains, whether it's editable, how it's delivered, or any side effects. 'Generate' implies creation but lacks details about permissions, data persistence, or error handling that would help an agent understand the tool's behavior.
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 - just one sentence that efficiently communicates the core purpose and output formats. Every word earns its place with no redundancy or unnecessary elaboration. It's front-loaded with the main purpose followed by format options.
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 10-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'BESS proposal document' contains, how the financial parameters relate to the output, what happens after generation, or any error conditions. The agent would struggle to understand the tool's full context and behavior from this minimal description.
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 90%, so the schema already documents most parameters well. The description adds minimal value beyond the schema - it mentions 'formats' which corresponds to the 'format' parameter with enum values, but doesn't explain the semantic differences between executive-summary, detailed-proposal, and one-pager formats. This meets the baseline for high schema coverage.
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 professional BESS proposal document for a prospect.' It specifies the verb ('generate'), resource ('proposal document'), and domain context ('BESS' - Battery Energy Storage System). However, it doesn't explicitly differentiate from sibling tools like 'generate_truequote' or 'compare_competitor' which might also generate documents or comparisons.
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 minimal usage guidance. It mentions three output formats but doesn't explain when to choose each format or when to use this tool versus alternatives like 'generate_truequote' or 'handle_objection'. There's no context about prerequisites, ideal scenarios, or limitations.
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 returns 'the best Merlin response,' but doesn't explain what 'best' means (e.g., based on criteria like effectiveness or data), whether it's a read-only operation, if there are rate limits, or what the output format looks like. For a tool with no annotations, this is insufficient to understand its behavior beyond the basic 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?
The description is a single, efficient sentence: 'Get the best Merlin response to a common sales objection.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. 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's complexity (simple with one parameter) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like how responses are generated, potential limitations, or what the output contains. For a tool that likely involves AI or data processing, more context is needed to ensure the agent can use it effectively without structured 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 input schema has 100% description coverage, with the parameter 'objection' described as 'The objection raised by the prospect.' The description doesn't add any meaning beyond this, such as examples of common objections or formatting tips. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately documents the parameter without extra help from the description.
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 the best Merlin response to a common sales objection.' It specifies the action ('Get') and the resource ('Merlin response'), though it doesn't explicitly differentiate from sibling tools like 'compare_competitor' or 'qualify_lead', which might also handle sales-related queries. The purpose is clear but 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 scenarios where it's appropriate, prerequisites, or exclusions. For example, it doesn't clarify if it's for common objections only or all objections, or how it differs from other sales tools in the sibling list. This leaves usage ambiguous.
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 returns a score, recommended actions, and routing decision, which gives some output context. However, it lacks critical details: whether this is a read-only analysis or triggers follow-ups, permission requirements, rate limits, or how the urgency tier is calculated. For a tool with 7 parameters and 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 a single, efficient sentence that front-loads the core purpose and outputs. There's no wasted text, but it could be slightly more structured (e.g., separating purpose from return values). Overall, it's appropriately concise for the tool's complexity.
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 moderate complexity (7 parameters, nested objects) and lack of annotations or output schema, the description is partially complete. It covers the purpose and return types, which helps, but misses behavioral context and parameter guidance. This is adequate for a basic understanding but leaves gaps for effective agent 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?
Schema description coverage is high (86%), so the baseline is 3. The description adds no specific parameter information beyond what the schema provides—it doesn't explain how inputs like 'annualRevenue' or 'decisionTimeline' influence the qualification. This meets the minimum viable standard but doesn't compensate for the 14% coverage gap (e.g., nested 'contactInfo' object details).
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: 'Qualify a sales lead and determine urgency tier (hot/warm/nurture).' It specifies the verb ('qualify') and resource ('sales lead') with concrete outputs (score, actions, routing). However, it doesn't explicitly differentiate from sibling tools like 'generate_proposal' or 'handle_objection', which might also involve lead processing.
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 prerequisites, timing in the sales process, or how it differs from sibling tools such as 'compare_competitor' or 'generate_truequote'. The agent must infer usage from the purpose 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?
No annotations are provided, so the description carries the full burden. It states the tool retrieves data but lacks details on behavioral traits such as data freshness, rate limits, authentication needs, or response format. This is inadequate 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.
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 and lists key data types. There is no wasted verbiage, and it directly communicates the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It covers the purpose but misses critical behavioral context and output details. However, the schema is well-documented, and the tool's complexity is moderate, making it minimally viable but with clear gaps.
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%, with clear descriptions for both parameters. The description adds minimal value beyond the schema by listing benchmark categories, but it does not explain parameter interactions (e.g., how 'industry' relates to 'category') or provide usage examples.
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 'retrieve' and specifies the resource as 'authoritative energy market benchmark data', listing concrete examples (BESS costs, solar costs, etc.). It distinguishes this tool from siblings like 'compare_competitor' or 'generate_proposal' by focusing on data retrieval rather than analysis or generation.
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 does not mention prerequisites, exclusions, or comparisons to sibling tools like 'compare_competitor' or 'generate_truequote', leaving the agent to infer 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 carries the full burden of behavioral disclosure. The description mentions the tool's purpose and usage context but lacks critical behavioral details: it doesn't specify what the analysis includes (e.g., features, pricing, strengths/weaknesses), whether it's read-only or has side effects, or any limitations (e.g., only covers listed competitors). For a tool with no annotation coverage, 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 extremely concise and front-loaded: two sentences that directly state purpose and usage guidelines with zero wasted words. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (competitive analysis with 2 parameters) and no annotations or output schema, the description is minimally adequate. It covers purpose and usage but lacks details on behavioral traits, output format, or limitations. Without annotations to fill gaps, the description should do more to be complete for an agent.
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%, with both parameters ('competitor' and 'context') well-documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain the 'other' enum option or provide examples for 'context'). Baseline 3 is appropriate since the schema handles 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 a competitive analysis comparing Merlin against a specific competitor.' This specifies the verb ('Get'), resource ('competitive analysis'), and scope ('Merlin against a specific competitor'). However, it doesn't explicitly differentiate from sibling tools like 'handle_objection' or 'get_benchmarks', which might have overlapping competitive analysis functions.
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 usage: 'Use when handling objections or competitive situations.' This gives practical guidance on when to invoke the tool. However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools (e.g., 'handle_objection' might be for general objections, while this is specifically for competitive comparisons).
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 generating a recommendation and ROI analysis, implying a read-only or analytical operation, but doesn't specify if this is a simulation, requires external data, has rate limits, or what the output format looks like. For a tool with 8 parameters and no annotations, this leaves significant gaps in understanding its behavior and constraints.
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, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place by clearly stating what the tool does and when to use it, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers purpose and usage well, but lacks details on behavioral aspects like output format, error handling, or dependencies. Without annotations or output schema, more context on what the tool returns or how it operates would improve completeness for this analytical tool.
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%, meaning all parameters are documented in the schema itself. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema, such as explaining relationships between fields like 'hasSolar' and 'solarMW'. 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: 'Generate a TrueQuote™ BESS recommendation and ROI analysis for a prospect.' It specifies the verb ('generate') and resource ('TrueQuote™ BESS recommendation and ROI analysis'), but doesn't explicitly differentiate from sibling tools like 'generate_proposal' or 'compare_competitor', which might also involve generating analyses or comparisons.
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: 'Use this when a prospect wants to know if battery storage makes sense for their facility.' This gives a specific scenario, but it doesn't mention when not to use it or explicitly name alternatives among sibling tools, such as 'qualify_lead' for initial assessments or 'compare_competitor' for competitive analysis.
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:

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

Score Badge

Copy to your README.md:

[![merlin-mcp-agent MCP server](https://glama.ai/mcp/servers/ugobe007/merlin-mcp-agent/badges/score.svg)](https://glama.ai/mcp/servers/ugobe007/merlin-mcp-agent)

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/ugobe007/merlin-mcp-agent'

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