Skip to main content
Glama

Tomorrow Central: Cloud Cost Sentinel

Where an architecture is allowed to run, and what that costs

where_can_this_run
Read-only

Apply requirements FIRST, then price only the regions that survive.

Use this for "the data has to stay in India", "we cannot use US-owned
jurisdictions", "our users are in Europe", "it has to survive a zone failure".

The order is the whole point. A cheaper region that cannot legally hold the
data is not a cheaper option, it is not an option, and a tool that priced
first and filtered second would already have told the user a number they
cannot have.

`items` is the same shape `estimate_cost` takes. `constraints` is
`[{"constraint": "<id>", "value": "<value>"}]`, with the ids and the value each
one expects coming from `list_cost_building_blocks`.

The reply separates three things that must never be confused:

* `options` are regions that satisfy every requirement AND can price the whole
  architecture, cheapest first.
* `cannot_run_this` are regions that satisfy the requirements but do not sell
  part of what was asked for. They are kept out of the ranking on purpose: a
  region that prices three lines of five prices LOW, so it would sort to the
  top and win by being incomplete.
* `excluded` are regions that failed a requirement, each with the reason.

`cost_of_requirements` says what the requirements cost against running anywhere,
and splits that into the part caused by the location and the part caused by the
architecture changes the requirements forced (a standby copy for zone failure,
for instance). Those are different decisions and a single premium figure hides
which one is expensive.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termNoOnDemand
itemsYes
regionsNo
constraintsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

The description explains the critical sequencing constraint, why that sequencing matters, exactly what each of the three output groups means, and that cost_of_requirements is separated from location pricing. That is substantial behavioral detail.

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?

Well organized with a lead sentence that states the algorithm, then concrete examples)Skip? Wait no. It is a bit long but the bullets and bolded distinctions justify the length. No filler.

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?

Covers the central decision rule, the input shapes for the two critical parameters, and the semantics of the three output categories. It omits `term` and `regions`, and does not describe the response envelope or error cases, but an agent can safely run the tool from this description.

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

Parameters3/5

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

The description explains `items` and `constraints` well, including the constraint shape and where IDs come from. But it never describes `term` or `regions`, and with 0% schema description coverage those two parameters are left to the agent to guess.

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 states the exact purpose and order of operations: apply requirements first, then price only the regions that survive. The title and description make it unmistakable that this tool is about constraint-filtered costing, not generic pricing.

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

Usage Guidelines4/5

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

The description gives concrete triggers: 'the data has to stay in India', 'we cannot use US-owned jurisdictions', 'users are in Europe', 'it has to survive a zone failure.' It also contrasts with a price-first approach, which tells the agent when not to use a naive cost tool. It never explicitly names the condition where estimate_cost should be used instead of this tool, so it falls just 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources