DC Blueprint data-centre intelligence

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.

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.

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.

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.

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.

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.

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

Annotations already establish that this is a safe, read-only, idempotent, non-open-world operation. The description adds substantial behavioral context by disclosing the returned market signals: dated project counts at 500 kW+, permitted/building status, MW by stage and capacity basis, top developers, grid connection policy condition, current-hour carbon intensity and power price, and applicable data-centre rule counts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then adds use examples and supported market lists. It is dense and the first sentence is long, but every part contributes useful selection or input guidance, with little wasted wording.

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

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

For a one-parameter aggregate market tool with no output schema, the description is complete enough: it explains the market parameter, lists valid geographies, and enumerates the main return-value categories. An agent can decide whether to call it and what kind of answer to expect.

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

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

The schema already documents the single market parameter at 100% coverage. The description meaningfully extends this by enumerating supported metros (London, Frankfurt, Paris, Amsterdam, Dublin, Milan, Madrid, Oslo) and a long list of supported countries, reducing ambiguity about valid values.

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

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

The description clearly states a specific resource and scope: a dated European data-centre market overview covering project counts, MW by stage, developers, grid connection conditions, carbon intensity, power price, and rules. It is distinguishable as an aggregate overview, though it does not explicitly name sibling tools such as grid_connection_status or grid_carbon_and_price_now as alternatives.

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

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

It gives concrete use cases such as "data centres in Germany", "Frankfurt data centre market", and "who is building data centres in Spain", which clearly indicates when the tool applies. It does not explicitly state when not to use it or name the more specific sibling tools for individual metrics.

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

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

Annotations already declare this as a safe, idempotent, non-destructive read, so the safety profile needs no restatement. The description adds return-value behavior that annotations cannot convey — each rule carries a status, an applicability scope, and a next relevant date, plus upcoming deadlines — which meaningfully sets expectations for the response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The functional sentence is front-loaded and dense with useful detail; the trailing country list is long but is the one piece of information an agent cannot get from the schema. Slight penalty because that list dominates the text and would arguably serve better as schema enums.

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

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

With a single fully-described parameter and no output schema, the description supplies the missing half: what a result record contains (status, applicability, next date) and that upcoming deadlines are included. Nothing an agent needs in order to call this tool correctly appears to be missing.

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

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

Schema coverage is 100% and only one parameter exists, so baseline would be 3; however the description enumerates all 29 accepted country values, which the schema does not (its only hint is 'A European country, e.g. Germany'). That enumeration closes a real risk of invalid input, though it gives no formatting guidance such as casing or name variants.

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

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

Names the specific resource (national and EU rules for building and running a data centre) plus the scope ('in one European country') and the sub-topics covered (energy efficiency reporting, waste heat, permitting, grid). It is distinguishable from siblings like data_centre_market_overview or grid_connection_status without opening either schema.

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

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

Usage is only implied by the content: an agent can infer this tool answers 'what rules/deadlines apply in country X' rather than 'what is the market/grid doing'. There is no explicit when-to-use statement, no exclusions, and no routing to the sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world, so the safety profile is covered. The description adds real behavioral context the annotations lack: the fields returned, the cleanest-window and ranking behavior, and the time-sensitivity ('this hour's') that explains why an identical read is not idempotent. It does not discuss pagination or freshness lag, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the payload (carbon, renewable share, price, window, rank) in the first sentence and defers the market enumeration to the end. The long market list is dense but earns its place since there is no enum in the schema. Slightly verbose overall, so not a 5.

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

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

No output schema exists, so the description correctly carries the return-value burden by naming every returned field and the ranking/cleanest-window semantics. Combined with the covered annotations and the explicit enum-free market list, an agent has everything needed to invoke and interpret the tool.

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

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

With one optional parameter and 100% schema coverage, the baseline is 3. The description exceeds that by enumerating the 15 valid markets (Germany, United Kingdom, France, etc.), which the schema does not capture as an enum, directly resolving the main ambiguity about what values 'market' accepts.

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

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

States a concrete verb+resource: it returns this hour's grid carbon intensity (with unit gCO2/kWh), renewable share, day-ahead price, the cleanest window ahead, and market rank. The resource is clearly distinct from the siblings (data centre overview/rules, grid connection status, science search). An agent knows exactly what data this yields without opening the schema.

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

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

Gives explicit conditional behavior: with a market it returns that market's data; 'Without a market: all markets ranked cleanest first.' This tells the agent how to call it in both modes. It stops short of naming alternatives or exclusions, so it is clear context rather than full when/when-not routing.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds value beyond them by describing what each result contains (measure name, scope of application, start date) and the geographic coverage, which matters because there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The scope statement is front-loaded and the trailing examples are compact and genuinely useful for routing. Slightly longer than necessary given the schema already documents the country default, but there is little waste.

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

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

For a one-parameter, read-only lookup with no output schema, the description covers coverage area, returned fields, default behavior and example intents. An agent has everything needed to invoke it correctly and interpret the result.

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

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

Schema coverage is 100% and the single optional parameter is fully documented there, including the same leave-out default the description restates. The description adds no new format or syntax detail, so baseline 3 applies.

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

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

Names a specific resource (new grid connections for data centres in Europe) and enumerates the exact statuses returned (paused, rationed, conditional, congested) plus the fields attached to each measure. An agent can distinguish this from grid_carbon_and_price_now purely from the description.

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

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

Two concrete sample questions anchor the intended use case and the description states the no-country default ('the whole ranking'). It does not name a sibling as the alternative or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the description only needs to add behavior. It does: results are capped at 5 pages, and the return fields (title, date, link, summary) are disclosed so the agent knows what it will get back. No rate-limit or ranking notes, but the essentials are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first front-loads what is searched and over what corpus, the second states the result cap and payload. Zero filler.

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

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

Given a single required string parameter, no output schema and full schema coverage, the description supplies the missing pieces (result cap and returned fields). Only the absence of guidance relative to the specialized sibling tools keeps it below 5.

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

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

Only one parameter and the schema documents it fully with concrete examples ('PUE benchmarks', 'fibre latency London Frankfurt'), so the baseline is 3. The description adds nothing about query syntax, phrase matching, or how the query is interpreted, so it does not exceed that baseline.

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

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

States a specific verb (Search) and a bounded corpus (DC Blueprint's pages: the four steps plus the European market pages), which is far more informative than the bare title. It does not explicitly contrast with the five sibling tools, but the scope statement makes the intent unambiguous.

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

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

There is no statement of when to use this versus alternatives; with siblings like business_case_figures, data_centre_market_overview and data_centre_rules present, a sentence such as 'use this for free-text discovery, use the others for structured figures' would be valuable and is absent. Usage is only inferable from the word 'Search'.

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