Skip to main content
Glama
mcp-server-scf

mcp-server-scf

by MarkAC007

scf_custom_risk_write

Destructive

Manage custom organization risks: create, update, or delete risk definitions and add, update, or remove linked controls via method-based actions.

Instructions

Manage custom risks (editor+): create, update or delete a risk (destructive); add, update or remove a linked control. Pick with method.

Input Schema

NameRequiredDescriptionDefault
titleNoRisk title (required, max 100 chars) [create] | New risk title (max 100 chars) [update] Used by: create, update.
methodYescreate: Create a custom org-defined risk (write — editor+ role). Auto-generates an R-ORG-N code and creates the matching risk assessment record. update: Update a custom risk definition's metadata — title, description, category (write — editor+ role). Only provided fields are applied. delete: Delete a custom risk definition, its assessment record, and every control mapping (destructive write — editor+ role). Irreversible. add_control: Link a control to a custom risk (write — editor+), optionally with the document whose standard it is an exception against. Changing an accepted exception's links clears its approval. update_control: Set or clear the standard's document on a custom risk's control link (write — editor). A changed document clears an accepted exception's approval. remove_control: Unlink a control from a custom risk (write — editor+ role). The control and risk both remain; only the mapping is removed. Unlinking clears an accepted exception's approval.
org_idYesOrganization UUID — obtain from scf_list_organizations
scf_idNoSCF control ID to link (e.g., 'AST-01') — obtain from scf_list_scoped_controls [add_control] | SCF control ID of an existing link — obtain from scf_list_custom_risk_controls [update_control] | SCF control ID to unlink (e.g., 'AST-01') — obtain from scf_list_custom_risk_controls [remove_control] Used by: add_control, update_control, remove_control.
risk_codeNoCustom risk code in R-ORG-N format (e.g., 'R-ORG-1') — obtain from scf_list_custom_risks [update, delete, add_control, remove_control] | Custom risk code in R-ORG-N format — obtain from scf_list_custom_risks [update_control] Used by: update, delete, add_control, update_control, remove_control.
descriptionNoRisk description (required) [create] | New risk description [update] Used by: create, update.
document_idNoOrganisation document that sets the standard this risk is an exception against — obtain from scf_list_documents (404 if not this org's). A link with a document makes the custom risk a standards exception [add_control] | Organisation document whose standard this risk is an exception against (404 if not this org's), or null to clear. Required: the platform refuses a call without it (422) [update_control] Used by: add_control, update_control.
category_nameNoCategory label shown in UI (default 'Custom') [create] | New category label [update] Used by: create, update.
category_colorNoHex color for the category badge, e.g., '#6b7280' (default '#6b7280') [create] | New hex color for the category badge [update] Used by: create, update.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the description's "destructive" adds little; the real added value is the editor+ role gate. The deeper consequences (delete removes the assessment record and all control mappings; link changes clear an accepted exception's approval) live only in the method's schema entry, not the description.

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?

A single compact sentence that front-loads the resource, the role requirement, and the operation groupings before the routing hint. Minor density cost from the parenthetical "(destructive)" sitting mid-clause, but nothing is wasted.

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 9-parameter, six-method polymorphic write tool it correctly signals the method-dispatch pattern and the role gate, and the per-method parameter mapping is fully covered by the schema, so no output schema is needed. The only shortfall is the absence of any guidance on precedence between scf_custom_risk_write and scf_custom_risk_read.

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 every parameter is documented per-method with format hints and provenance (e.g., obtain from scf_list_custom_risks), so the schema does the heavy lifting. The description only says to choose via method and contributes no additional field semantics, which is the baseline 3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (custom risks) and enumerates the six concrete operations grouped into risk-level (create/update/delete) and control-link-level (add/update/remove) actions, which is well beyond restating the name. It stops short of naming the sibling read tool (scf_custom_risk_read) as the non-destructive alternative, so the write/read split is only inferable from the name.

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

Usage Guidelines3/5

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

"Pick with method" gives a minimal dispatch cue and the "(editor+)" tag flags a permission prerequisite, but there is no explicit when-to-use vs. when-not guidance and no pointer to the read counterpart for fetching risks. An agent must open the schema to learn which method suits its intent.

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