mcp-server-scf

scf_vendor_write

Create or update organization vendor records, trigger AI security research, or queue a vendor assessment by selecting the method.

Instructions

Manage vendors (editor+): create or update a vendor, trigger AI research, or trigger a DPSIA assessment (async). Pick with method.

Input Schema

Name	Required	Description
`name`	No	Vendor legal or trading name (required) [create] \| New vendor name [update] Used by: create, update.
`method`	Yes	create: Create a vendor in the TPRM registry (write — editor+ role). Platform auto-scores risk based on criticality and data handling. update: Update an existing vendor record (write — editor+ role). Only provided fields are applied. research: Queue AI security research for a vendor (write — editor+ role, async). Checks HIBP breach data, NVD vulnerabilities, and public posture. Returns a task ID; poll scf_get_vendor_research. assess: Queue an AI vendor security assessment (write — editor+ role, async, HTTP 202). Replaces the deprecated DPSIA trigger. Returns assessment_id + job_id; poll scf_get_vendor_assessment_status.
`org_id`	Yes	Organization UUID — obtain from scf_list_organizations
`status`	No	Lifecycle status (default prospect) — one of: prospect, active, under_review, approved, suspended, offboarded [create] \| New lifecycle status — one of: prospect, active, under_review, approved, suspended, offboarded [update] Used by: create, update.
`website`	No	Vendor website URL [create] \| New website URL [update] Used by: create, update.
`category`	No	Category label (e.g., 'SaaS', 'Infrastructure', 'Consulting') [create] \| New category label [update] Used by: create, update.
`data_role`	No	GDPR data role (default 'Processor') Used by: assess.
`vendor_id`	No	Vendor UUID — obtain from scf_list_vendors Used by: update, research, assess.
`criticality`	No	Business criticality tier (default 'medium') [create] \| New criticality tier [update] Used by: create, update.
`description`	No	Short free-text description of the vendor [create] \| New free-text description [update] Used by: create, update.
`contact_email`	No	Primary contact email address [create] \| New primary contact email [update] Used by: create, update.
`data_location`	No	Where the vendor stores or processes our data [create] \| Where the vendor stores or processes our data; null clears [update] Used by: create, update.
`services_used`	No	Description of services the vendor provides, 1–2000 chars (auto-derived from the vendor record if omitted) Used by: assess.
`assessment_type`	No	Assessment type: 'initial', 'annual', or 'adhoc' (default 'initial') Used by: assess.
`domain_override`	No	Override the vendor's website domain used for research lookup (e.g., 'example.com') Used by: research.
`additional_context`	No	Free-text context, scope notes, or specific concerns to feed the assessor (max 5000 chars) Used by: assess.
`flow_down_requirements`	No	Requirements passed down to the vendor by contract [create] \| Requirements passed down to the vendor by contract; null clears [update] Used by: create, update.
`shared_responsibility_note`	No	Who is responsible for what between us and the vendor [create] \| Who is responsible for what between us and the vendor; null clears [update] Used by: create, update.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.1.0Nov 5, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds real behavioral context: an editor+ role gate on all operations, that research and assess are async, and that assess supersedes the deprecated DPSIA trigger. It stops short of noting that update is a partial/patch-style mutation or what the queued jobs entail, which the schema covers instead.

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?

A single front-loaded sentence with no wasted words, listing operations before mechanics. It is arguably over-compressed for a four-in-one tool with 18 parameters, but nothing is padding.

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 an 18-parameter, four-method multiplexed write tool with no output schema, the description is thin — it omits how method-specific requirements interact (vendor_id for update/research/assess, name for create) and relies entirely on schema text. The key facts an agent needs (role requirement, async behavior, polling siblings) are present, so it is minimally sufficient rather than complete.

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 every parameter including per-method applicability via 'Used by:' tags, which sets the baseline at 3. The description adds only 'Pick with method' and the async hint; it contributes no additional meaning about the 18 parameters.

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 names the resource (vendors) and enumerates the four concrete operations — create, update, AI research, DPSIA assessment — so an agent immediately knows what the tool does. It falls short of a 5 because it gives no differentiation from the closely-named sibling scf_vendor_record_write, leaving overlap ambiguous.

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' identifies the discriminator but gives no when-to-use guidance between the four operations, and no exclusions relative to scf_vendor_read or scf_vendor_record_write. The per-method context (async, polling targets) lives in the method enum's schema description rather than in the tool description, so usage is only implied here.

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

scf_vendor_write

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools