Skip to main content
Glama
Sign In
mcp-server-scf

mcp-server-scf

by MarkAC007
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

scf_evidence_read

Read-only

Read evidence-tracking records, coverage gaps, collection health, due items, maturity, and upgrade guidance to review evidence status and identify next collection actions.

Instructions

Read evidence tracking: list records, one record with its in-scope requiring controls, requiring controls alone, gaps, health, upcoming, frequency health, maturity and upgrade guidance, suggestions.

Input Schema

NameRequiredDescriptionDefault
daysNoLook-ahead window in days (1–90, default 14) Used by: upcoming.
methodYeslist: List the organization's evidence tracking records: tracking status, maturity, owner, system, file count, required_by_scope. Names no controls — use scf_get_evidence_requiring_controls for those. get: Get one evidence tracking record (read) plus required_by_in_scope_controls (the org's in-scope controls that require it) and, as labelled context, catalog_control_mappings. 404 if untracked. requiring_controls: Which in-scope controls require one evidence item (read; works untracked). Primary: required_by_in_scope_controls with status and maturity. Context: catalog_control_mappings and what is not in scope. gaps: List the organization's evidence coverage gaps: evidence required by in-scope controls that is not yet tracked, with overall coverage percentage. health: Get evidence collection health for the organization: per-item freshness status (green/amber/red) against collection frequency, with a roll-up summary. upcoming: List evidence whose next collection falls due within N days (read — viewer role), computed from each item's frequency and last upload. The daily 'what is due' view. frequency_health: Report evidence whose declared frequency disagrees with the observed upload cadence over the last 90 days (read — viewer role). Only misaligned items are returned. maturity_summary: Get the organization's evidence maturity summary: average maturity score, automation percentage, distribution by maturity level, and improvement opportunities. item_maturity: Get one evidence item's collection maturity: current level (1=Ad Hoc to 5=Optimized), contributing factors, upgrade potential, and tracking state. upgrade_recommendations: Get upgrade-path recommendations for maturing one evidence item's collection: target level, effort, impact, and step-by-step actions — the same guidance shown in the platform UI. suggestions: Get system-aware collection suggestions for one evidence item: which tracked system currently collects it, which in-scope systems are capable of collecting it, and tailored collection guidance.
org_idYesOrganization UUID — obtain from scf_list_organizations
team_idNoFilter to evidence this team is assigned to, accountable or consulted — obtain from scf_list_teams Used by: list.
my_teamsNoFilter to evidence 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.
system_idNoSystem UUID to filter by — obtain from scf_list_systems Used by: list.
evidence_idNoCatalog evidence ID, e.g. E-IAM-01 — obtain from scf_list_evidence_catalog [get] | Catalog evidence ID, e.g. E-AST-09 — obtain from scf_list_evidence or scf_list_evidence_catalog [requiring_controls] | Evidence ID (e.g., 'E-RSK-02') — obtain from scf_list_evidence [item_maturity, upgrade_recommendations, suggestions] Used by: get, requiring_controls, item_maturity, upgrade_recommendations, suggestions.
function_idNoFilter to evidence assigned to any team aligned to this function — obtain from scf_list_functions 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

B3.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the description's 'Read' prefix is consistent with it. But beyond that the description adds no behavioral context of its own: no mention of the viewer-role requirement on `upcoming`/`frequency_health`, the 90-day observation window, the 404 for untracked evidence, or the 90-day cap on `days` — all of which 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.

Conciseness3/5

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

It is a single front-loaded sentence with no filler, which is structurally sound. However, most of its content is a compressed restatement of the method enum names already fully documented in the schema, and the telegraphic list style ('gaps, health, upcoming, frequency health, maturity and upgrade guidance, suggestions') sacrifices parseability without adding new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter, eleven-mode endpoint with no output schema, the description gives only mode labels and never characterizes what any mode returns (record fields, coverage percentage, green/amber/red statuses, maturity levels). The rich schema compensates for parameter completeness, but the absence of return-shape signal leaves a real gap for a multi-mode read tool.

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%, so the schema already documents all nine parameters, including per-method applicability ('Used by: list'), enum meanings, and where to obtain IDs. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 opens with a specific verb+resource ('Read evidence tracking') and enumerates the operation families the single multiplexed endpoint covers (list, get, requiring controls, gaps, health, upcoming, frequency health, maturity, upgrade guidance, suggestions). It is distinguishable from the write sibling and from scf_evidence_file_read by naming the tracking records themselves, though the compressed phrasing ('one record with its in-scope requiring controls, requiring controls alone') makes several modes hard to separate at a glance.

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?

Listing the modes implies which value to pass to `method`, but the description never says when to prefer one mode over another, nor when to use a sibling such as scf_get_evidence_requiring_controls instead of the `requiring_controls` method. That routing guidance exists only in the schema's method descriptions, so usage selection 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