Utilizes OpenAI's language models to assist in the formatting and generation of commercial Battery Energy Storage System (BESS) proposals.
Leverages Resend to automate the delivery of generated BESS proposals and sales documents via email.
Integrates with Supabase to provide backend infrastructure for tracking and managing analytics related to BESS quotes and lead scoring.
The only MCP server for commercial BESS (Battery Energy Storage) quoting. TrueQuote estimates, lead qualification, competitor battle cards, and proposals inside Claude or any MCP-compatible AI client.
npx @merlinpro/mcp-agentRelated MCP server: swarmix-mcp
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"merlin-energy": {
"command": "npx",
"args": ["-y", "@merlinpro/mcp-agent"],
"env": {
"OPENAI_API_KEY": "sk-...",
"SUPABASE_URL": "https://xxxx.supabase.co",
"SUPABASE_SERVICE_ROLE_KEY": "eyJ..."
}
}
}
}Restart Claude Desktop — the Merlin Energy tools appear in the ⚙ menu.
Tool | Description |
| 47-variable BESS sizing + financial model (cost, savings, payback, NPV, IRR, CO2) |
| Score leads 0-100 across 18 industry verticals: hot / warm / nurture |
| Battle cards vs Homer Energy, EnerNOC, manual Excel |
| Executive summary, detailed, or one-pager format |
| NREL and EIA benchmarks: cost curves, utility rates, ROI by sector |
| Data-backed responses to the 5 most common BESS sales objections |
URI | Content |
| Full platform overview |
| TrueQuote competitive advantages |
| Industry ROI benchmarks |
| Objection-handling playbook |
Prompt | Modes |
| Cold opener for BESS sales conversations |
| investor / EPC / SMB / manufacturer |
Variable | Required | Description |
| Yes | OpenAI key for proposal formatting |
| Optional | Supabase URL for analytics |
| Optional | Supabase service role key |
| Optional | Resend key for email delivery |
| Optional | Merlin Partner API base URL |
Merlin TrueQuote | Homer Energy | Manual Excel | |
Time per quote | Seconds | 12-18 hours | 90+ hours |
Variables used | 47 | ~12 | ~8 |
Accuracy vs. installs | 95%+ | ~85% | ~70% |
Annual cost | $299/mo+ | $3K-$15K/yr | Staff time |
MCP integration | Yes | No | No |
REST API (OpenAPI 3.1.0) for programmatic quoting, leads, and benchmarks.
Plan | Price | Rate Limit |
Starter | $299/mo | 100 req/hr |
Professional | $499/mo | 500 req/hr |
Enterprise | $999/mo | 5,000 req/hr |
Docs: merlinpro.energy/api
git clone https://github.com/merlinpro/merlin-mcp-agent
cd merlin-mcp-agent
npm install
npm run dev # hot reload via tsx
npm run build # tsc -> dist/index.jsLocal test (stdio):
{
"mcpServers": {
"merlin-energy-dev": {
"command": "node",
"args": ["/path/to/dist/index.js"],
"env": { "OPENAI_API_KEY": "sk-..." }
}
}
}MIT © Merlin Energy
Get a competitive analysis comparing Merlin against a specific competitor. Use when handling objections or competitive situations.
| Name | Required | Description | Default |
|---|---|---|---|
| competitor | Yes | Competitor to compare against | |
| context | No | Specific comparison context or objection being raised |
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.
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.
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.
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.
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.
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.
Generate a professional BESS proposal document for a prospect. Formats: executive-summary, detailed-proposal, or one-pager.
| Name | Required | Description | Default |
|---|---|---|---|
| prospectName | Yes | Prospect company name | |
| industry | Yes | Industry vertical | |
| systemSizeMW | Yes | Recommended BESS size in MW | |
| durationHours | Yes | BESS duration in hours | |
| totalCostDollars | Yes | Total installed cost in USD | |
| annualSavingsDollars | Yes | Annual savings in USD | |
| paybackYears | Yes | Simple payback period | |
| npvDollars | Yes | 25-year NPV in USD | |
| irrPercent | Yes | IRR as percentage | |
| format | No | executive-summary |
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.
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.
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.
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.
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.
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.
Generate a TrueQuote™ BESS recommendation and ROI analysis for a prospect. Use this when a prospect wants to know if battery storage makes sense for their facility.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | Yes | Industry vertical of the prospect | |
| peakDemandKw | Yes | Peak electrical demand in kilowatts | |
| monthlyBillDollars | Yes | Average monthly utility bill in dollars | |
| zipCode | Yes | 5-digit US ZIP code | |
| primaryUseCase | No | Primary application for the BESS | peak-shaving |
| hasSolar | No | Does the facility have or plan solar? | |
| solarMW | No | Existing/planned solar size in MW | |
| desiredPaybackYears | No | Target payback period |
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.
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.
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.
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.
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.
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.
Retrieve authoritative energy market benchmark data (BESS costs, solar costs, utility rates, ROI by industry, market size).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category of benchmark data | |
| industry | No | Specific industry for industry-specific benchmarks |
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.
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.
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.
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.
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.
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.
Get the best Merlin response to a common sales objection.
| Name | Required | Description | Default |
|---|---|---|---|
| objection | Yes | The objection raised by the prospect |
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.
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.
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.
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.
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.
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.
Qualify a sales lead and determine urgency tier (hot/warm/nurture). Returns a score, recommended actions, and routing decision.
| Name | Required | Description | Default |
|---|---|---|---|
| companyName | Yes | Company name | |
| industry | Yes | Industry type | |
| annualRevenue | No | Approximate annual revenue in USD | |
| numberOfLocations | No | Number of facilities | |
| decisionTimeline | Yes | Purchasing timeline | |
| currentPain | Yes | Primary energy challenge they are trying to solve | |
| contactInfo | No |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build and manage AI-native customer support agents from Claude or any MCP client.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
AI Visibility and Content Intelligence tools for Claude and MCP-compatible agents.
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
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
