Provides satellite-based solar potential analysis via Google Solar API, enabling roof surface calculation, orientation detection, roof segmentation, and photovoltaic panel placement optimization for solar estimates.
MCP (Model Context Protocol) server for Solematica — solar estimates, provider comparison and energy data for Italy.
This server enables AI assistants like Claude, Cursor, Windsurf, Kiro and other MCP-compatible clients to analyze solar potential, compare photovoltaic providers, check energy prices and search energy-related articles for the Italian market.
Tool | Description | Auth |
| Generate a full solar estimate for an Italian address — production, savings, ROI, panel sizing | API key |
| Satellite roof analysis via Google Solar API — surface, orientation, segments, panel potential | Free |
| Compare 11 Italian solar providers — prices, components, warranties, transparency index | Free |
| Full provider detail — accessories (heat pumps, EV chargers, boilers), contacts, financing | Free |
| Free | |
| Search Solematica blog articles by category or keyword | Free |
Related MCP server: SwitchAI
Add to your claude_desktop_config.json:
{
"mcpServers": {
"solematica": {
"command": "npx",
"args": ["@solematica/mcp-server"],
"env": {
"SOLEMATICA_API_KEY": "your-api-key"
}
}
}
}claude mcp add solematica npx @solematica/mcp-serverAdd to your .cursor/mcp.json:
{
"mcpServers": {
"solematica": {
"command": "npx",
"args": ["@solematica/mcp-server"],
"env": {
"SOLEMATICA_API_KEY": "your-api-key"
}
}
}
}Add to your ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"solematica": {
"command": "npx",
"args": ["@solematica/mcp-server"],
"env": {
"SOLEMATICA_API_KEY": "your-api-key"
}
}
}
}Any MCP-compatible client can use this server via stdio transport:
npx @solematica/mcp-serverAPI key is only required for stima_solare (consumes credits per estimate)
All other tools are free and public — no API key needed
Get an API key by registering as a partner at solematica.it/partner
Variable | Required | Default | Description |
| Only for | — | Your API key for authenticated endpoints |
| No |
| API base URL (for self-hosted or testing) |
stima_solareGenerates a complete solar estimate for an Italian address using Google Solar API + PVGIS data.
Input:
indirizzo (required) — Full Italian address (e.g. "Via Roma 1, 20100 Milano MI")
consumo_annuo_kwh — Annual electricity consumption in kWh (default: 3500)
tipo_abitazione — Building type: indipendente, bifamiliare, schiera, condominio
superficie_tetto_mq — Roof surface in sqm (auto-calculated from satellite if omitted)
orientamento — Roof orientation: nord, sud, est, ovest
Returns: kWp sizing, panel count, annual production, monthly distribution, savings, ROI, CO2 avoided, cost estimate.
info_tettoAnalyzes a roof using Google Solar API satellite data.
Input:
lat (required) — Latitude
lng (required) — Longitude
Returns: Roof surface, usable area, orientation, roof segments, max panel count, sunshine hours.
confronta_providerLists all active Italian solar providers with comparison data. See the full provider comparison on Solematica.
Returns: Array of providers with name, price (3 kWp), panel brand, inverter brand, warranty, transparency index (1-3), and accessory services availability (heat pump, EV charger, boiler).
dettaglio_providerFull detail for a specific provider.
Input:
slug (required) — Provider slug: enel, iren, plenitude, otovo, eon, hera, a2a, edison, engie, sorgenia, bluenergy
Returns: All comparison data plus: description, phone, headquarters, founding year, financing details, accessory service details with URLs.
prezzi_energiaCurrent Italian energy prices from the Solematica database, updated monthly from ARERA and GME.
Returns: Self-consumption price (EUR/kWh), SSP price, cost per kWp range, battery cost per kWh, last update date.
cerca_articoliSearch the Solematica blog for energy-related articles.
Input:
categoria — Filter by category (e.g. fotovoltaico, incentivi, risparmio)
limit — Max results (default: 10, max: 50)
Returns: Article list with title, slug, category, date, description, and full URL.
Ask Claude:
"Quanto produrrebbe un impianto fotovoltaico in Via Garibaldi 15, Torino?"
"Confronta le offerte fotovoltaico di Enel e Iren"
"Quali provider offrono anche la pompa di calore?"
"Qual e il prezzo corrente dell'energia in Italia?"
"Cerca articoli sugli incentivi fotovoltaico 2026"
Solematica — Main platform
Provider Comparison — Compare 11 Italian solar providers
Solar Estimate — Free solar estimate tool
Energy Guide — Complete energy guide
API Documentation — REST API docs
Blog — Energy articles and news
npm Package — npm registry page
Model Context Protocol — MCP specification
MCP Servers — More MCP servers
Google Solar API — Satellite-based solar potential
PVGIS — EU photovoltaic estimation tool
ARERA — Italian energy regulator
Superbonus & Incentivi — Italian solar incentives info
MIT — see LICENSE file.
Cerca articoli nel blog di Solematica per categoria o keyword. Restituisce titolo, slug, categoria, data e meta description. Non richiede API key.
| Name | Required | Description | Default |
|---|---|---|---|
| categoria | No | Filtro per categoria (es. 'fotovoltaico', 'incentivi', 'risparmio') | |
| limit | No | Numero massimo di risultati (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return fields (title, slug, category, date, meta description) and authentication requirements (no API key) since no annotations exist.
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?
Three efficient sentences: action, return values, auth requirements. 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?
Compensates well for missing output schema by enumerating return fields; adequate for simple 2-parameter 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?
Description mentions 'keyword' filtering but schema only provides 'categoria' parameter, creating potential confusion about capabilities.
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?
Clearly states it searches Solematica blog articles and distinguishes from utility-oriented siblings (provider comparison, solar estimates), though mentions 'keyword' search not reflected in schema.
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?
No guidance on when to use versus siblings or content retrieval alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restituisce il confronto aggiornato delle offerte fotovoltaico dei principali operatori italiani (Enel, Iren, Plenitude, Otovo, E.ON, Hera, ecc.). Include prezzi, brand componenti, garanzie, finanziamento e indice di trasparenza. Non richiede API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data freshness ('aggiornato') and auth requirements ('Non richiede API key') in absence of annotations, though omits rate limits or caching details.
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?
Two dense sentences covering scope, data fields, and auth; no redundancy or filler content.
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?
Adequately compensates for missing output schema by enumerating return data points (prezzi, brand, garanzie), sufficient for simple parameterless 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?
Zero-parameter tool meets baseline expectation; description appropriately silent on parameters since schema is empty.
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?
Specific verb (restituisce/confronto) and resource (offerte fotovoltaico) with explicit differentiation from sibling 'dettaglio_provider' via multi-operator comparison scope.
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?
Usage is implied by the comparison framing vs sibling tools, but lacks explicit when/when-not guidance or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restituisce la scheda completa di un operatore fotovoltaico italiano: prezzi, componenti, garanzia, finanziamento, servizi accessori (pompa di calore, wallbox, caldaia), contatti e descrizione. Non richiede API key.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug del provider (es. 'iren', 'enel', 'plenitude', 'otovo', 'eon', 'hera', 'a2a', 'edison', 'engie', 'sorgenia', 'bluenergy') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses 'Non richiede API key' and enumerates returned data fields (prezzi, componenti, garanzia), compensating for missing annotations and output schema.
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?
Two compact sentences: first front-loaded with complete data taxonomy, second notes auth requirement. No 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?
Without output schema, comprehensively lists return data categories (finanziamento, servizi accessori, contatti) providing sufficient invocation context.
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% coverage with examples; description adds no parameter detail but meets baseline since structured documentation is complete.
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?
Specific verb (restituisce) + resource (scheda completa operatore fotovoltaico) clearly distinguishes from siblings like confronta_provider (comparison) and cerca_articoli (search).
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?
Implicitly suggests use for single-provider deep dives vs comparison, but lacks explicit when-to-use/when-not-to-use guidance relative to confronta_provider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analizza un tetto tramite dati satellitari Google Solar API. Restituisce superficie, orientamento, segmenti del tetto e potenziale per pannelli solari. Non richiede API key.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitudine (es. 45.464) | |
| lng | Yes | Longitudine (es. 9.190) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (Google Solar API), authentication requirements (no API key needed), and return values, compensating for lack of annotations and output schema.
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?
Three tight sentences: action, returns, and auth requirements. Front-loaded with specific verb and no filler.
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?
Adequately covers tool behavior and return structure given simple input schema and absence of output schema, though rate limits or error scenarios are not mentioned.
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 with examples; description adds no parameter-specific semantics but meets baseline given high schema quality.
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?
Clearly states the tool analyzes roofs using Google Solar satellite data and lists specific outputs (surface, orientation, segments, solar potential), distinguishing it from generic solar tools.
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?
No explicit guidance on when to use this versus sibling 'stima_solare' or other alternatives; usage must be inferred from output description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restituisce i prezzi correnti dell'energia elettrica in Italia (PUN, ARERA) con data di aggiornamento. Utile per calcoli di risparmio e confronti. Non richiede API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authentication requirements ('Non richiede API key') and output metadata ('con data di aggiornamento'), but omits rate limits, caching behavior, or real-time vs delayed data details.
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?
Two well-structured sentences with zero fluff: immediate action statement followed by use case and auth note.
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?
Adequately covers simple retrieval scope by specifying geographic scope (Italia), price types (PUN/ARERA), and temporal metadata despite lack of output schema.
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?
Zero-parameter tool meets baseline; description correctly implies no configuration needed via 'Non richiede API key' and absence of parameter mentions.
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?
Specific verb ('restituisce') and resource ('prezzi correnti dell'energia elettrica'), with technical distinctions (PUN, ARERA) that differentiate it from sibling provider comparison tools.
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?
Implies usage context ('Utile per calcoli di risparmio e confronti') but lacks explicit when-not-to-use guidance or contrast with 'confronta_provider'/'dettaglio_provider'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Genera una stima del potenziale fotovoltaico per un indirizzo in Italia. Analizza il tetto via satellite, calcola produzione, risparmio, ROI e dimensionamento ottimale. Richiede API key con crediti.
| Name | Required | Description | Default |
|---|---|---|---|
| indirizzo | Yes | Indirizzo completo in Italia (es. 'Via Roma 1, 20100 Milano MI') | |
| consumo_annuo_kwh | No | Consumo elettrico annuo in kWh (default 3500) | |
| tipo_abitazione | No | Tipo di abitazione | |
| superficie_tetto_mq | No | Superficie tetto in mq (opzionale, calcolata da satellite se omessa) | |
| orientamento | No | Orientamento tetto: nord, sud, est, ovest (opzionale) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical requirements (API key with credits) and methodology (satellite analysis) that schema doesn't cover; no annotations provided to contradict.
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?
Three well-structured sentences: purpose, capabilities/methodology, and requirements—every sentence earns its place with no 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?
Lists calculated outputs (production, savings, ROI, sizing) compensating for missing output schema; could briefly mention output format/structure.
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%, establishing baseline 3; description mentions 'indirizzo' contextually but doesn't need to elaborate given comprehensive 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?
Clear specific action (estimates PV potential) with resource (Italian address) and distinguishes from siblings like info_tetto or prezzi_energia by mentioning satellite analysis and financial calculations.
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?
Usage is implied by the specific domain (solar estimation vs siblings for articles/providers/energy prices), but lacks explicit when/when-not guidance or comparison with info_tetto.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools serve distinct purposes (blog search, provider comparison, energy prices), but info_tetto and stima_solare both analyze roof/satellite data with overlapping outputs (surface, potential), which could cause confusion about which to use for solar analysis.
All tools use Italian snake_case, but mix verb-noun (cerca_articoli, confronta_provider) with noun-noun patterns (dettaglio_provider, prezzi_energia, stima_solare, info_tetto). The language and separator are consistent, but the grammatical pattern varies.
Six tools is well-scoped for a solar/PV consulting domain, covering content (blog), market data (providers, prices), and technical analysis (roof data, estimates) without bloat. Each tool earns its place in the workflow.
Covers the core solar consultation lifecycle: education (blog), market comparison (providers), technical assessment (roof analysis), and economic calculation (prices, ROI). Minor gap: no explicit list_providers tool to discover available operators before requesting details, though confronta_provider may serve this indirectly.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Free solar & home energy tools: estimates, incentives by ZIP, scores, installer routing.
dati.gov.it MCP — Italy's national open-data portal (CKAN API).
Italian cross-dealer MCP: cars, NLT rentals with quotations, dealer directory, automotive KB.
PVGIS MCP — EU Joint Research Centre PV system modeler
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/n3m1/solematica-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
