boaviztapi-mcp

Estimate an end-user device

estimate_device

Read-onlyIdempotent

Estimate the environmental footprint of end-user devices like laptops, smartphones, tablets and monitors. Returns manufacturing and electricity impacts per criteria, with units, ranges and warnings.

Instructions

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.

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": {
      "device_type": "<device_type>"
    },
    "name": "estimate_device"
  }
}

Input Schema

Name	Required	Description	Default
`detail`	No	'breakdown' adds per-component impacts and all assumptions.	summary
`criteria`	No	Impact criteria codes; default gwp, adp, pe. See list_impact_criteria. 'all' is not accepted.
`archetype`	No	Device archetype, e.g. 'laptop-pro'; required for iot_device. See search_catalog(kind='device_archetype').
`avg_power_w`	No	Average power in watts.
`device_type`	Yes	Kind of device.
`duration_hours`	No	Period assessed in hours (8760 = 1 year, 730 = 1 month). Omit for the whole hardware lifetime.
`lifetime_hours`	No	Hardware lifetime in hours.
`usage_location`	No	Where the electricity comes from: country name or 3-letter code ('Germany', 'DEU'), 'WOR' for world or 'EEE' for Europe.
`use_time_ratio`	No	Share of time the device is in use, 0 to 1.

Output Schema

Name	Required	Description
`api`	Yes
`notes`	No
`impacts`	Yes
`subject`	Yes
`summary`	Yes	Plain-text digest; quote it or use the fields.
`duration`	Yes
`location`	Yes
`breakdown`	No
`assumptions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive, openWorld), it discloses cost/behaviour details an agent needs: a single BoaviztAPI request, one-hour caching, and that missing criteria are returned as unavailable rather than zero. It also characterizes the response shape (manufacturing and electricity impacts per criterion, with units, ranges and warnings).

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?

It is front-loaded with purpose and scoping before parameter caveats, and every sentence carries operational information. The inline list of thirteen device types partially duplicates the enum already in the schema, which is the main piece of slack in an otherwise tight definition.

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 nine-parameter, open-world estimation tool with an output schema, this covers what an agent needs: scope, alternatives, archetype resolution, missing-data behaviour, and a note on latency/caching. Nothing required for a correct call is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: use_time_ratio is clarified as the share of time the device is on, and the archetype-default versus iot_device-required distinction is spelled out with a pointer to search_catalog. The remaining parameters (avg_power_w, duration_hours, lifetime_hours, usage_location) are left entirely to the schema.

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 opens with a precise verb+resource ('Estimate the environmental footprint of an end-user device') and enumerates the supported device types, leaving no ambiguity about scope. It explicitly contrasts itself with siblings estimate_server and estimate_cloud_instance, so an agent can route between them without opening any schema.

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

Usage Guidelines5/5

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

It states the positive case ('devices people use') and the exclusion ('not servers or cloud') with named alternatives. It also explains the archetype default behaviour, the iot_device exception, and routes the agent to search_catalog for archetypes and list_impact_criteria for criteria.

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

Deploy Server