Tomorrow Central: Cloud Cost Sentinel

Tell Tomorrow Central what was missing or broken

report_feedback

Idempotent

Report, in plain English, something Tomorrow Central could not do, did badly, or documented unclearly. Use this when you hit a wall: a capability that does not exist, a call that succeeded but returned something you could not use, a tool description that did not match what happened, or a bug.

`kind` is one of: bug, missing_capability, unclear_docs, wrong_result, suggestion,
other. `blocking` means this stopped you completing what the user asked for.
`tool_name` and `job_id` anchor the report to a specific call if there was one, and
`rating_token` links it to a result you were given.

Say what you were trying to do and what happened instead. Do not paste credentials,
and remember that anything you write here is stored.

One call per issue. The reply may tell you the gap is already known or already
fixed, in which case retrying is worth it. Nobody replies to this in conversation:
it is a one-way channel, so do not promise the user a response.

Input Schema

TableJSON Schema

Name	Required	Default
`kind`	No	other
`job_id`	No
`message`	Yes
`blocking`	No
`tool_name`	No
`rating_token`	No

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses crucial behavioral traits: it is a one-way channel with no replies, data is stored, credentials must not be pasted, and retrying may be worthwhile if the gap is already known/fixed. This adds significant context that annotations do not cover.

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 description is longer than average but well-structured and front-loaded with the core purpose. Every sentence adds value: scenarios, parameter explanations, security warning, and channel behavior. It is verbose but not wasteful, and the organization makes it easy to scan.

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?

Given the tool's complexity (6 parameters, no output schema), the description is complete: it covers purpose, when/how to use, parameter meanings, security, persistence, and the one-way nature. It leaves no critical gaps for an agent to invoke the tool correctly.

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 0%, so the description carries full responsibility. It explains 'kind' with all possible values, defines 'blocking', and clarifies the roles of 'tool_name', 'job_id', and 'rating_token' as anchors/links. It also instructs on the content of 'message' ('Say what you were trying to do and what happened instead'), fully compensating for the schema's lack of descriptions.

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 clearly states the tool's purpose: to report something Tomorrow Central could not do, did badly, or documented unclearly. It uses a specific verb ('Report') and resource ('Tomorrow Central'), and distinguishes itself from siblings like submit_rating by targeting gaps/bugs rather than ratings.

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 explicit when-to-use scenarios ('when you hit a wall: a capability that does not exist, a call that succeeded but returned something you could not use...') and practical constraints ('One call per issue', 'one-way channel'). It does not explicitly name alternative tools, but the use cases are clear enough to avoid confusion with siblings.

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?