Skip to main content
Glama
Sign In

Costory: Your Finops MCP

by io.costory.app-api
OverviewDiscussionsAdmin

list_metrics

Read-only

List saved Costory business metrics and, optionally, matching live external metrics from connected integrations (e.g. Tsuga, BigQuery, Datadog, CloudWatch, Google Cloud Monitoring). Use when the user asks which business or integration metrics are available to query. Saved metrics return id/name/type for { type: "metric", metricId: "..." } in query. Set includeExternal: true with a specific search term to return externalMetrics with provider, integrationId, integrationName, metricName, unit, capabilities, and attributes. That catalog is enough to build { type: "externalMetric", provider, integrationId, metricName, aggregator, groupByFields, conditions } for Tsuga, Datadog (attributes are tag keys; metricName is the Datadog metric name), CloudWatch (metricName is Namespace/MetricName such as AWS/EC2/CPUUtilization; attributes are dimension names), Google Cloud Monitoring (provider "cloudmonitoring"; metricName is the metric type such as compute.googleapis.com/instance/cpu/utilization; attributes are fully-qualified group-by fields such as metric.label.state or resource.label.project_id, and conditions is an optional Monitoring filter), or Amplitude. For BigQuery or S3, the same hit also includes schema (typed columns: DATE / NUMERIC / STRING). Pick dateColumn from the first DATE field, metricColumn from the first NUMERIC field, and groupByFields from STRING fields (also listed in attributes). gapFillingMethod is not in the catalog — default FORWARD_FILL unless the user specifies ZERO, LINEAR_INTERPOLATION, or SPREAD. Those three fields are required on both query and a new virtual-dimension telemetry allocation. Do not call includeExternal without search; external catalogs can be large, and the tool will ask for a search term instead of listing everything. externalLimit (default 50, max 50) caps matching external results. New virtual-dimension telemetry reallocations use includeExternal + an inline externalMetric (same fields as a query series, plus exactly one groupByFields entry as the series key). Pass datasourceId only to inspect a leftover saved usage-metric datasource's groupByDimensions — not for new reallocations. Then call query (type: "metric", metricId, groupBy) to inspect the values for that leftover datasource. The datasourceId is the same metricsDatasource id this tool returns as a saved-metric id (strip any ::metricName suffix). Does not return values (use query). EXAMPLES: • "What business metrics do we have?" → {} • "Find Tsuga metrics about requests" → { includeExternal: true, search: "request" } • "Find BigQuery tables about revenue" → { includeExternal: true, search: "revenue" } • "Find Datadog metrics about CPU" → { includeExternal: true, search: "cpu" } • "Find CloudWatch metrics about CPU" → { includeExternal: true, search: "CPUUtilization" } • "Find GCP Monitoring metrics about CPU" → { includeExternal: true, search: "cpu/utilization" } (Cloud Monitoring search matches the metric type, not its display name) • "What live metrics can I reallocate shared cost by?" → { includeExternal: true, search: "cpu" } • "What can I split a leftover saved-metric datasource by?" → { datasourceId: "clx…" }

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": {
      "context": "<context>"
    },
    "name": "list_metrics"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoOrganization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
searchNoOptional filter on saved metric names. Required when includeExternal is true because external metric catalogs can be large.
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.
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.
datasourceIdNoSpecial list mode (not a query field): return groupBy dimensions for ONE leftover saved usage-metric datasource. New telemetry reallocations use includeExternal + inline externalMetric instead. Pass the metricsDatasource id from metrics[].id (strip any `::metricName` suffix). Then call query with type:"metric", metricId:<same id>, groupBy:<dimension>. Do not confuse with query metricId — that is the identity field on the query tool; this filter only returns dimensions. When set, search / includeExternal are ignored.
externalLimitNoMax matching external metrics to return when includeExternal is true and search is provided (capped at 50).
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.
includeExternalNoWhen true and search is provided, include matching live integration-backed external metrics in externalMetrics.

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: -[
-  "context",
-  "llm_model"
-]New value: +[
+  "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"
+}
    • addedInput schema / required
      Added value: +[
+  "context",
+  "llm_model"
+]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds real behavior beyond that: it explicitly does not return values, external catalogs can be large so the tool will demand a search term, externalLimit defaults to 50 and is capped at 50, and datasourceId triggers a distinct "special list mode" that ignores search/includeExternal. There is mild tension between openWorldHint=false and reading from connected integrations, but the bounded, search-gated catalog described is consistent with a closed-domain read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly – what it does, when to use it, then examples – but the middle is a dense wall of text about constructing externalMetric query payloads, aggregator/groupByFields/conditions, DATE/NUMERIC column selection, and gapFillingMethod defaults, most of which belongs to the `query` tool's documentation. Many sentences describe downstream payload construction rather than helping select or invoke this list tool, so the description is substantially longer than its job requires.

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?

There is no output schema, so the description carries the full burden of describing returns and does so concretely: saved metrics yield id/name/type, externalMetrics yield provider, integrationId, integrationName, metricName, unit, capabilities and attributes, and BigQuery/S3 hits additionally include a typed `schema`. For an eight-parameter discovery tool, an agent has enough to call it and interpret the response.

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 the baseline is 3 and the schema already documents each field, including the search/includeExternal dependency and the externalLimit cap. The description nonetheless adds usable semantics by pairing argument combinations with user intents in the examples and by clarifying that datasourceId is a mode switch rather than a query field. It loses a point for largely restating the schema's own notes rather than adding new per-parameter nuance.

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?

Opens with a specific verb and resource: "List saved Costory business metrics and, optionally, matching live external metrics from connected integrations." It also draws the boundary against the sibling it is most likely to be confused with ("Does not return values (use `query`)"), so an agent can separate catalog discovery from value retrieval without reading either 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 ("Use when the user asks which business or integration metrics are available to query"), explicit negative guidance ("Do not call includeExternal without search"), and names the alternative to use for values. The example block maps concrete user phrasings to concrete argument sets, which is the strongest form of routing guidance.

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