Skip to main content
Glama
Sign In

Costory: Your Finops MCP

by io.costory.app-api
OverviewDiscussionsAdmin

publish_label_dimensions

Destructive

Merge add/update/delete operations onto published label dimensions, then replace the stored document (one feature-engineering refresh, about 10 minutes). Use when the user wants to save merged label-dimension changes (preview with dryRun: true first). Input is operations[], never the full labels array — sibling labels you do not mention are kept. add: sourceKeys (required), optional name/maps (id is generated). update/delete: target by id from list_label_dimensions (or an id created by an earlier add in the same array). Duplicate sourceKeys across labels are rejected; move a key with update on the owner in the same array. Names must be unique across labels and virtual dimension bqNames (default name is a sanitized sourceKeys[0]); a collision rejects the whole operations array — send a different unique name. Deleting a label and adding it back (same name or sourceKeys) in the same array is allowed, in either order. dryRun defaults true (preview the full next labels document, no write). Persist once with dryRun: false and confirm: true. Check list_label_dimension_usages before rename or delete. Demo orgs are read-only unless the Clerk caller is an org admin on that tenant; dimensionsAdminOnly requires an org admin. Real write is Clerk MCP only — the service route accepts dry-run only. Do not call publish twice. EXAMPLES: • Preview adding environment + team → { dryRun: true, operations: [{ op: "add", sourceKeys: ["env", "environment"], name: "environment", maps: [{ value: "prd", to: "production" }] }, { op: "add", sourceKeys: ["team"], name: "team" }] } • Persist the same ops once → { dryRun: false, confirm: true, operations: [] }

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

Input Schema

NameRequiredDescriptionDefault
slugNoOrganization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
dryRunNoWhen true (default), merge and validate only — no Prisma write and no feature-engineering job.
confirmNoMust be true to persist. Merges add/update/delete onto all existing label dimensions, replaces the stored document, and starts a feature-engineering refresh that takes about 10 minutes. Put every change into this one call. Check list_label_dimension_usages before delete or rename.
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.
operationsYesadd / update / delete operations applied in order onto the currently published labels.
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: -[
-  "operations",
-  "context",
-  "llm_model"
-]New value: +[
+  "operations",
+  "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: -[
-  "operations"
-]New value: +[
+  "operations",
+  "context",
+  "llm_model"
+]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint: true), disclosing the ~10-minute feature-engineering refresh, that the stored document is replaced while unmentioned sibling labels are kept, that name collisions reject the entire operations array, the demo-org read-only rule, and that real writes only work through the Clerk MCP route. That is exactly the behavioral context an agent needs before a destructive write.

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 and a preview-first instruction, then the operational rules. Every sentence carries a rule, but the block is dense and run-on, packing edge cases (delete-then-add, duplicate sourceKeys, name collisions) into a single paragraph that rewards re-reading.

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 7-parameter destructive mutation with no output schema, nothing material is missing: precedence of dryRun/confirm, atomicity of the operations array, ordering semantics, permission constraints, and timing of the refresh are all stated.

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 schema already documents parameters well, and the description adds further meaning: input is operations[] and never the full labels array, ids are generated on add, update/delete target by id, and the default name comes from a sanitized sourceKeys[0]. Marginal value beyond the schema is real but modest.

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 set and resource: 'Merge add/update/delete operations onto published label dimensions, then replace the stored document.' This clearly separates it from the read-only siblings list_label_dimensions and list_label_dimension_usages, which it references by name.

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 says when to use it ('when the user wants to save merged label-dimension changes'), mandates previewing with dryRun: true first, requires 'Check list_label_dimension_usages before rename or delete', and warns 'Do not call publish twice.' Alternatives and exclusions are both covered.

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