Skip to main content
Glama

ClevSec EU compliance tools

Vendor due diligence plan and contract clauses (ClevSec Pro)

vendor_due_diligence_plan
Read-onlyIdempotent

Use after vendor_risk_assessment when the user needs to act on a vendor's gaps. Returns every gap with an action, the evidence to request from the vendor, ISO 27001 / GDPR / NIS2 / DORA references and a roadmap (before signing first), plus the contract clauses to include (GDPR Art. 28, NIS2 Art. 21, DORA Art. 30 when they apply). Requires ClevSec Pro.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "vendor_due_diligence_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
bcp1NoDoes the vendor have a business continuity / disaster recovery plan?
bcp2NoDoes the vendor offer a defined SLA with uptime guarantees?
bcp3NoCan data be exported/migrated if you terminate the relationship?
bcp4NoDoes the vendor have geographic redundancy for critical services?
bcp5NoIs the vendor financially stable (no signs of distress)?
com1NoIs the vendor compliant with GDPR (if processing EU personal data)?
com2NoWill the vendor sign a Data Processing Agreement?
com3NoDoes the vendor provide right-to-audit or access to audit reports?
com4NoDoes the vendor's contract include security requirements and SLAs?
com5NoDoes the vendor have adequate insurance coverage (cyber liability)?
inc1NoDoes the vendor have a documented incident response plan?
inc2NoWill the vendor notify you of security incidents within 24-48 hours?
inc3NoHas the vendor experienced any data breaches in the last 3 years?
inc4NoDoes the vendor conduct incident response exercises/tabletop tests?
sec1NoDoes the vendor hold relevant security certifications (ISO 27001, SOC 2, etc.)?
sec2NoDoes the vendor have a documented information security policy?
sec3NoDoes the vendor encrypt data at rest and in transit?
sec4NoDoes the vendor enforce multi-factor authentication?
sec5NoDoes the vendor conduct regular penetration testing?
sec6NoDoes the vendor have a vulnerability management program?
sec7NoDoes the vendor perform background checks on employees with data access?
sup1NoDoes the vendor disclose its key subprocessors/subcontractors?
sup2NoWill the vendor notify you before changing subprocessors?
sup3NoDoes the vendor assess the security of its own suppliers?
sup4NoAre subprocessor contracts held to the same security standards?
regimesNoWhich of these apply to your organization? (optional)
dataAccessNoWhat data will this vendor access?
vendorTypeNoType of service
criticalityNoHow critical is this vendor to your operations?

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, lowering the bar. The description adds genuinely useful context beyond that: it enumerates the return structure and discloses an entitlement requirement ("Requires ClevSec Pro"), which the annotations do not express. It does not, however, describe pagination or output format for a 29-parameter tool.

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?

Three sentences, front-loaded with the usage precondition before the payload description, and every clause carries information. Slightly dense in the middle sentence listing references and verdicts, but no filler or repetition 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 read-only tool with no output schema, the description does the heavy lifting by enumerating what is returned (gaps, actions, evidence requests, references, roadmap, contract clauses) and its prerequisite tool. The one omission is that it never tells the agent it must supply the vendor's checklist answers (the 29 params drawn from vendor_risk_assessment) as input, which is implied but not stated.

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 every parameter carries an inline enum description, so the schema fully documents inputs. The description names the regimes it maps to (GDPR Art. 28, NIS2 Art. 21, DORA Art. 30) which loosely ties to the regimes parameter, but adds no syntax or value-level guidance. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (produces a due-diligence/remediation plan from vendor gaps) and explicitly frames it as the follow-on to vendor_risk_assessment. The listed outputs (gaps with actions, evidence to request, standard references, roadmap, contract clauses) make it unmistakable versus other sibling plan tools like dora_remediation_plan or nis2_remediation_plan.

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?

"Use after vendor_risk_assessment when the user needs to act on a vendor's gaps" gives both the sequencing precondition and the triggering condition, and names the sibling alternative. It stops short of stating when NOT to use it (e.g. before an assessment exists is only implied by "after"), but the context is clear enough for selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources