Tomorrow Central: Cloud Cost Sentinel

Run a cloud cost scan (read-only against your cloud)

run_cost_scan

Start a cloud cost / FinOps scan of a linked account and return a job_id. Use this when the user wants to find idle, unused or underutilized cloud resources, review cloud spend, or estimate savings.

The provider comes from the connection, and **AWS is the only provider supported
today** (see `list_connections`). Other clouds will appear on this same tool as
connections for them become linkable; nothing else about the call changes.

READ-ONLY against your cloud: it reads resource metadata and monitoring metrics and
reports; it never changes, stops or deletes anything. (It does create a scan job
here and consume that account's scan quota, which is why this tool is not marked
read-only.)

On AWS it covers EC2 instances, EBS volumes and snapshots, RDS instances, Elastic
IPs, NAT Gateways, load balancers, VPCs and VPC endpoints, site-to-site VPN and
Transit Gateway attachments, Client VPN endpoints, Secrets Manager secrets,
CloudFront distributions and WAF web ACLs. Resource kinds outside that list are not
inspected, so a clean scan is not a claim that the whole bill is optimized.

`connection_id` picks which linked AWS account to scan (see `list_connections`).
Omit it to run against sample data — useful for showing the user what the output
looks like before any account is linked.

The scan runs asynchronously: poll `get_job(job_id)` roughly every 10 seconds
until status is COMPLETED (typically 1-3 minutes), then call
`list_cost_findings(job_id)`. Do NOT start another scan while one is running —
each scan consumes the account's monthly quota.

Pass `idempotency_key` (any unique string you choose) if you may retry on a
network error: a retry with the same key returns the original job instead of
starting a second scan.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`connection_id`	No
`idempotency_key`	No

TDQS

A5/5.0

Behavior5/5

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

Even though annotations set readOnlyHint=false, the description explains why: it creates a scan job and consumes quota, but is read-only against the cloud. It discloses asynchronous behavior, polling cadence, coverage scope (what is and isn't inspected), and idempotency key semantics. This adds substantial context beyond the annotations.

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 long but every sentence earns its place. It is front-loaded with purpose, then covers use cases, provider support, read-only clarification, coverage, parameters, async flow, quota warning, and idempotency. Well-paragraphed and bolded key terms, no redundancy.

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 tool initiating an async job with no output schema, the description fully explains the workflow: start scan, poll get_job, retrieve findings via list_cost_findings. It also covers quota limits, sample data mode, provider limitations, and resource coverage. Given the tool's complexity, this is exceptionally complete.

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?

The input schema provides no descriptions and 0% coverage, so the description carries full burden. It explicitly explains both parameters: connection_id selects the linked AWS account (or sample data if omitted), and idempotency_key enables retry-safe behavior. This is far beyond schema-only information.

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 opens with a specific verb and resource: 'Start a cloud cost / FinOps scan of a linked account and return a job_id.' It clearly distinguishes the tool from siblings like get_job and list_cost_findings by focusing on initiating a scan, and it lists concrete use cases (idle resources, spend review, savings estimates).

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?

The description states when to use the tool ('Use this when the user wants to find idle, unused or underutilized cloud resources...'), provides exclusions (only AWS supported), warns against starting concurrent scans due to quota, and references sibling tools for next steps (poll get_job, then list_cost_findings). This is exemplary guidance.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: connection lifecycle (create, verify, get, list), job lifecycle (run, get status, get result), and findings (list). Even get_job_result and list_cost_findings are clearly differentiated as raw vs. analyzed data, and whoami/list_tools_available serve metadata purposes.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (create_, get_, list_, run_, verify_). The only outlier is 'whoami', which breaks the pattern but is a recognizable convention for account identification. Overall naming is predictable and readable.

Tool Count5/5

With 10 tools, the set is well-scoped for a cloud cost scanning platform. Each tool serves a clear purpose in the connection-scan-result workflow, with no redundancy or bloat.

Completeness3/5

The core scan workflow is covered (connect, verify, scan, get job, get findings), but there are notable gaps: no tool to delete/disconnect a cloud account, and no way to list past jobs or retrieve results without a prior job_id. These missing lifecycle/history operations could force agents to rely on external state or fail when context is lost.

Resources

Need Help?