Skip to main content
Glama
boaviztapi-mcp

boaviztapi-mcp

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BOAVIZTAPI_URLNoBoaviztAPI base URL.https://api.boavizta.org
BOAVIZTAPI_TIMEOUTNoSeconds per request.20
BOAVIZTAPI_CACHE_TTLNoSeconds to cache list and lookup responses; `0` disables caching.86400
BOAVIZTAPI_DEFAULT_CRITERIANoCriteria 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:

  1. Keep every number with its unit exactly as returned (kgCO2eq, MJ, kgSbeq, m3 eq.).

  2. Report embedded (manufacturing) and use (electricity) impacts separately; only give a total when the result has one.

  3. Always state the period. Without duration_hours the figures cover the whole lifetime. With it, embedded is the share of manufacturing for that period.

  4. Give ranges as min to max when they differ; do not round further or recompute.

  5. Repeat warnings and notes next to the figures they belong to.

  6. "not available from BoaviztAPI for this item" means no data, never zero.

  7. Without a location the use phase relies on a default mix with a wide range; suggest a country.

  8. Name the exact item and the main assumptions (lifetime, average power, load).

  9. 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 criteria for the estimate tools; it estimates nothing. query filters on code, unit or description words such as 'water'. Read-only; the list comes from BoaviztAPI and is cached for a day.

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 provider), a cloud region, a server or device archetype (needs device_type), or a country. Results are exact upstream strings, including upstream typos such as 'platfom_gpucompute_high', best matches first and capped by limit; total_matches says how many exist. To see what one item contains, use describe_catalog_item instead. Read-only; lists are cached for a day.

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. name is resolved to the exact upstream name, and an ambiguous name returns the candidates (use search_catalog to find names). provider is required for cloud_instance and device_type for device_archetype. Read-only; cached for a day.

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 region (the provider's region, which fixes the electricity mix) or usage_location (a country), not both; with neither, a wide European default is used. duration_hours sets the period (8760 = one year); omit it for the whole hardware lifetime. Read-only: one BoaviztAPI request, cached for an hour; if one criterion fails upstream the others are still returned. Use search_catalog(kind='cloud_instance', provider=...) if unsure of a name.

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 archetype (default 'platform_compute_medium'), and the result lists which ones. The default lifetime is 4 years (35040 h); a duration_hours longer than the lifetime counts manufacturing once and says so. Set usage_location for a country's electricity mix and detail='breakdown' for per-component impacts. Read-only: one BoaviztAPI request, cached for an hour.

estimate_componentA

Estimate the environmental footprint of one kind of component (gpu, cpu, ram, ssd or hdd), units of it: manufacturing (embedded) and electricity (use) impacts per criterion, with units, ranges and warnings.

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 gpu block. name and tdp_w apply to gpu and cpu, capacity_gb to ram, ssd and hdd; other combinations are an error. Names are resolved to BoaviztAPI's model names and an ambiguous one (such as 'h100') returns the candidates. Read-only: one BoaviztAPI request, cached for an hour.

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 archetype the device type's default profile is used, except for iot_device, which needs one; list them with search_catalog(kind='device_archetype', device_type=...). use_time_ratio is the share of time the device is on (0 to 1). Criteria without data are reported as not available, never as 0. Read-only: one BoaviztAPI request, cached for an hour.

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 label, a kind, and params holding the matching estimate tool's inputs (without duration_hours, criteria or detail). duration_hours is required so items with different lifetimes compare on equal terms. Every item is checked before any estimate runs, and an invalid item fails the call with its label named. Read-only: one BoaviztAPI request per item.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.5/5.0

Scored across 8 tools

Disambiguation5/5

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.

Naming Consistency5/5

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).

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues