boaviztapi-mcp

Estimate a server

estimate_server

Read-onlyIdempotent

Estimate the environmental footprint of on-premise servers, with optional GPUs, by calculating manufacturing and electricity-use impacts per criterion, including units, ranges, and warnings.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "estimate_server"
  }
}

Input Schema

Name	Required	Description	Default
`cpu`	No	CPUs, e.g. {name: 'Xeon Gold 6134', units: 2}.
`gpu`	No	GPUs, e.g. {name: 'A100 SXM4 80GB', units: 8}.
`ram`	No	RAM modules, e.g. [{units: 12, capacity_gb: 32}].
`disks`	No	Disks, e.g. [{type: 'ssd', units: 2, capacity_gb: 960}].
`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	Server archetype for anything not given (default 'platform_compute_medium'); see search_catalog.
`avg_power_w`	No	Average power in watts.
`server_type`	No	Form factor; defaults to the archetype's (rack).
`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.
`use_time_ratio`	No	Share of time the device is in use, 0 to 1.
`gpu_load_percent`	No	Average GPU load in percent.

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?

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered; the description still adds real behavioral context beyond them: a single BoaviztAPI call, a one-hour cache, the fact that the response lists which parts were filled from the archetype, and the non-obvious accounting rule that a `duration_hours` exceeding the lifetime counts manufacturing once and reports it. These are exactly the behaviors an agent could not infer from structured fields.

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?

Purpose is front-loaded in the first sentence, then usage routing, then option-level behavior, then a closing read-only/caching note — a sensible order with no filler. The archetype/default sentence is dense with parenthetical detail, though each clause carries distinct information, so trimming would lose content.

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 15-parameter, all-optional tool with an output schema and full annotation coverage, the description supplies what structure cannot: the fill-in-from-archetype model, the default 4-year lifetime, the duration-vs-lifetime accounting, and the criteria/usage_location/detail options. An agent can call this correctly and interpret the result without further reading.

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, and the description earns more by explaining the interaction between `duration_hours` and lifetime, the archetype default and its role as a fallback for CPU/RAM/disks/GPU/PSU/case, and the accepted forms of `usage_location` and `detail`. It stops short of covering the power/load parameters (avg_power_w, load_percent, use_time_ratio), which remain schema-only.

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 first sentence names a specific verb and resource ('estimate the environmental footprint of an on-premise server') and scopes what is measured ('manufacturing (embedded) and electricity (use) impacts per criterion, with units, ranges and warnings'). It also explicitly carves out the sibling territory ('use estimate_cloud_instance for cloud VMs and estimate_component for one part'), so an agent can discriminate 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 gives explicit routing rules against two named alternatives plus a conditional ('optionally with GPUs'), and then states when to use specific options: set `usage_location` for a country electricity mix, `detail='breakdown'` for per-component impacts. The archetype fallback rule ('any part you leave out ... comes from archetype, default platform_compute_medium') tells the agent what happens when it omits inputs, which is guidance, not just description.

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

Deploy Server