Soljo Solar (Switzerland)

Building energy profile (Switzerland)

building_energy_profile

Read-onlyIdempotent

Soljo Data: full solar profile for one Swiss building from official data. Returns the roof faces (Sonnendach, BFE), building facts from the federal register (construction period, floors, heating energy source), measured shading from the swisstopo LiDAR surface model, system size and annual yield, and the economics: turnkey cost, subsidies, local electricity price (ElCom), feed-in tariff, self-consumption, savings, payback and 25-year net result. Same calculation as the Soljo report. Every value block lists sourceIds that resolve to sources; cite them. Without api_key a small shared free allowance applies; a free key with 100 profiles per month: https://soljo.ch/developers. Takes about 2 to 5 seconds.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "building_energy_profile"
  }
}

Input Schema

Name	Required	Description
`ev`	No	Household has or plans an electric car.
`address`	Yes	Swiss street address with house number and postcode, e.g. 'Bundesplatz 3, 3011 Bern'.
`api_key`	No	Soljo Data API key (sjd_…). Optional.
`battery`	No	Include a battery recommendation and its payback.
`heat_pump`	No	Household has or plans a heat pump.
`household_size`	No	People in the household (default 3); drives consumption and self-consumption.
`annual_consumption_kwh`	No	Known annual electricity consumption in kWh; overrides household_size.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only/open-world/idempotent annotations, the description discloses authentication behavior, the shared free allowance without api_key, a free-key quota of 100 profiles per month, and a 2 to 5 second latency. It also states that every value block has sourceIds that must be cited, which is important behavioral context for downstream use.

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 dense but front-loaded: purpose first, then returned data, citation requirement, access terms, and latency. The long enumeration of output blocks is functional rather than padded, though it makes the paragraph heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with seven parameters and no output schema, the description is complete enough: it enumerates the return blocks, explains sourceIds and citation obligations, covers authentication and quota, and notes expected latency. No critical calling information is missing.

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%, so the schema already defines all seven parameters, including the household_size default and annual_consumption_kwh override. The description adds useful api_key quota context, but it does not add semantic detail for the other parameters beyond what the schema provides.

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 states a specific verb and resource: a full solar profile for one Swiss building from official data. It enumerates the returned profile blocks, making the scope concrete. The word 'full' also implicitly distinguishes it from the sibling solar_first_estimate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'full solar profile for one Swiss building' and by the latency note, but the description does not explicitly say when to choose this over solar_first_estimate or other alternatives. It also gives no when-not-to-use conditions, leaving the agent to infer routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Soljo Solar (Switzerland) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?