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

mcp-server-scf

by MarkAC007
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

scf_evidence_write

Create or update evidence tracking records from catalog IDs, upsert tracking fields, or batch-upsert up to 500 items in one transaction to keep compliance evidence current.

Instructions

Create or update evidence tracking records (editor+): create one from a catalog id, upsert one record's tracking fields, or batch-upsert up to 500 in one transaction. Pick with method.

Input Schema

NameRequiredDescriptionDefault
ownerNoPerson accountable for this evidence item Used by: create, update.
methodYescreate: Create an evidence tracking record from a catalog evidence ID (write — editor+ role). Starts tracking an evidence item for the organization. update: Upsert an evidence item's tracking fields (write — editor+ role). Creates the tracking row if missing. All body fields are optional; only provided fields are applied. batch_update: Create or update up to 500 evidence tracking records in one transaction (write — editor role). Each upserts by evidence_id; only fields given change. Use instead of 500 scf_update_evidence calls.
org_idYesOrganization UUID — obtain from scf_list_organizations
commentsNoFree-text notes or context Used by: create, update.
frequencyNoCollection cadence: 'daily', 'weekly', 'monthly', 'quarterly', or 'annually' Used by: create, update.
system_idNoSystem UUID to link this evidence to — obtain from scf_list_systems Used by: create, update.
is_trackedNoStart actively tracking this item (default false) [create] | Toggle active tracking for this item [update] Used by: create, update.
operationsNoUpsert operations, max 500 — each keyed by evidence_id Used by: batch_update.
evidence_idNoCatalog evidence ID (e.g., 'E-IAM-01') — obtain from scf_list_evidence_catalog [create] | Catalog evidence ID (e.g., 'E-IAM-01') — obtain from scf_list_evidence or scf_list_evidence_catalog [update] Used by: create, update.
maturity_levelNoEvidence maturity level L0–L5 (e.g., 'L3'); omit to leave unset [create] | Evidence maturity level L0–L5 (e.g., 'L3'); omitting never clears the stored value [update] Used by: create, update.
collecting_systemNoName of the tool or system that collects the evidence Used by: create, update.
method_of_collectionNoCollection approach: 'automated', 'manual', or 'hybrid' Used by: create, update.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations only cover readOnlyHint=false and destructiveHint=false; the description adds real context beyond them — the editor+ permission floor, the 500-record batch ceiling, the transactional nature of batch_update, and the fact that update upserts a row if missing. It omits what a failed batch does (partial vs full rollback) and what the response contains.

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 sentence that leads with the verb and resource, then enumerates the modes in the order an agent needs them, ending with the discriminator. No filler or redundant restatement of the title.

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 12-parameter mutation tool whose schema is fully documented and whose annotations declare the safety profile, the description supplies the essential framing: role gate, batch limit, and mode selection. The only gap is response behavior, which matters somewhat given no output schema exists.

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 per-parameter meaning (including the detailed method enum semantics and the 'Use instead of 500 scf_update_evidence calls' note) is already documented in structured data. The description only restates the method names and the catalog-id concept, adding no syntax or edge-case detail beyond the schema.

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 verb and resource ('Create or update evidence tracking records') and enumerates the three modes it supports: single create from a catalog id, single-record upsert, and batch upsert of up to 500. It is clearly a write counterpart to scf_evidence_read, 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 Guidelines4/5

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

Gives a clear selection rule — 'Pick with method' — plus an upfront role requirement ('editor+') that gates who may call it. It does not state when to prefer this over scf_evidence_task_write or other write siblings, leaving that routing to the agent.

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