Costory: Your Finops MCP

update_scout

Destructive

Replace one scout persona's FULL standing prompt (its persona/instructions text) with new complete prompt text — nothing else about the scout can change here (renaming/description stay in the web app; a numbers change means an explicit report/widget configuration edit, proposed separately). scout accepts the NAME (from list_scouts — preferred) or the id; an ambiguous or unknown name resolves to an error — ask the user which scout they mean. Archived scouts are rejected. BEFORE calling: read the scout's CURRENT prompt with list_scouts, show the user the exact proposed diff (old prompt → new prompt) in chat, and get their explicit confirmation — the tool call itself is the approval point and the prompt must be the full final text, not a patch. Never fabricate the old side of the diff; when list_scouts does not return the scout, you cannot read its prompt and must not propose a replacement. The write re-checks edit access at execution time. EXAMPLE: { scout: "FinOps Sage", prompt: "You are FinOps Sage. Prioritize AWS savings, ...", }

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": {
      "scout": "<scout>",
      "prompt": "<prompt>"
    },
    "name": "update_scout"
  }
}

Input Schema

Name	Required	Description
`slug`	No	Organization slug. Omit to auto-detect from your account (fails if you belong to multiple orgs).
`scout`	Yes	Scout persona NAME (from list_scouts) — preferred — or its id, whose standing prompt is replaced.
`prompt`	Yes	The new FULL standing prompt text (persona/instructions). It REPLACES the scout's current prompt entirely — not a patch, an append, or a partial edit.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description reinforces why: the prompt is entirely replaced, not patched, so prior text is lost. It adds context annotations cannot express — archived scouts rejected, edit access re-checked at execution time, and that the tool call itself is the approval point. It stops short of stating whether the previous prompt is recoverable or what a successful response contains.

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?

Dense but nearly every clause earns its place on a destructive full-text replacement. Minor waste: the inline EXAMPLE largely restates what the 100%-covered schema already documents, and the single-paragraph flow of constraints would scan better as ordered prerequisites.

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 destructive write with no output schema, the definition covers prerequisites, approval flow, edge cases and scope exclusions. The remaining gap is outcome behavior: nothing says what a successful replacement returns or whether the prior prompt can be recovered if the user changes their mind.

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 would be 3, but the description adds operational meaning: `scout` takes the NAME from list_scouts (preferred) or the id, and an ambiguous or unknown name is an error requiring the user to disambiguate. The 'full final text, not a patch' and 'never fabricate the old side of the diff' guidance constrains how `prompt` must be constructed.

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: replacing one scout persona's FULL standing prompt, and immediately bounds scope by excluding renaming/description (web app) and numbers changes (report/widget config, proposed separately). That negative scoping is what separates it from create_scout, update_report and the other update_* 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 an explicit pre-call procedure: read the current prompt via list_scouts, show the user the old→new diff in chat, obtain explicit confirmation, then call. It also covers the failure branches (ambiguous/unknown name → ask the user; archived scouts rejected; scout not returned by list_scouts → do not propose a replacement) and names where the out-of-scope edits actually belong.

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 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.

Resources

Need Help?