boaviztapi-mcp

Estimate a component

estimate_component

Read-onlyIdempotent

Estimate environmental footprint for one component type (GPU, CPU, RAM, SSD, or HDD) by units, returning manufacturing and electricity impacts per criterion with units, ranges, and warnings.

Instructions

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.

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": {
      "component": "<component>"
    },
    "name": "estimate_component"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	Model name for gpu or cpu, e.g. 'H100 SXM'.
`tdp_w`	No	TDP in watts (gpu, cpu).
`units`	No	How many.
`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.
`component`	Yes	Component type.
`avg_power_w`	No	Average power in watts.
`capacity_gb`	No	Capacity in GB (ram, ssd, hdd).
`load_percent`	No	Average CPU load in percent.
`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.

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.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, and the description adds real behavior: a single BoaviztAPI request, one-hour caching, model-name resolution against BoaviztAPI, and that an ambiguous name like 'h100' returns candidates rather than failing. What it does not cover is whether cached results are shared across differing criteria/detail, but the operational profile is well beyond the annotations.

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?

Three short, front-loaded paragraphs: what it returns, when to use it versus estimate_server, then parameter applicability and runtime traits. The third paragraph partly restates applicability that the schema's own parameter descriptions already carry, which is the only waste.

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?

With an output schema present, the description does not need to detail return shapes, yet it still signals units, ranges and warnings. For a 12-parameter tool it covers the decision-relevant edges: sibling routing, per-component parameter applicability, error conditions, and caching.

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 cross-field constraints the schema only implies per-parameter: name and tdp_w belong to gpu/cpu, capacity_gb to ram/ssd/hdd, and mismatched combinations are an error. The name-resolution and ambiguity behavior for `name` also adds meaning beyond 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 pairs a specific verb with a specific resource and enumerates the component kinds (gpu, cpu, ram, ssd, hdd) plus the output content: manufacturing and electricity impacts per criterion with units, ranges and warnings. It explicitly distinguishes itself from estimate_server for whole machines, so an agent can route correctly without opening a 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 exact use case ('parts on their own, such as eight H100 GPUs'), names the alternative for the adjacent case ('for a whole machine use estimate_server with a `gpu` block'), and flags invalid parameter combinations as errors. When-to-use, when-not, and the substitute tool are all present.

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

Deploy Server