Skip to main content
Glama
Sign In

Costory: Your Finops MCP

by io.costory.app-api
OverviewDiscussionsAdmin

get_skill

Read-only

Load a workflow guide or any markdown file from the Costory skills GitHub repo. Use when the requested task needs Costory workflow guidance. Returns markdown. For build tasks, load a mechanics skill ("virtual-dimensions", "dashboards", "reports", "query"). When a curated recipe fits the user's outcome, call with skillId: "recipes", then load the matching card via its repo-relative .md path. Pass either: (1) a catalog skillId from list_skills (e.g. "virtual-dimensions", "dashboards", "reports", "query", "recipes"), or (2) a repo-relative .md path (e.g. a recipe card or skill reference under plugins/costory/skills/…). Paths must be relative, end in .md, and cannot traverse (..). EXAMPLES: • "Match outcome to a recipe card" → { skillId: "recipes" } • "Build an AWS overview dashboard" → { skillId: "dashboards" } • "Generate a report of monthly changes" → { skillId: "reports" } • "Create a custom cost axis" → { skillId: "virtual-dimensions" } • "Load the marketplace spend recipe" → { skillId: "plugins/costory/skills/recipes/marketplace-spend.md" } • "Load the dashboards dashboard-overview reference" → { skillId: "plugins/costory/skills/dashboards/references/how-to-generate-interesting-dashboards.md" }

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "skillId": "<skillId>",
      "context": "<context>"
    },
    "name": "get_skill"
  }
}

Input Schema

NameRequiredDescriptionDefault
contextYesA few words on why you are calling this tool, for the server developer's analytics. Describe people and things by role, such as "a customer". Do not quote the user or include names, emails, or other personal details.
skillIdYesCatalog skillId from list_skills (e.g. "dashboards", "reports", "recipes", "virtual-dimensions") OR a repo-relative .md path in the skills GitHub repo (e.g. "plugins/costory/skills/recipes/explain-period-change.md").
llm_modelNoThe model identifier you are running as, for example "claude-opus-4-8" or "gpt-5.2". Pass "unknown" if you are not certain. Recorded for the server developer's analytics.
conversation_idNoThe conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / context / description
      Previous value: -"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""New value: +"A few words on why you are calling this tool, for the server developer's analytics. Describe people and things by role, such as \"a customer\". Do not quote the user or include names, emails, or other personal details."
    • changedInput schema / required
      Previous value: -[
-  "skillId",
-  "context",
-  "llm_model"
-]New value: +[
+  "skillId",
+  "context"
+]
  2. Changed4 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+  "type": "string"
+}
    • addedInput schema / properties / conversation_id
      Added value: +{
+  "description": "The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.",
+  "type": "string"
+}
    • addedInput schema / properties / llm_model
      Added value: +{
+  "description": "The model identifier you are running as, for example \"claude-opus-4-8\" or \"gpt-5.2\". Pass \"unknown\" if you are not certain. Recorded for the server developer's analytics.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "skillId"
-]New value: +[
+  "skillId",
+  "context",
+  "llm_model"
+]
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds that the return value is markdown and imposes path validation rules (must be relative, end in .md, no '..' traversal). It does not say what happens on an unknown skillId or a nonexistent path, which is the remaining gap for a loader tool.

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 rules, then examples — a sensible order. It is somewhat verbose: the catalog skillId list ('virtual-dimensions', 'dashboards', 'reports', 'query', 'recipes') is enumerated twice, once inline and once repeated in the 'Pass either' sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, no-output-schema loader, the description covers purpose, routing, both addressing modes, path constraints, and return type. Minor omissions remain around failure modes (invalid id, missing file) and whether loaded guidance should be re-fetched per turn.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 would be the baseline, but the description adds meaning the schema lacks: it explains the two mutually exclusive addressing modes for skillId (catalog id vs. repo-relative path) and documents the path-format constraint that the schema only expresses as minLength. It adds no interpretation for context, llm_model, or conversation_id, which are already fully documented in-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: 'Load a workflow guide or any markdown file from the Costory skills GitHub repo', and immediately scopes it to workflow guidance. It is clearly distinguishable from list_skills (which yields the catalog) and from the query/get data tools named as siblings.

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 explicit when-to-use ('when the requested task needs Costory workflow guidance'), a routing rule for build tasks (load a mechanics skill from an enumerated set), and a two-step recipe procedure: call with skillId 'recipes' then load the card by repo-relative path. The examples map concrete user outcomes to concrete arguments, leaving little inference.

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

All Costory: Your Finops 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