vcf-ops-mpb-mcp

Export design to a JSON file

mpb_export_design

Read-only

Exports a valid design in MPB exchange format, removes credential values, and writes a git-friendly JSON file for design-as-code; relative paths resolve under MPB_DESIGNS_DIR.

Instructions

Exports a VALID design in MPB exchange format, removes credential values, and writes it to a file (design as code, git-friendly). Relative paths resolve under MPB_DESIGNS_DIR.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "designId": "<designId>"
    },
    "name": "mpb_export_design"
  }
}

Input Schema

Name	Required	Description	Default
`designId`	Yes	MPB design UUID (see mpb_list_designs)
`outputPath`	No	File to write. Default: <MPB_DESIGNS_DIR>/<name>-<version>.json

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 15, 2026

TDQS

A3.7/5.0

Behavior3/5

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

The description adds genuinely useful behavior beyond the annotations: credential values are stripped before writing, the output is git-friendly code, and relative paths resolve under MPB_DESIGNS_DIR. However, it writes a file to disk while annotations declare readOnlyHint=true, and the description never clarifies that read-only applies to the MPB service rather than the local filesystem, leaving a real ambiguity for an agent deciding whether the call has side effects.

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?

Two tight sentences plus a parenthetical; the core action and its constraints are front-loaded, and the path-resolution rule, which is easy to miss, is stated last without padding. No sentence is redundant with the title or schema.

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 two-parameter export tool with full schema coverage and annotations, this covers format, redaction, and path semantics well enough to call correctly. Because there is no output schema, it could still say what the call returns (the written path, a count of stripped credentials) or how failures like an invalid design or unwritable directory surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the baseline is 3, but the description adds meaning the schema does not: the relative-path resolution rule against MPB_DESIGNS_DIR for outputPath. The designId side is left entirely to the schema, which already points to mpb_list_designs, so nothing is missing.

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 a specific verb+resource ("Exports a VALID design") plus the output artifact and format ("MPB exchange format ... writes it to a file"), which clearly separates it from mpb_import_design by direction. It stops short of naming a sibling explicitly, so an agent must infer the import/export pairing from the opposites in the names.

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?

Usage is only implied: the capitalized "VALID" signals the design must exist and be valid first, and a sibling (mpb_verify_design) exists but is never referenced. There is no statement of when to prefer this over mpb_get_design (programmatic read) or what to do when validation fails.

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