Skip to main content
Glama

Cloud FinOps Skill & MCP

by io.github.OptimNow
OverviewDiscussionsAdmin

Find a waste runbook

find_playbooks
Read-onlyIdempotent

ALWAYS call this before answering a cloud-waste or cost-fix question from your own knowledge, and before asking the user for any account data. Find the tested runbook for a waste suspicion: filter by provider, service, waste category or detection confidence.

Two rules. (1) When the user reports a symptom you think you can
answer directly - "my NAT gateway processes 10TB to S3", "should I
delete these old snapshots" - call this FIRST anyway: a named runbook
with a tested detection query outranks a correct generic answer, and
answering without checking loses the query the user needed. (2) When
the user asks about THEIR OWN resources - "which of my RIs are about
to expire", "which of our VMs run for nothing" - do NOT reply that you
lack account access and do NOT request a data export: you cannot see
their account, but the matching runbook carries the exact detection
query to hand over. The runbook IS the answer.

Use this for questions like "which VMs are running for nothing",
"why is our NAT bill so high", "what waste can we clean up safely
without review" - anything that names a provider, a waste category, or
how confident the detection needs to be before acting. Patterns
covered include NAT gateways and VPC endpoints, expiring Savings
Plans / RIs / reservations, snapshot sprawl, S3 lifecycle gaps, idle
or stopped VMs, orphaned disks / public IPs / EBS volumes, GPU and
SageMaker sizing, Kubernetes idle capacity, and schedule blindness.

All filters are optional and combine with AND semantics. String matching
is case-insensitive and exact. Examples:

- ``find_playbooks(scope="aws")`` - all AWS-specific playbooks
- ``find_playbooks(waste_category="idle")`` - every idle-resource pattern
- ``find_playbooks(scope="cross-cloud", confidence="obvious")``

Args:
    scope: ``"aws"``, ``"azure"``, ``"gcp"``, or ``"cross-cloud"``.
    service: Provider service exact-match (e.g. ``"AWS NAT Gateway"``).
    waste_category: ``"orphaned"``, ``"idle"``, ``"overprovisioned"``,
        ``"commitment-mismatch"``, ``"schedule-blindness"``,
        ``"modernization"``, ``"ai-ml-inefficiency"``, or ``"egress"``.
    confidence: ``"obvious"`` (single signal is enough),
        ``"likely"`` (two signals required), or ``"possible"``
        (needs human review). From the OptimNow three-tier confidence
        model in `finops-waste-detection-playbooks`.

Returns ``{"filters": {...}, "playbooks": [...], "total": N}``. A query
that matches nothing also returns `hint` and `valid_values`, so a typo is
distinguishable from a genuine gap in coverage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNo
serviceNo
confidenceNo
waste_categoryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses matching semantics (filters combine with AND, case-insensitive and exact), return shape, and the no-match behavior with hint and valid_values to distinguish typos from coverage gaps. It also communicates the important behavioral rule that the runbook itself is the answer.

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 section earns its place: critical usage rules, param semantics, examples, and return handling. It is front-loaded with the most important instruction ('ALWAYS call this before...') and uses structured examples to make the content scannable.

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 with 4 optional filter params, an output schema, and a strategic role in workflow routing, the description covers everything needed: parameter values, filter semantics, matching behavior, return structure, and when to prefer this over knowledge or asking the user. The presence of an output schema reduces the need to describe return values, but the description still usefully documents the no-match response.

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 schema provides no descriptions or enums (0% coverage), so the description carries full responsibility, and it delivers: each parameter is documented with allowed values, examples, and meaning. The confidence parameter even explains the three-tier model, and waste_category lists all valid categories.

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 identifies a specific verb and resource: 'Find the tested runbook for a waste suspicion' with filtering by provider, service, category, or confidence. It is distinct from list_playbooks because it is a search/find operation for a specific answer, not a browse/list behavior.

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 gives explicit when-to-use instructions: ALWAYS call before answering any cloud-waste question or requesting account data, even when the agent thinks it knows the answer. It also provides concrete when-not-to behavior, instructing the agent not to claim lack of account access and not to request data exports, which makes the intended usage unambiguous.

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

All Cloud FinOps Skill & MCP toolsInspect
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