Skip to main content
Glama

DC Blueprint data-centre intelligence

by com.dcblueprint
OverviewDiscussionsAdmin

Data-centre business-case figures for one market

business_case_figures
Read-onlyIdempotent

The inputs of a colocation data-centre business case for one European market: construction cost per MW, colocation prices per kW-month, electricity price, staff cost, guarding, property tax, exit yield, grid wait, permitting and grid charges, with low and high. Needs a personal DC Blueprint key (Authorization: Bearer) from an account with a DC Blueprint licence or trial. Ask for one market for the project at hand: every figure costs 5 credits, one figure (the "figure" argument) 1; the same answer again in the calendar month costs nothing. It is not a way to copy the catalogue market by market. Markets: Amsterdam, Athens, Berlin, Copenhagen, Dublin, Frankfurt, Helsinki, Lisbon, London, Madrid, Milan, Oslo, Paris, Stockholm, Vienna, Warsaw, Zurich. Figures: Construction cost, Colocation price, retail, Colocation price, wholesale, Colocation price, large deals, Electricity price, Cost of a site employee, Guarding and monitoring, Property tax, Exit yield, Wait for a grid connection, Permitting, Grid connection charge, Customer substation.

Input Schema

NameRequiredDescriptionDefault
figureNoOptional: one figure only, e.g. "Construction cost" or "Exit yield" (1 credit). Leave it out for every figure of the market.
marketYesA business-case market, e.g. "Frankfurt", "Milan".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: requires a bearer DC Blueprint key tied to a licence or trial, discloses credit pricing (5 per market call, 1 per single figure, free within the same calendar month), and warns against bulk catalogue copying. The annotations already cover read-only/idempotent safety, and the description adds the auth, quota and caching behaviour they cannot express.

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?

The key constraints (auth, credits, one-market rule) are front-loaded and each sentence carries information. However, the figure list is stated twice — once in the opening sentence and again after 'Figures:' — which is avoidable redundancy, and the opening sentence is overloaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does explain what comes back (each figure with low and high) and what drives cost, so an agent can invoke it confidently. It stops short of describing the response shape or units (per MW, per kW-month are mentioned but yield/percentage-style figures are not characterised).

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

Parameters5/5

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

Schema coverage is 100%, so baseline would be 3, but the description adds substantial meaning: it enumerates all 17 valid market values and all 15 figure names, effectively supplying the enums the schema lacks. It also clarifies that omitting 'figure' returns every figure at 5 credits versus 1 for a single figure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact resource: the input variables of a colocation data-centre business case for a single European market, and enumerates them. It is clear this is not the market overview or rules sibling, but it never explicitly contrasts them, and the verb ('returns'/'provides') must be inferred from 'The inputs of...'.

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?

Explicitly scopes usage: 'Ask for one market for the project at hand', and states the negative case 'It is not a way to copy the catalogue market by market.' It also gives the cost trade-off that drives the choice between one figure and all figures, which is exactly the when/when-not guidance an agent needs.

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

All DC Blueprint data-centre intelligence toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources