Skip to main content
Glama
mcp-server-scf

mcp-server-scf

by MarkAC007

scf_control_read

Read-only

Read an organization's scoped SCF controls: list with filters, fetch one control in full, view scoping stats and framework coverage, or preview a framework scope change before applying it.

Instructions

Read the organization's control scope: list scoped controls with filters, one control in full, scoping stats, framework scope summary, or preview a framework scope change. Pick with method.

Input Schema

NameRequiredDescriptionDefault
sortNoOrder: 'scf_id' (default), or 'weighting' — material controls first, then catalogue weighting highest first, then scf_id. Rows also carry target_maturity, target_source (control | domain), target_maturity_reason, procedure_document_id, procedure_document_status, last_validated_at, last_validated_by and last_validation_note Used by: list.
basisNoFilter by obligation basis: 'mcr', 'dsr', or 'unclassified' (no classified framework and no override). Each row carries obligation_basis, basis_source (override | framework) and basis_override_reason Used by: list.
limitNoPage size (1–200, default 50) Used by: list.
domainNoSCF domain code (e.g., 'GOV', 'AST', 'IAC') Used by: list.
methodYeslist: List controls scoped to the organization with status, basis, target maturity, materiality, procedure and last validation. Filter by scope, domain, framework, team, basis, material. Paginated. get: Get one scoped control: owner, notes, scope/basis/target/material overrides with reason, set_at and set_by, procedure_document_id, last validation. Identify by scf_id, not UUID. stats: Get the organization's implementation statistics: counts by status, overall completion percentage, and per-framework coverage breakdown. framework_scope: Get framework coverage and selection state (read — viewer): each framework's coverage, basis, obligation_type and obligation_source, and basis_counts (in-scope controls by mcr/dsr/unclassified). preview_framework_change: Preview adding or removing frameworks WITHOUT applying it (read — viewer): controls entering or leaving scope, orphaned evidence, and on remove basis_downgrades (controls whose basis weakens).
offsetNoPagination offset — number of results to skip (default 0) Used by: list.
org_idYesOrganization UUID — obtain from scf_list_organizations
scf_idNoSCF control identifier in DOMAIN-NN format (e.g., 'AST-01', 'GOV-02') — NOT the UUID Used by: get.
searchNoFree-text filter applied to control ID, name, or description Used by: list.
team_idNoFilter to controls this team is assigned to, accountable or consulted — obtain from scf_list_teams Used by: list.
materialNoFilter by materiality: true for material controls (catalogue weighting 10, or an admin override), false for the rest. Rows carry material, material_source (control | weighting) and material_reason Used by: list.
my_teamsNoFilter to controls assigned to any team the caller belongs to; intersects with team_id rather than overriding it. 'The caller' is the API key's identity; on a self-hosted instance that is a service account on no team, so this returns nothing — use team_id instead. Used by: list.
frameworkNoFramework slug (e.g., 'nist-800-53') to filter mapped controls Used by: list.
operationNo'add' to preview scoping these frameworks in, 'remove' to preview taking them out Used by: preview_framework_change.
frameworksNoFramework slugs to model — obtain from scf_list_frameworks Used by: preview_framework_change.
function_idNoFilter to controls assigned to any team aligned to this function — obtain from scf_list_functions Used by: list.
csf_functionNoNIST CSF function: 'GOVERN', 'IDENTIFY', 'PROTECT', 'DETECT', 'RESPOND', or 'RECOVER' Used by: list.
scope_statusNoScope filter: 'in_scope' (selected), 'out_of_scope' (deselected), or 'all' (default — everything) Used by: list.
control_weightingNoWeighting threshold on a 0–10 scale Used by: list.
accountable_owner_typeNoFilter by the accountable team's primary owner: 'internal' or 'external_contractor' Used by: list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, and 'Read' is consistent with that. The description flags that preview_framework_change is non-mutating by calling it a preview, but omits the important caveats (permission level for the preview/framework_scope modes, pagination semantics for list) that live only in the schema.

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 front-loaded sentence with the resource first and the modes enumerated in the same order as the method enum, followed by the routing hint. Nothing is redundant or buried.

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 20-parameter, five-mode multiplexed tool with no output schema, the description gives enough to understand the surface and select a mode, and the method enum carries the detailed per-mode behavior. It stops short of describing what list/stats return in any useful shape, but the schema shoulder most of that burden.

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 description coverage is 100% and the schema is unusually explicit, including per-parameter 'Used by:' tags, so the baseline would be 3. The description adds a small amount by pairing each mode name with the data it returns, but contributes no syntax or constraints beyond what the schema already documents.

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?

The description uses a specific verb+resource ('Read the organization's control scope') and enumerates all five modes the method parameter selects (list, get, stats, framework_scope, preview). An agent can tell this is the read-side counterpart to scf_control_write, though it never names that sibling explicitly.

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' is the only routing instruction, and it defers entirely to the method enum's schema text for when to choose each mode. There is no when-not guidance and no mention of alternatives outside the tool; usage 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.