Shoot Plan

Record a decision about a finding

shoot_plan_record_decision

Read-only

Records a decision about one finding from shoot_plan_check (accepted, overridden or wont_fix), with the reason and who decided, so that you do not raise it again next session. We keep nothing: the answer is the updated decision log, and you must keep it and send it back to shoot_plan_check as dispositions. A finding with a remembered decision then comes back closed, with the reason, for as long as the evidence behind it is unchanged; if the evidence changes, it comes back open again. Input: plan; finding_id (a finding's id from shoot_plan_check); decision (accepted, overridden or wont_fix); reason (why, in plain words); by (who decided); optionally at (an ISO 8601 time with a zone, such as 2026-10-18T09:30:00Z; the time of the request if left out) and dispositions (the log you were given last time, to extend it: a later decision about the same finding replaces the earlier one, which stays as history). Output: dpl.dispositions/1, the log with this decision added. A finding_id the plan does not have is refused. No AI model runs. We don't keep the plan. We log a one-way fingerprint (hash) of it, its size, the tool, the type of client, the result and the time taken. Needs an agent key from a Shoot Plan account. Free, and it does not count toward the account's 3 free projects a month. Plans up to 8 MB and 120 calls a minute (5,000 a day).

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": {
      "plan": "<plan>",
      "finding_id": "<finding_id>",
      "decision": "<decision>",
      "reason": "<reason>",
      "by": "<by>"
    },
    "name": "shoot_plan_record_decision"
  }
}

Input Schema

Name	Required	Description
`at`	No	Optional: when it was decided, an ISO 8601 time with a zone, for example 2026-10-18T09:30:00Z. The time of the request if left out.
`by`	Yes	Who decided: a name.
`plan`	Yes	The plan itself: a dpl.plan/1 JSON object (not text inside a string). Call shoot_plan_format for the schema links and an example.
`reason`	Yes	Why, in plain words. It is shown when the finding is closed by this decision.
`decision`	Yes	accepted, overridden or wont_fix.
`finding_id`	Yes	The id of a finding in the shoot_plan_check result for this plan, for example f-3a9c51d02b7e.
`dispositions`	No	The decision log: the dpl.dispositions/1 document shoot_plan_record_decision returned, exactly as returned. You keep it; we don't.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the sparse annotations: it discloses that nothing is retained server-side, that the caller must persist the log, how remembered decisions affect future shoot_plan_check results, that unknown finding_ids are refused, plus the hashing/telemetry, agent-key requirement, and size/rate limits. This also reconciles the seemingly odd readOnlyHint=true with a 'records' verb.

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 the action and the contract (nothing stored, caller keeps the log), and organized as Input/Output/constraints. Some redundancy – the decision values are listed twice and the 'we don't keep it' promise is restated – costs it a point.

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 tool with nested objects, it covers input meanings, output document type, error behavior, auth, and quotas; an output schema exists so return values need no elaboration. Nothing an agent needs in order to call it correctly is missing.

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, but the description adds real meaning: dispositions extend a prior log and later decisions replace earlier ones while keeping history, and `at` defaults to request time. It does repeat the enum values already present in the schema, which caps it below 5.

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 ('Records a decision about one finding from shoot_plan_check') and enumerates the decision values, so an agent can distinguish it from siblings like shoot_plan_check (which reports findings) or shoot_plan_apply_fix (which changes the plan).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear when: after shoot_plan_check, to prevent a finding being raised again, and explicitly describes the round-trip (keep the returned log and send it back as dispositions). It does not explicitly contrast with shoot_plan_apply_fix, which handles the case where the user wants a fix rather than an override.

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

All Shoot Plan 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?