Cloud FinOps Skill & MCP

Read one FinOps guide

get_reference

Read-onlyIdempotent

Fetch the guidance on one FinOps topic - the billing mechanics, decision rules and worked examples behind a defensible answer - either whole or one section at a time.

Use this when you need the actual content of one known reference,
after ``list_references`` or ``find_references`` told you which one
serves the question. Advisory questions (commitment sizing, chargeback
design, allocation methodology) are served by the reference's decision
rules and worked examples, which a summary does not carry.

``section`` is useful when the question is narrower than the file. The
``approx_tokens`` hint in the listing shows when this matters: the
largest references run to about 15,000 tokens and the Azure pattern
catalogue is an enumerated list, so a question about storage lifecycle is
served by one section of ``finops-azure-patterns``. Without ``section``
the whole file comes back, with its cross-cutting reasoning.

Args:
    name: Reference name as returned by ``list_references`` (e.g.
        ``"finops-aws"``, ``"finops-genai-capacity"``,
        ``"optimnow-methodology"``).
    section: Optional H2 or H3 heading to return on its own. Matched
        case-insensitively and partially against the headings, so a
        natural phrase works - ``"storage"``, ``"commitment decision
        tree"``. A heading's trailing count is ignored, so
        ``"storage optimization patterns"`` matches
        ``"Storage Optimization Patterns (28)"``. If it matches nothing
        you get the list of available headings back, not the whole file.

Without ``section``, returns ``{"name": ..., "content": "...",
"lines": N}`` where ``content`` is the file verbatim. With ``section``,
returns ``{"name", "title", "section", "section_level", "partial": true,
"content", "lines", "full_lines"}`` where ``content`` is that section
prefixed by the reference's title, plus ``other_matching_sections`` when
the phrase matched more than one heading.

On a miss, returns ``{"error": ..., "suggestions": [...]}``. An unknown
name gives up to three string-distance matches; an unmatched ``section``
gives ``available_sections`` - every heading in the file - so the retry
is exact.

Input Schema

Name	Required	Description	Default
`name`	Yes
`section`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 29, 2026

addedInput schema / properties / section

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Section"
+}

First observedAug 19, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description reasonably spends its budget elsewhere: it discloses exact return shapes for both modes, the title-prefixing of section content, the "other_matching_sections" case, and the distinct error shapes on a miss. The failure behavior (suggestions vs. available_sections, never silently returning the whole file) is the kind of context annotations cannot carry.

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 parameters, then return shapes — a logical escalation with no filler sentences. It runs long and the "Args:" block partially restates schema property names, which keeps it just short of maximally tight.

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?

Despite the existence of an output schema, the description explains branch-dependent return shapes and error recovery, which the agent needs to plan a retry strategy. For a two-parameter read tool with sibling routing, nothing material 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?

Schema coverage is 0%, so the description must compensate, and it does: `name` is tied to list_references output with example values, and `section` is fully specified as case-insensitive, partially matched, trailing-count-insensitive, with worked examples ("storage" matching "Storage Optimization Patterns (28)"). This is meaning well beyond the bare string type in the schema.

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 and resource ("Fetch the guidance on one FinOps topic") plus the scope of what is returned ("billing mechanics, decision rules and worked examples"), and separates itself from list_references/find_references by naming them as the discovery step. An agent can distinguish this from every sibling without opening a 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?

Gives an explicit trigger ("after list_references or find_references told you which one serves the question") and an explicit condition for the section variant ("when the question is narrower than the file"), including a concrete example of storage lifecycle in finops-azure-patterns. It also carves out advisory question types where this tool beats a summary.

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 tools Inspect

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.