Tomorrow Central: Cloud Cost Sentinel

Compare architectures and find the crossover

compare_architectures

Read-only

Price every shape that delivers a capability, and say where they cross over.

This is the tool for "should we move to serverless", "is Lambda cheaper than
EC2", "what would containers cost instead". Answer with the crossover, not a
verdict: one shape is cheaper below some level of traffic and dearer above it,
and the number where that flips is the thing the user can act on.

`capability` is an id from `list_cost_building_blocks` (for example
`serve-http`). `drivers` are the workload's measurements, and EVERY driver the
capability declares must be given, for every shape. That is enforced rather
than defaulted: giving one architecture a favourable assumption the other does
not get is the single easiest way to produce a comparison that looks rigorous
and is not.

`over` names the driver to sweep, usually the one the user is unsure about
(`requests_per_month` is the common one). Pass it to get `break_even`: a priced
curve for each shape and the crossing points between them. `low` and `high`
bound the sweep; omit them for the driver's typical range.

Read `crossings` carefully. Each one carries the band around it where the two
shapes are indistinguishable given the uncertainty in the inputs. Inside that
band the honest answer is "it does not matter, pick on other grounds", and
saying "X is cheaper" there is a claim the numbers do not support.

An EMPTY `crossings` list is not "there is no break-even". Read `no_crossing`,
which says which window was swept and what happened inside it. Usually it means
one shape won at every point in that range, and that the answer is being decided
by one of the drivers you held fixed rather than by the one you swept. Sweeping a
different driver is what finds the flip. Do not report "they never cross" from a
single sweep.

Cost is one input and rarely the deciding one. Request time limits, long-lived
connections, operational effort and what the team already knows all decide this
more often than price does. The reply carries each shape's characteristics for
exactly that reason; pass them on rather than reducing the answer to a total.

Input Schema

TableJSON Schema

Name	Required	Default
`low`	No
`high`	No
`over`	No
`term`	No	OnDemand
`region`	Yes
`drivers`	Yes
`capability`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses critical behavior beyond the readOnlyHint annotation: it emphasizes that empty crossings does not mean no crossover, explains that 'it does not matter' zones exist, and warns that a single sweep may miss crossovers driven by other variables. It also clarifies that the tool returns characteristics and not a verdict, which prevents an agent from overclaiming.

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

Conciseness5/5

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

The description is front-loaded with the core purpose in the first two sentences/no wasted words. Each subsequent paragraph earns its place: parameter guidance, output interpretation, and caveats about cost as a deciding factor. The warning about empty crossings is essential and tightly written.

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?

The description fully addresses the main output semantics (crossings, no_crossing, characteristics) and mentions the input requirements for capability and drivers. It does not explain how term and region factor into the comparison, and it does not mention any rate limits, timeouts, or error cases. For a tool of this complexity, those omissions are noticeable but not fatal.

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?

With schema description coverage near 0%, the description must carry parameter meaning. It does explain capability, drivers, over, low, and high, and explicitly warns that drivers must be complete per capability. However, region and term are never described, and the relationship between low/high and units/scale is left implicit. So while most parameters are covered, a required parameter (region) and the pricing term parameter receive no semantic guidance.

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 states a clear verb-resource pair (

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 explicitly tells the agent when to use this tool ('This is the tool for

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

All Tomorrow Central: Cloud Cost Sentinel tools Inspect

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

Need Help?