boaviztapi-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BOAVIZTAPI_URL | No | BoaviztAPI base URL. | https://api.boavizta.org |
| BOAVIZTAPI_TIMEOUT | No | Seconds per request. | 20 |
| BOAVIZTAPI_CACHE_TTL | No | Seconds to cache list and lookup responses; `0` disables caching. | 86400 |
| BOAVIZTAPI_DEFAULT_CRITERIA | No | Criteria used when a call names none. | gwp,adp,pe |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Tools for estimating the environmental footprint of IT hardware with BoaviztAPI (https://doc.api.boavizta.org): cloud instances, servers, single components such as GPUs, and end-user devices. All numbers come from BoaviztAPI.
When reporting results:
Keep every number with its unit exactly as returned (kgCO2eq, MJ, kgSbeq, m3 eq.).
Report embedded (manufacturing) and use (electricity) impacts separately; only give a total when the result has one.
Always state the period. Without duration_hours the figures cover the whole lifetime. With it, embedded is the share of manufacturing for that period.
Give ranges as min to max when they differ; do not round further or recompute.
Repeat warnings and notes next to the figures they belong to.
"not available from BoaviztAPI for this item" means no data, never zero.
Without a location the use phase relies on a default mix with a wide range; suggest a country.
Name the exact item and the main assumptions (lifetime, average power, load).
Cite the BoaviztAPI version and URL from the result. Use search_catalog to find exact names before estimating when unsure.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_impact_criteriaA | List BoaviztAPI's impact criteria with their code, unit and meaning, e.g. gwp (climate change, kgCO2eq), adp (abiotic resources, kgSbeq) or pe (primary energy, MJ). Use it to explain a code that appears in a result, or to choose |
| search_catalogA | Find the exact names BoaviztAPI knows, before estimating. Use it whenever an estimate needs a name you are unsure of: a GPU or CPU
model, a cloud instance type (needs |
| describe_catalog_itemA | Show what a named catalog item contains: a cloud instance's vCPUs, memory and host platform; a server or device archetype's default parts and usage; or a GPU's or CPU's specifications. Use it to explain or check the assumptions behind an estimate, or to choose
between similar items; it does not estimate impacts. |
| estimate_cloud_instanceA | Estimate the environmental footprint of one cloud VM: its share of the host server's manufacturing (embedded) and the electricity it uses (use), per impact criterion, with units, min-max ranges and warnings. Use it for a single instance; use compare_estimates to rank several and
estimate_server for physical servers. Give either |
| estimate_serverA | Estimate the environmental footprint of an on-premise server, optionally with GPUs: manufacturing (embedded) and electricity (use) impacts per criterion, with units, ranges and warnings. Use it for physical servers; use estimate_cloud_instance for cloud VMs and
estimate_component for one part on its own. Any part you leave out (CPU,
RAM, disks, GPU, power supply, case) comes from |
| estimate_componentA | Estimate the environmental footprint of one kind of component (gpu, cpu,
ram, ssd or hdd), Use it for parts on their own, such as eight H100 GPUs. A GPU alone excludes
its host server: for a whole machine use estimate_server with a |
| estimate_deviceA | Estimate the environmental footprint of an end-user device: laptop, desktop, smartphone, tablet, television, box, vr_headset, vr_controller, monitor, usb_stick, external_ssd, external_hdd or iot_device. Returns manufacturing (embedded) and electricity (use) impacts per criterion, with units, ranges and warnings. Use it for devices people use, not servers or cloud (see estimate_server and
estimate_cloud_instance). Without |
| compare_estimatesA | Compare 2 to 5 options (cloud instances, servers, components or devices) over one common period and rank them per criterion, with each total, the difference from the first option, and whether the uncertainty ranges overlap. Use it whenever the question is which option is greener or how options
differ; use the single estimate tools for one item. Each item has a |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a clearly distinct step or domain: reference lookups (list_impact_criteria, search_catalog, describe_catalog_item), single-item estimates split by resource type (cloud_instance, server, component, device), and cross-option comparison. The descriptions explicitly state the boundary between neighbours ('use compare_estimates to rank several', 'search_catalog to find names'), leaving no realistic chance of misselection.
All eight tools follow a strict verb_noun snake_case pattern, with the estimate_* family forming a predictable, parallel series (estimate_cloud_instance, estimate_server, estimate_component, estimate_device). Catalog tools also pair consistently (search_catalog / describe_catalog_item).
Eight tools is well within the sweet spot and each one earns its place: three reference/lookup helpers, four estimation entry points mapping to distinct physical scopes, and one aggregation tool. Nothing appears redundant or padded.
Coverage of the domain is strong: name resolution, item introspection, criterion glossary, per-scope estimates, and multi-option comparison form a coherent end-to-end workflow with no dead ends for typical questions. Minor gaps remain — there is no direct 'list supported kinds/archetypes' or filter/search over prior results, so agents must probe via search_catalog and per-kind arguments.