Skip to main content
Glama
OptimNow

cloud-finops-mcp

by OptimNow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Find a waste runbook

find_playbooks
Read-onlyIdempotent

Retrieve cloud waste runbooks by provider, service, waste category, or confidence. Each includes a tested detection query to answer cost-fix questions.

Instructions

Finds the runbook for a specific cloud waste pattern, filtered by provider, service, waste category or detection confidence. Useful before answering a specific waste or cost-fix question: each runbook includes a tested detection query the user can run in their own account, so it also serves questions about the user's own resources.

Use this for questions like "which VMs are running for nothing",
"why is our NAT bill so high", "my NAT gateway processes 10TB to S3",
"should I delete these old snapshots", "which of our RIs are about to
expire", "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

NameRequiredDescriptionDefault
scopeNo
serviceNo
confidenceNo
waste_categoryNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavior: filters combine with AND, string matching is case-insensitive and exact, and a no-match query returns hint/valid_values so a typo is distinguishable from a coverage gap. It does not discuss rate limits or result size, which is the only shortfall.

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?

Front-loaded with purpose, then usage, then argument semantics, then return shape — a sensible order. The battery of example questions is long, but each maps to a filter dimension and earns its place as disambiguation; only marginal trimming is possible.

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 four-filter lookup tool with annotations covering safety, the description covers purpose, routing, filter semantics, enum values, matching rules, and even the no-match return behavior. Although an output schema exists, the description supplements it usefully with the hint/valid_values edge case rather than redundantly restating fields.

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 description coverage is 0%, so the description carries the full burden — and it does: it enumerates all four scope values, all eight waste_category values, the three confidence tiers with their signal requirements, and specifies exact-match semantics for service with an example. This is materially more than the bare 'string' schema types.

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?

States a specific verb ('finds') and resource ('runbook for a cloud waste pattern') plus the filter dimensions that define the lookup. The filter-based semantics clearly separate it from list_playbooks (unfiltered enumeration) and get_playbook (single fetch by identifier), so an agent can route without opening the schema.

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?

Explicitly frames when to use it ('before answering a specific waste or cost-fix question') and supplies a long list of concrete triggering questions, including the insight that it also answers questions about the user's own resources. The condition for each filter is spelled out, leaving little to inference.

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

Deploy Server

Other Tools