Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@heatpump-mcp-server Size a heat pump for my 2000 sq ft home in 02138"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for residential heat pump sizing, cost estimation, and cold-climate performance verification. Use with AI assistants like Claude Desktop, Claude Code, Cursor, and other MCP clients.
Works out-of-the-box with bundled data - no API keys required!
The server runs directly via uvx - no installation required. Your MCP client will handle this automatically.
Choose your preferred AI assistant:
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"heatpump-calculator": {
"command": "uvx",
"args": ["--refresh", "--from", "git+https://github.com/subspace-lab/heatpump-mcp-server.git", "heatpump-mcp-server"]
}
}
}Restart Claude Desktop.
Add to .claude/mcp.json in your workspace:
{
"mcpServers": {
"heatpump-calculator": {
"command": "uvx",
"args": ["--refresh", "--from", "git+https://github.com/subspace-lab/heatpump-mcp-server.git", "heatpump-mcp-server"]
}
}
}Restart VS Code.
Add to Cursor's MCP settings (Settings > MCP):
{
"mcpServers": {
"heatpump-calculator": {
"command": "uvx",
"args": ["--refresh", "--from", "git+https://github.com/subspace-lab/heatpump-mcp-server.git", "heatpump-mcp-server"]
}
}
}Restart Cursor.
Any MCP-compatible client can use:
{
"mcpServers": {
"heatpump-calculator": {
"command": "uvx",
"args": ["--refresh", "--from", "git+https://github.com/subspace-lab/heatpump-mcp-server.git", "heatpump-mcp-server"]
}
}
}That's it! The server includes:
81 heat pump models from major manufacturers
2024 state-average electricity rates for all US states
TMY3 weather station data for climate zones
No API keys needed to get started.
Related MCP server: Merlin Energy
calculate_heat_pump_sizing: Single-zone BTU sizing with humidity considerations
calculate_multi_zone_sizing: Floor-by-floor load calculations for complex homes
estimate_energy_costs: Bill comparison and 10-year payback analysis
check_cold_climate_performance: Verify capacity at design temperature
get_electricity_rate: Fetch current electricity rates by ZIP code
list_heat_pump_models: Browse 81 heat pump models with specs
design-temps/{zip_code}: Climate data and design temperatures
heat-pump-models: Complete model database with BTU, HSPF2, prices
climate-zones: ASHRAE climate zone reference
size-heat-pump: Step-by-step sizing guidance
analyze-costs: Cost comparison workflow
verify-cold-climate: Cold climate suitability check
User: I need help sizing a heat pump for my 2000 sq ft home built in 1995 in ZIP 02138.
AI: [Uses calculate_heat_pump_sizing tool]
Based on your location (Cambridge, MA - Climate Zone 5A) and home characteristics:
- Required BTU: 80,000 BTU
- Recommended range: 72,000 - 88,000 BTU
- Design temperature: 6Ā°F
...User: What would a Mitsubishi MXZ-3C30NA cost to operate vs my gas furnace?
AI: [Uses estimate_energy_costs tool]
Annual cost comparison:
- Heat pump: $1,850/year (using bundled state average rate)
- Gas furnace: $2,400/year
- Annual savings: $550
- Payback period: 8.2 years
...User: Will a Fujitsu AOU24RLXFZ work in Minneapolis?
AI: [Uses check_cold_climate_performance tool]
Cold climate analysis:
- Design temp: -13Ā°F
- Heat pump capacity at design: 18,000 BTU
- Your heating load: 75,000 BTU
- Coverage: 24% (Inadequate)
- Recommendation: You'll need substantial backup heat...For more accurate electricity rates, you can optionally provide an EIA API key:
Get a free EIA API key: https://www.eia.gov/opendata/register.php
Add to your MCP client config:
{
"mcpServers": {
"heatpump-calculator": {
"command": "uvx",
"args": ["--refresh", "--from", "git+https://github.com/subspace-lab/heatpump-mcp-server.git", "heatpump-mcp-server"],
"env": {
"EIA_API_KEY": "your_eia_api_key_here"
}
}
}
}Or create a .env file in your working directory:
# Optional: For live electricity rate lookups
EIA_API_KEY=your_eia_api_key_hereNote: Without an API key, the server uses 2024 state-average electricity rates, which are generally accurate for cost estimates.
git clone https://github.com/subspace-lab/heatpump-mcp-server.git
cd heatpump-mcp-server
uv pip install -e .If you prefer to install the package locally instead of using uvx:
# Install from GitHub
uv pip install git+https://github.com/subspace-lab/heatpump-mcp-server.git
# Then configure your MCP client to use the local installation:
{
"mcpServers": {
"heatpump-calculator": {
"command": "heatpump-mcp-server"
}
}
}Note: Using uvx with --refresh is recommended for most users as it automatically updates to the latest version.
Built on FastMCP for easy MCP server development.
Heat Pump Models: Bundled database of 81 models (Mitsubishi, Fujitsu, Daikin, LG, etc.)
Climate Data: TMY3 weather station database with design temperatures
Electricity Rates: Bundled 2024 state averages (EIA API optional for live data)
Sizing: Climate-zone specific BTU/sqft coefficients based on building age and insulation
Costs: Monthly degree-day analysis with heat pump COP curves
Cold Climate: Manufacturer capacity curves with temperature derating
# Clone repo
git clone https://github.com/subspace-lab/heatpump-mcp-server.git
cd heatpump-mcp-server
# Install with dev dependencies
uv pip install -e ".[dev]"
# Run tests
pytest
# Lint code
ruff check .heatpump_mcp_server/
āāā src/heatpump_mcp_server/
ā āāā server.py # Main MCP server
ā āāā tools.py # Calculator tools
ā āāā resources.py # Data resources
ā āāā prompts.py # Guided prompts
ā āāā config.py # Configuration
ā āāā models/ # Pydantic models
ā āāā services/ # Business logic
ā āāā quick_sizer_service.py
ā āāā bill_estimator_service.py
ā āāā cold_climate_service.py
ā āāā ...
āāā data/ # Bundled data files
ā āāā hpmodels.json # 81 heat pump models
ā āāā eeweather_stations.json # Weather data
āāā tests/
āāā pyproject.toml
āāā README.mdContributions welcome! Areas for improvement:
Additional heat pump models
More weather stations for better coverage
Manual J load calculation support
International climate zone support
MIT License - see LICENSE file for details.
Climate data from EEWeather
Heat pump specs compiled from manufacturer data
Built with FastMCP
Electricity rate fallbacks from EIA
Calculate required BTU capacity for a single-zone heat pump installation.
This tool performs a quick sizing calculation based on:
Home location (ZIP code) for climate zone and design temperature
Square footage and building age for heat loss estimation
Optional humidity considerations for enhanced dehumidification needs
Returns: Dictionary with: - required_btu: Recommended BTU capacity - btu_range_min/max: Acceptable range for equipment selection - design_temperature: Design heating temperature for location - climate_zone: ASHRAE climate zone - recommended_models: List of suitable heat pump models - calculation_notes: Detailed explanation of calculations - humidity_recommendations: Optional humidity control advice - oversizing_warnings: Warnings if system may be oversized
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | 5-digit US ZIP code | |
| square_feet | Yes | Home square footage (100-10000) | |
| build_year | Yes | Year home was built (1900-2025) | |
| humidity_concerns | No | Does home have humidity issues? | |
| humidity_level | No | Humidity level: low, normal, high, extreme | normal |
| dehumidification_priority | No | Prioritize dehumidification capability |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully explains the calculation factors (climate zone via ZIP, square footage, build year, optional humidity) and lists all return fields, making the tool's behavior transparent.
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?
Description is well-structured with bullet points and a clear return list. Each sentence adds value, and the main purpose is front-loaded. No unnecessary words.
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?
Description adequately covers inputs and outputs for a sizing tool. It includes optional humidity considerations and detailed return fields. However, it could mention that the calculation is approximate (quick sizing) or any limitations.
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 has 100% description coverage, but the tool description adds meaningful context beyond basic schema descriptions (e.g., explains how ZIP code determines climate zone and design temperature). This adds value beyond the schema.
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?
Description clearly states it calculates required BTU capacity for a single-zone heat pump installation. It lists specific inputs (ZIP code, square footage, build year, humidity) and outputs, distinguishing it from sibling 'calculate_multi_zone_sizing'.
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?
Description clearly indicates when to use the tool (for single-zone sizing) but does not explicitly state when not to use or mention alternatives. The sibling list provides context, but the description lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate heating/cooling loads for a multi-zone home with detailed zone-by-zone analysis.
Each zone should specify:
name: User-defined zone name
square_feet: Zone area (50-5000 sqft)
ceiling_height: Height in feet (7-20 ft, default 8)
zone_type: living_area, bedrooms, kitchen, basement, attic, garage, other
sun_exposure: north, south, east, west, minimal
window_coverage: Percentage of wall area as windows (0.0-0.5, default 0.15)
occupancy: high, medium, low
heat_sources: List like ["kitchen_appliances", "electronics", "home_office"]
air_sealing: tight, average, leaky
is_above_grade: True if above ground level
Returns: Dictionary with: - total_cooling_load/total_heating_load: Total BTU requirements - zone_results: Detailed results for each zone - system_options: Recommended multi-zone configurations - climate_info: Location-specific climate data - recommendations: Installation and design recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | 5-digit US ZIP code | |
| build_year | Yes | Year home was built (1900-2025) | |
| zones | Yes | List of zone configurations |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully explains inputs and outputs including zone structure and return values, but does not mention computational constraints or error conditions.
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?
Well-structured with clear breakdown of zone specification and return results, though somewhat lengthy; no wasted sentences.
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?
Output schema exists (not shown) but description provides full return structure. For a complex multi-zone tool, covers essential inputs and outputs adequately.
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 covers all 3 parameters with descriptions, but zones parameter schema is minimal (additionalProperties: true). Description adds extensive detail on zone sub-fields, compensating for schema gap.
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?
Description clearly states it calculates heating/cooling loads for multi-zone homes with detailed zone-by-zone analysis, distinguishing from siblings like calculate_heat_pump_sizing by specifying multi-zone focus.
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?
Provides detailed zone specification instructions but lacks explicit guidance on when to use this tool versus siblings or prerequisites (e.g., require construction details).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify heat pump performance at design temperature and determine backup heat requirements.
Analyzes:
Heat pump capacity at design temperature (coldest expected outdoor temp)
Percentage of heating load covered by heat pump alone
Required backup heat capacity to cover shortfall
Temperature range where heat pump provides full heating
COP (efficiency) across temperature range
Critical for cold-climate installations to ensure adequate heating on coldest days.
Returns: Dictionary with: - location_info: Climate zone and design conditions - heat_pump_model: Selected model name - capacity_curve: Heat pump capacity at various outdoor temperatures - performance_analysis: Coverage at design temp, backup heat needed - backup_heat_recommendation: Recommended backup system if needed - temperature_range_analysis: Performance across temperature ranges - key_findings: Important observations - warnings: Critical issues or limitations
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | 5-digit US ZIP code | |
| square_feet | Yes | Home square footage (100-10000) | |
| build_year | Yes | Year home was built (1900-2025) | |
| heat_pump_model | Yes | Heat pump model to analyze | |
| existing_backup_heat | No | Existing backup: electric_strip, gas_furnace, oil_boiler, none |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 describes the output in detail but does not explicitly state whether the tool is read-only or has side effects. Given the analysis nature, it implies safety, but lacks explicit behavioral disclosure.
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 structured with bullet points and includes necessary detail. It is not overly verbose, but could be slightly more concise. The front-loading with the core purpose is effective.
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 output schema exists and explains return values, the description adequately covers the tool's function, inputs, and analysis steps. It is comprehensive for a complex verification tool, leaving no critical 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?
Schema description coverage is 100% for all 5 parameters, so the baseline is 3. The description does not add significant meaning beyond the schema; it lists what is analyzed but does not elaborate on parameter specifics.
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 uses a specific verb ('Verify') and resource ('heat pump performance at design temperature') and clearly lists what it analyzes and determines. It distinguishes itself from sibling tools like 'calculate_heat_pump_sizing' by focusing on cold-climate performance and backup heat requirements.
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 explicitly states 'Critical for cold-climate installations to ensure adequate heating on coldest days,' which provides clear context for when to use. However, it does not explicitly state when not to use or list alternatives, missing an opportunity for full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate annual electricity costs and payback period for heat pump vs current heating system.
Analyzes:
Monthly heating load based on location and home characteristics
Heat pump electricity consumption using model's efficiency (HSPF2)
Comparison with current heating fuel costs
10-year cost projection with savings analysis
Break-even year calculation
Returns: Dictionary with: - location_info: Climate and location details - electricity_rate: Rate used for calculations ($/kWh) - gas_rate: Comparison fuel rate if applicable - heat_pump_info: Selected model specifications - monthly_breakdown: Month-by-month cost comparison - annual_summary: Annual totals and payback analysis - ten_year_projection: Long-term savings projection - calculation_notes: Important assumptions and notes
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | 5-digit US ZIP code | |
| square_feet | Yes | Home square footage (100-10000) | |
| build_year | Yes | Year home was built (1900-2025) | |
| heat_pump_model | Yes | Selected heat pump model name | |
| gas_price_per_therm | No | Local gas price per therm ($) | |
| electricity_rate_override | No | Manual electricity rate ($/kWh) | |
| current_heating_fuel | No | Current heating fuel: gas, oil, propane, electric | gas |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It details output structure but omits behavioral traits like data sources, limits, or assumptions beyond mentioning 'calculation_notes'.
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?
Description is well-structured with bullet points, front-loaded purpose, and every sentence adds value without fluff.
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 7 parameters, 4 required, and a full output schema described, the description is thorough. Minor omission: no mention of rate defaulting or fallback behavior.
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 covers 100% of parameters, and description adds context by grouping parameters into analysis steps, enhancing meaning beyond the schema alone.
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 estimates annual electricity costs and payback period for heat pump vs current system, and lists detailed analysis areas. It distinguishes from sibling tools like sizing calculators.
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 implicitly conveys usage for cost comparison, but lacks explicit guidance on when not to use or 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.
Get the current electricity rate for a specific ZIP code location.
Fetches residential electricity rates from EIA (Energy Information Administration) API. Requires EIA_API_KEY environment variable to be set.
Returns: Dictionary with: - zip_code: Input ZIP code - electricity_rate: Rate in $/kWh - unit: Always "$/kWh" - source: Data source information
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | 5-digit US ZIP code |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it fetches from an external API (EIA), requires an API key, and returns a dictionary with specific fields. It does not mention error handling or rate limits, but for a simple read operation, this is sufficient.
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 very concise: two main sentences followed by bulleted return fields. It is front-loaded with the core purpose and contains no fluff.
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 a single parameter, no annotations, and an output schema present, the description is complete. It explains the data source, prerequisite, and return format.
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 has 100% coverage for the one parameter 'zip_code' with a clear description. The description adds no extra detail beyond 'ZIP code location', so baseline 3 is appropriate.
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 gets the current electricity rate for a specific ZIP code, using a verb (get) and resource (electricity rate). It distinguishes from sibling tools which are all about heat pump sizing.
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 mentions the requirement of EIA_API_KEY environment variable as a prerequisite, but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied by the context of electricity rates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available heat pump models, optionally filtered by brand, capacity, or efficiency.
Returns comprehensive database of heat pump models with:
Brand and model name
BTU capacity (heating/cooling)
HSPF2 efficiency rating (higher is more efficient)
Estimated price range
Filters:
brand: Case-insensitive partial match (e.g., "Mitsubishi", "Fujitsu")
min_btu/max_btu: Capacity range for sizing
min_hspf2: Minimum efficiency threshold (typical range: 8.0-12.0)
Returns: Dictionary with: - total_models: Count of models matching filters - brands: List of available brands - models: List of model details
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Filter by brand name | |
| min_btu | No | Minimum BTU capacity | |
| max_btu | No | Maximum BTU capacity | |
| min_hspf2 | No | Minimum HSPF2 efficiency rating |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 transparently describes the return structure and filter behavior (e.g., case-insensitive partial match for brand, typical HSPF2 range). No side effects are expected, and the description adequately covers 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 well-structured with clear sections for overview, return values, and filter details. It is concise but could be slightly tightened (e.g., some redundancy between filter list and explanation). Still, it is efficient and front-loaded.
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 output schema exists, the description sufficiently explains the return structure (total_models, brands, models). It covers the essential aspects for a listing tool. No major gaps are apparent.
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 coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema (e.g., 'Case-insensitive partial match' for brand, 'Capacity range for sizing' for BTU, 'typical range: 8.0-12.0' for min_hspf2), enhancing usability.
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 lists heat pump models with optional filters, using a specific verb ('List') and resource ('heat pump models'). It distinguishes from siblings like calculate_heat_pump_sizing by focusing on retrieval rather than calculation.
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 explains when to use the tool and details each filter with examples. While it doesn't explicitly state when not to use it, the sibling context provides differentiation. The filter descriptions are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0calculate_heat_pump_sizingcalculate_multi_zone_sizingcheck_cold_climate_performanceestimate_energy_costsget_electricity_ratelist_heat_pump_modelsEach tool has a clearly distinct purpose: single-zone sizing, multi-zone sizing, cold-climate performance verification, energy cost estimation, electricity rate lookup, and model listing. There is no overlap or ambiguity between tools.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., calculate_heat_pump_sizing, list_heat_pump_models), making the naming predictable and easy to understand.
With 6 tools covering core aspects of heat pump sizing and analysis, the count is well-scoped. Each tool serves a necessary function without redundancy or unnecessary complexity.
The tool surface covers major workflows: sizing (single and multi-zone), cold climate performance, cost estimation, and model listing. Minor gaps exist, such as no direct tool for comparing models or generating full reports, but these are not critical for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
AI-powered job cost estimator for skilled trades with material and labor breakdowns
Property management AI: work orders, vendors, appliances, and triage for Claude and ChatGPT.
Design, solve and simulate HVAC systems from real components, weather years and buildings.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jiweiqi/heatpump-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
