Skip to main content
Glama

Cloud FinOps Skill & MCP

Find the right FinOps guide

find_references
Read-onlyIdempotent

Find which guidance serves a FinOps question - how to commit, size, allocate, charge back, forecast, or govern cloud and AI spend.

Use this for questions like "how should we size Savings Plans",
"what should Finance own in chargeback", "what does a Crawl-stage org
tackle first" - anything that maps to FinOps Framework facets (domain,
capability, phase, persona, maturity) - and you want only the
references that serve it, instead of scanning the full list.

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

- ``find_references(domain="Optimize Usage & Cost")``
- ``find_references(phase="Optimize", persona="Engineering")``
- ``find_references(persona="Engineering", persona_primary_only=True)``
- ``find_references(capability="Rate Optimization")``
- ``find_references(maturity="Crawl")``

Args:
    domain: FinOps Framework domain (e.g. ``"Optimize Usage & Cost"``,
        ``"Quantify Business Value"``, ``"Manage the FinOps Practice"``).
    capability: FinOps capability (matches ``fcp_capability`` and
        ``fcp_capabilities_secondary``).
    phase: FinOps phase (``"Inform"``, ``"Optimize"``, ``"Operate"``).
    persona: Persona (matches ``fcp_personas_primary`` and
        ``fcp_personas_collaborating``).
    maturity: Entry maturity level (``"Crawl"``, ``"Walk"``, ``"Run"``).
    persona_primary_only: when True, ``persona`` matches only the primary
        list. Use it when the default match barely narrows the set -
        broad personas like Engineering collaborate on nearly every file,
        so filtering on collaboration is descriptive, not discriminating.
        ``persona="Engineering", persona_primary_only=True`` is the
        engineering reading list; the default is the everything-they-touch
        view.

Returns ``{"filters": {...}, "references": [...], "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
phaseNo
domainNo
personaNo
maturityNo
capabilityNo
persona_primary_onlyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / persona_primary_only
      Added value: +{
      +  "default": false,
      +  "title": "Persona Primary Only",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses AND semantics across filters, case-insensitive exact string matching, persona_primary_only behavior, and the return shape including a no-match hint/valid_values. This is substantial behavioral context not available in structured data.

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 purpose and usage, then moves to filter semantics, examples, args, and return shape. Despite its length, every section carries needed information for a 6-parameter search tool and the examples are illustrative rather than padding.

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 schema has no property descriptions and no enums, the description covers all call-relevant details: optionality, AND combination, string-matching behavior, field matching semantics, return object, and the no-match hint. The presence of an output schema further reduces the burden, so nothing needed for correct invocation is missing.

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?

With 0% schema description coverage, the description fully compensates: it documents each of the six parameters, gives examples for four of them, explains matching semantics, and even clarifies the nuanced persona_primary_only behavior. This is far beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific verb and resource: 'Find which guidance serves a FinOps question' and returns references filtered by FinOps facets. It differentiates from list_references with 'instead of scanning the full list', but it does not explicitly contrast with the sibling find_playbooks, so it stops short of full sibling differentiation.

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?

It gives explicit usage context with examples ('how should we size Savings Plans', 'what should Finance own in chargeback') and an explicit alternative ('instead of scanning the full list'). It lacks an explicit when-not or routing to other siblings like get_reference or find_playbooks, so it earns a 4 rather than a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.