mcp-server-scf

scf_risk_write

Destructive

Create, update, delete, or accept risk register entries by selecting an operation with the method field. Record or renew risk acceptances with rationale and expiry dates.

Instructions

Change the risk register (editor+; accept is admin): create a risk assessment, update one, delete one (destructive), or record or renew a risk acceptance. Pick with method.

Input Schema

Name	Required	Description
`notes`	No	Free-text notes on this risk assessment Used by: update.
`owner`	No	Name or identifier of the risk owner Used by: create.
`title`	No	Risk title (required, max ~100 chars) Used by: create.
`impact`	No	Inherent impact on a 1–5 scale Used by: create, update.
`method`	Yes	create: Create a new risk assessment in the risk register (write — editor+ role). Likelihood and impact scores populate the 5×5 risk matrix. update: Update a scored risk by code (write — editor). Only passed fields change. Setting accepted records no approval (use scf_accept_risk); re-scoring an accepted risk clears its approval. delete: Delete an organization's scoring of a risk code (destructive write — editor role). The catalog or custom risk definition itself remains; only this org's assessment row is removed. accept: Accept a risk (write — admin): records you as approver, now, the rationale and expiry. Renews an accepted risk. Also accepts a standards exception. A platform key without a user gets 403.
`org_id`	Yes	Organization UUID — obtain from scf_list_organizations
`rationale`	No	Why the risk is accepted (required, non-blank; stored trimmed). Blank is refused Used by: accept.
`risk_code`	No	Risk code — catalog R-XX-N or custom R-ORG-N [update, delete] \| Risk code — catalog R-XX-N or custom R-ORG-N — obtain from scf_list_risks or scf_list_custom_risks [accept] Used by: update, delete, accept.
`control_id`	No	SCF control ID to link (e.g., 'AST-01') — obtain from scf_list_controls Used by: create.
`expires_on`	No	Date the acceptance lapses (YYYY-MM-DD); must be after today (400 otherwise) Used by: accept.
`likelihood`	No	Inherent likelihood on a 1–5 scale Used by: create, update.
`description`	No	Risk description (required) Used by: create.
`owner_user_id`	No	Risk owner — obtain from scf_list_members Used by: update.
`treatment_plan`	No	How the risk is being treated Used by: update.
`residual_impact`	No	Residual impact after treatment, 1–5 scale Used by: update.
`next_review_date`	No	YYYY-MM-DD Used by: update.
`treatment_status`	No	Treatment workflow status (default identified) [create] \| Treatment lifecycle state. 'accepted' set here records no approval — scf_accept_risk does. Below admin, moving an accepted risk with an approval in force off accepted is ignored (it stays accepted); an admin's move clears the acceptance [update] Used by: create, update.
`treatment_due_date`	No	YYYY-MM-DD Used by: update.
`residual_likelihood`	No	Residual likelihood after treatment, 1–5 scale Used by: update.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.1.0Nov 5, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description reinforces this by labeling delete as destructive and noting only this org's assessment row is removed while the catalog definition persists. It further adds non-obvious constraints – accept requires admin, a platform key without a user gets 403, expiry must be in the future – that go beyond the annotations, though it does not describe the response shape.

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

Conciseness5/5

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

A single dense sentence plus a routing instruction, with the resource, the role gate, and the destructive warning all front-loaded. No filler sentences.

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 19-parameter multiplexed mutation tool with no output schema, the description plus the fully documented method enum give an agent enough to pick the right method and understand the permission and destructive implications. Residual gap is that nothing describes the return payload, but that is minor given the schema's richness.

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

Parameters3/5

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

Schema description coverage is 100% and each parameter already carries per-method 'Used by' annotations, so the description adds essentially nothing per-parameter beyond restating which method is chosen. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

The description opens with a specific verb+resource ("Change the risk register") and then enumerates the four operations the single tool multiplexes (create, update, delete, record/renew acceptance), which clearly separates it from the read-side sibling scf_risk_read and from scf_custom_risk_write.

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?

It states that method selects the operation and flags role gates (editor+ for changes, admin for accept), plus the schema's method enum explicitly routes approval recording to scf_accept_risk instead of setting treatment_status to accepted. There is no explicit statement of when to prefer this over scf_custom_risk_write, which keeps it below a 5.

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

scf_risk_write

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools