Skip to main content
Glama
MarkAC007

mcp-server-scf

by MarkAC007
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

scf_add_custom_risk_control

Link a control to a custom risk, optionally citing the document whose standard it is an exception against. Updating an accepted exception's links clears its approval.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
org_idYesOrganization UUID — obtain from scf_list_organizations
scf_idYesSCF control ID to link (e.g., 'AST-01') — obtain from scf_list_scoped_controls
risk_codeYesCustom risk code in R-ORG-N format (e.g., 'R-ORG-1') — obtain from scf_list_custom_risks
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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.7.2
    • addedInput schema / properties / document_id
      Added value: +{
+  "description": "Organisation 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",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}
  2. First observedv1.7.0

TDQS

A4.2/5.0
Behavior4/5

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

Goes meaningfully beyond the annotations by disclosing an authorization requirement (editor+) and a non-obvious side effect: changing an accepted exception's links clears its approval. That is exactly the kind of hidden consequence annotations (destructiveHint=false, readOnlyHint=false) cannot convey. It stops short of describing idempotency or conflict/duplicate-link behavior.

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?

Two compact clauses, front-loaded with the action and scope, with the permission note and the side-effect warning packed in without filler. Every sentence earns its place.

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 4-parameter mutation with no output schema, the definition covers what it writes, who can call it, and a key side effect, which is most of what an agent needs. Missing minor details such as duplicate-link handling and the shape of the confirmation response.

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 coverage is 100% and each parameter already documents format plus its source tool. The description restates the optional document semantics ('document whose standard it is an exception against') that the schema property already spells out, so it adds little beyond the structured fields.

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 (link) and resource (control to custom risk), and the optional document qualification. An agent can distinguish it from siblings scf_update_custom_risk_control, scf_remove_custom_risk_control, and scf_list_custom_risk_controls without opening schemas.

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?

Specifies the caller precondition ('write — editor+') and the optional document use case, which tells the agent when the exception variant applies. It does not explicitly contrast with the update/remove siblings, so alternative-choice guidance is implied rather than stated.

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

Deploy Server

Other Tools