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

mcp-server-scf

by MarkAC007
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

scf_system_write

Create or update systems, declare or update evidence capabilities, and queue collection-recipe generation in the SCF inventory by selecting the appropriate method.

Instructions

Manage the systems inventory (editor+): create or update a system, declare or update an evidence capability, or generate collection recipes (async). Pick with method.

Input Schema

NameRequiredDescriptionDefault
nameNoHuman-readable system name (required) [create] | New system name [update] Used by: create, update.
notesNoFree-text notes about the capability Used by: create_capability, update_capability.
methodYescreate: Create a system in the organization's infrastructure inventory (write — editor+ role). Systems can be linked to capabilities and evidence. update: Update a system record (write — editor+ role), including its boundary and recovery record. All fields are optional; only provided fields are applied. create_capability: Declare that a system can provide one evidence type (write — editor role). One entry per evidence_id per system; status defaults to potential, confidence to medium. update_capability: Update a system's evidence capability (write — editor role). Only passed fields change; move status potential → configured → active as the collector is wired up. generate_recipes: Queue AI generation of evidence-collection recipes for a system (write — editor+ role, async, HTTP 202). Poll scf_get_recipe_generation_status for progress.
org_idYesOrganization UUID — obtain from scf_list_organizations
statusNoLifecycle status (default: active) [create] | New lifecycle status [update] Used by: create, update.
vendorNoLegacy free-text vendor name (prefer vendor_id for a structural link) [create] | New legacy free-text vendor name (prefer vendor_id) [update] Used by: create, update.
categoryNoFree-text category (e.g., 'SIEM', 'Endpoint', 'Identity') [create] | New free-text category [update] Used by: create, update.
in_scopeNoInside the assessment boundary (true) or outside (false); omit when not decided [create] | Assessment boundary: true (inside), false (outside), or null to mark it undecided [update] Used by: create, update.
rpo_hoursNoRecovery point objective, in hours (≥ 0) [create] | Recovery point objective in hours (≥ 0); null clears [update] Used by: create, update.
rto_hoursNoRecovery time objective, in hours (≥ 0) [create] | Recovery time objective in hours (≥ 0); null clears [update] Used by: create, update.
system_idNoSystem UUID to update — obtain from scf_list_systems [update] | System UUID — obtain from scf_list_systems [create_capability, update_capability, generate_recipes] Used by: update, create_capability, update_capability, generate_recipes.
vendor_idNoVendor UUID to structurally link this system to — obtain from scf_list_vendors (same org) [create] | New structural vendor link (UUID, same org) — obtain from scf_list_vendors [update] Used by: create, update.
criticalityNoBusiness criticality — one of: low, medium, high, critical [create] | Business criticality — one of: low, medium, high, critical; null clears [update] Used by: create, update.
data_formatNoFormat of the collected data, e.g. 'csv', 'json', 'pdf' Used by: create_capability, update_capability.
descriptionNoFree-text description of the system [create] | New system description [update] Used by: create, update.
evidence_idNoCatalog evidence ID, e.g. E-IAM-01 Used by: create_capability.
system_typeNoSystem classification — one of: cloud_provider, identity_provider, ticketing, logging, security_tool, code_repository, document_management, endpoint_management, vulnerability_management, email_security, security_awareness, password_manager, communication, hr_system, custom [create] | New system classification — one of: cloud_provider, identity_provider, ticketing, logging, security_tool, code_repository, document_management, endpoint_management, vulnerability_management, email_security, security_awareness, password_manager, communication, hr_system, custom [update] Used by: create, update.
capability_idNoCapability UUID — obtain from scf_list_system_capabilities Used by: update_capability.
confidence_levelNoConfidence in evidence quality (default medium) [create_capability] | Confidence in evidence quality [update_capability] Used by: create_capability, update_capability.
hosting_locationNoWhere the system runs, e.g. a cloud region or data centre [create] | Where the system runs; null clears [update] Used by: create, update.
capability_statusNoCapability status (default potential) [create_capability] | Capability status [update_capability] Used by: create_capability, update_capability.
collection_methodNoHow the evidence is collected Used by: create_capability, update_capability.
catalog_template_idNoSystem-catalog template ID to link — obtain from scf_list_system_catalog [create] | New system-catalog template ID link — obtain from scf_list_system_catalog [update] Used by: create, update.
data_classificationNoHighest classification of data held — one of: public, internal, confidential, restricted [create] | Highest classification of data held — one of: public, internal, confidential, restricted; null clears [update] Used by: create, update.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds genuinely non-structured context: the editor+/editor role requirement per operation, and that generate_recipes is asynchronous returning HTTP 202 with progress tracked via a separate status tool. It still does not mention reversibility, what a null field does on update (that detail is in the schema), or rate limits, but for a write tool it goes well beyond the annotations.

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?

The role scope is front-loaded in a parenthetical and the three capability families follow in one compact sentence, so it reads quickly with little waste. The single dense sentence forces the reader to parse a comma-heavy list, and "(async)" is tacked on without saying what is returned.

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 24-parameter, five-mode multiplexed write tool with no output schema, the description covers the mode inventory, role gates, and the async follow-up, which is the core framing. It stops short of summarizing the mode-to-parameter contract (e.g. that system_id is required for four of the five methods, or that update treats all fields as optional/partial) or what the non-async methods return, leaving the agent to reconstruct that from the schema.

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 each parameter already carries per-method "Used by:" annotations plus enum value explanations, so the schema does all the parameter work. The description adds only the generic instruction "Pick with method" and no per-mode parameter guidance or conditional-requirement summary beyond what the schema states.

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 states a specific verb and resource ("Manage the systems inventory") and then enumerates all five things the tool can do: create/update a system, declare/update an evidence capability, and generate collection recipes. The name is scf_system_write and the sibling scf_system_read exists, so the write-vs-read split is inferable, but the description never names that sibling or otherwise explicitly differentiate itself from the read tool.

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?

It gives a meaningful selector ("Pick with method") and flags that generate_recipes is async, plus a follow-up pointer to scf_get_recipe_generation_status. However, it does not say when to use scf_system_write versus scf_system_read (or scf_capability_theme_read / scf_catalog_read) for related lookups, and the when-to-use detail lives almost entirely in the per-method enum descriptions inside the schema rather than in the description itself.

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