Skip to main content
Glama

Get building details

get_building
Read-onlyIdempotent

Returns every fact baseray holds on one building, by the buildingId an earlier result gave, as the baseray app's building panel shows it. Use for questions about one building already found; it does not find a building by address. It holds statedFacts, what the building's record states (declared use, construction year, floors, built and floor areas, units, cadastral number, where known); parts, what a building drawn from parts is made of: each construction the register records (by its label) and each structure it does not, with its area and what its outline traces (walls at ground level or a roof from above); addresses, every address of the building (each entrance of a block with the dwellings behind it, a corner building's second street) and whether its records agree on the number; units, the units and dwellings its record lists, floor by floor and kind by kind (dwellings, shops, parking, storage), against the totals the record states, the entrances they are reached by and the dwellings the record counts behind each entrance (the units themselves are listed separately); recordSheet, the identity numbers its record carries (cadastral or property number, where the record keeps one; a land book number only as filed in the register, unverified and often an old paper land book's, never the land book in force) and every other fact on record, by section as its register lays it out (such as use, areas, storeys, construction, heating and utilities, energy certificate, accessibility); roofAnalysis, the analysed roof plane by plane (facing, pitch, area, sunshine, panels) with the panel its layout assumes; record, the roof (shape, eave height, 3D model, CO2 the solar potential would save, the roof photo's analysis date and resolution), the local climate (coldest and hottest day, frost and hot days, rainfall, for the last complete year, the recent years' average and this year so far; heating degree-days against the climate normal; the warming trend), gas and district-heating network evidence from the locality down to the building, and the heating estimate. Sizes carry their basis: measured, stated or estimated. The heating figures are model estimates, never metered values, given as two figures. The standard need, full heating at standard conditions, says whether it is checked, modelled or the building's own documented assessment: the annual heat need for space heating of the building as built (in total, per m² of heated floor area and per dwelling) and the energy the heating takes in for it, a low/high span of the need where the number of floors or the construction year is not on record, the need under each construction period where the construction year is not on record and, where a check of the model against reference buildings it was not fitted on measured its error, the band 8 in 10 of them fell in and what they were checked against. The expected use, typical heating for its heating type, occupied, is always modelled and never banded: the energy a typical occupied home like this one takes in for heating, its range over the storeys, eras and heating types it may have and how homes like it are heated in its area. Beside them: the heat in the hot water (separate from space heating), the peak heat load with the outdoor temperature it is worked out at and heat-pump electricity per performance factor. It also lists the businesses whose registered office is at its address, with their registration numbers, stated sizes, legal forms, whether a business is a person's (a sole proprietorship or an estate) and whether their register protects them from direct marketing, and the credits their registers require. A registered office is not proof that the business owns or occupies the building. Cost: 1 credit to open a building the workspace has not opened in the last year; free once opened.

Input Schema

NameRequiredDescriptionDefault
buildingIdYesThe baseray building id (`buildingId` in an earlier result).
includeRegisteredBusinessesNoWhether to list the businesses registered at the building's address. Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / buildingId / description
      Previous value: -"The baseray building id returned by find_buildings or search_buildings."New value: +"The baseray building id (`buildingId` in an earlier result)."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations by disclosing the credit model ('1 credit to open a building the workspace has not opened in the last year; free once opened'), warning that heating figures are modelled estimates never metered values, that land book numbers are unverified register filings, and that a registered office does not prove ownership or occupancy.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and cost are front-loaded, but the middle is a single enormous semicolon-chained paragraph acting as a return-value dictionary. With no output schema the content is largely justified, yet the lack of structure (no list, no grouping, run-on clauses within `parts`, `recordSheet`, `roofAnalysis`) makes it hard to scan for the one field an agent needs.

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?

No output schema exists, so the description carries the return shape, and it does so thoroughly: field groups, size bases, heating-model caveats, business-list caveats, and the cost rule. An agent knows what it will receive and what the call costs before invoking it.

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 coverage is 100%, so buildingId and includeRegisteredBusinesses are already documented. The description confirms the id should come from 'an earlier result' and mentions the registered-businesses content, but never says the boolean toggles that content or what the default is — baseline 3 for a schema that does the heavy lifting.

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?

Opens with a specific verb and resource ('Returns every fact baseray holds on one building') scoped to a single buildingId, and explicitly excludes the adjacent operation ('it does not find a building by address'), which cleanly separates it from find_buildings/search_buildings.

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?

'Use for questions about one building already found; it does not find a building by address' gives a clear when-to-use and a when-not, plus the prerequisite that the id must come from an earlier result. It stops short of naming the sibling tools to use instead (find_buildings, search_buildings), so routing is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources