Skip to main content
Glama
rhyne1012

OpenVSP MCP (Maintained Fork)

by rhyne1012
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

openvsp.inspect

Read-only

Read component IDs, wing names, and summary directly from .vsp3 XML files without launching OpenVSP. Inspect geometry metadata quickly and safely, with invalid XML failing gracefully.

Instructions

Read component IDs, wing names and a component summary directly from .vsp3 XML. Does not launch OpenVSP, write files or modify the source; unreadable or invalid XML fails. Use openvsp.query for native parameter values or analysis defaults.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYesModel file to inspect as XML.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
geom_idsYesComponent IDs found in Vehicle/Geom XML entries, in file order.
info_logYesNewline-separated component summaries in ID:name:type form; no solver log.
wing_namesNoNames of components whose XML type is Wing; empty when none exist.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.7.0
    • changedInput schema / $defs / OpenVSPGeometryRequest / properties / geometry_file / description
      Previous value: -"Path to the .vsp3 file"New value: +"Path to an existing .vsp3 file, read as XML without native processes. Tilde expands; relative paths use the server working directory."
    • addedInput schema / properties / request / description
      Added value: +"Model file to inspect as XML."
    • addedOutput schema / properties / geom_ids / description
      Added value: +"Component IDs found in Vehicle/Geom XML entries, in file order."
    • addedOutput schema / properties / info_log / description
      Added value: +"Newline-separated component summaries in ID:name:type form; no solver log."
    • addedOutput schema / properties / wing_names / description
      Added value: +"Names of components whose XML type is Wing; empty when none exist."
  2. First observedv0.6.0

TDQS

A4.7/5.0
Behavior5/5

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

The description adds meaningful behavioral detail beyond the readOnlyHint annotation: it does not launch OpenVSP, write files, or modify source, and it fails on unreadable or invalid XML. This clarifies side effects and error behavior in a way annotations alone do not, and it is consistent with the readOnlyHint=true annotation.

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?

The description is three sentences, front-loaded with the primary purpose, and every sentence earns its place: what it reads, what it avoids doing, how it fails, and when to use an alternative. There is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with an output schema, the description covers the input file handling, the non-mutating behavior, error conditions, and the appropriate alternative tool. The presence of an output schema removes the need to enumerate return fields in the description. Nothing essential is missing for correct invocation.

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 the single parameter 'geometry_file' is already well-described in the schema with path semantics and tilde expansion. The tool description adds context about reading the file as XML and the kind of data extracted, but does not significantly enhance parameter-level meaning beyond what the schema already provides.

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?

The description identifies a specific verb ('Read'), a specific resource ('.vsp3 XML'), and the exact data returned (component IDs, wing names, component summary). It also explicitly distinguishes itself from openvsp.query by noting that query provides native parameter values or analysis defaults, making sibling differentiation clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool: to read component and wing data directly from XML without launching OpenVSP. It also provides an explicit when-not by directing users to openvsp.query for native parameter values or analysis defaults, giving clear guidance on choosing between these tools.

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