vcf-ops-mpb-mcp

Test the design source connection

mpb_test_source

Runs an MPB source connectivity test on a collector and saves the response to the source by default so the design can become VALID.

Instructions

Runs the MPB source test on a collector (GET_SESSION when session auth is configured, then TEST_CONNECTION) and, by default, saves the test response into the source, which MPB requires before the design can become VALID.

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_test_source"
  }
}

Input Schema

Name	Required	Description
`persist`	No	Write the test response back into the source (default true)
`designId`	Yes	MPB design UUID (see mpb_list_designs)
`collectorId`	No	Collector uuId; default = first UP collector
`credentials`	No	Credential values by label, e.g. {"username":"x","password":"y"}. Never stored by this server.
`trustedCertificates`	No	Extra PEM certificates to trust for this test

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, but the description explains why: by default the test response is written back into the source, and persist can disable that. It also discloses the conditional GET_SESSION auth handshake, which is real behavior an agent would otherwise not anticipate. No mention of failure modes or timeout behavior.

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 dense sentence with the action, the handshake, and the default side effect front-loaded; nothing is filler. The nested parenthetical makes it slightly harder to parse than a two-sentence split would be.

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?

Covers what the tool does, the auth path, and its side effect for a 5-parameter tool with a nested credentials object and no output schema. The return value of the test is left implicit, which is the main remaining gap.

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?

Schema coverage is 100%, so baseline is 3, and the description adds rationale rather than restating fields: persist's default write-back is explained as a requirement for the design to become VALID, and credentials are implicitly tied to session auth. collectorId and trustedCertificates get no extra treatment.

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 and resource ("Runs the MPB source test on a collector") and describes the actual sequence (GET_SESSION when session auth is configured, then TEST_CONNECTION). This is clearly distinguishable from the sibling mpb_test_regex and from the get/set source tools.

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 the key motivating context: this is the step MPB requires before a design can become VALID, so an agent knows when it is needed. It stops short of naming alternatives or stating when not to use it.

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