Skip to main content
Glama
Sign In
MCP Server for OSCAL

MCP Server for OSCAL

by dfkunstler
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

validate_oscal_file

Validate an OSCAL JSON file against syntax, JSON Schema, model rules, and oscal-cli, returning results per validation level. Use it when your OSCAL document is stored in a file.

Instructions

Validate an OSCAL JSON file and return per-level results for JSON syntax, JSON Schema, the OSCAL model, and oscal-cli (skipped when not installed). Use when the document is in a file; for JSON text use validate_oscal_content.

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": {
      "file_uri": "<file_uri>"
    },
    "name": "validate_oscal_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
file_uriYesPath or URI of an OSCAL JSON file. Remote URIs are rejected unless the server operator enables remote URIs.
model_typeNoOSCAL model name from list_oscal_models, e.g. "catalog". Omit to detect it from the document's root key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.1
    • addedInput schema / properties / file_uri / description
      Added value: +"Path or URI of an OSCAL JSON file. Remote URIs are rejected unless the server operator enables remote URIs."
    • addedInput schema / properties / model_type / description
      Added value: +"OSCAL model name from list_oscal_models, e.g. \"catalog\". Omit to detect it from the document's root key."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations the description carries the full burden, and it does disclose meaningful behavior: the tool returns per-level results (not a single pass/fail) and the oscal-cli level is conditionally skipped when not installed, which prevents misreading a partial result set. It stops short of saying how an invalid document is surfaced (error vs. results payload), which is the one behavioral detail an agent would still want.

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 sentences, zero waste. The validation scope is front-loaded and the alternative-tool routing is placed at the end where it belongs.

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?

There is no output schema, but the description compensates by naming the returned per-level structure and the conditional skip. For a read-only two-parameter validator that is nearly complete; only the failure/error reporting path is unaddressed.

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 both parameters already document themselves — including the remote-URI rejection rule and that model_type is auto-detected when omitted. The description adds nothing parameter-specific, so the baseline 3 applies.

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 (validate an OSCAL JSON file) and enumerates exactly what validation levels are run: JSON syntax, JSON Schema, OSCAL model, and oscal-cli. It also explicitly names the sibling it is not (validate_oscal_content) so the agent can distinguish the two without opening either schema.

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?

Gives an explicit selection rule: use this when the document is in a file, use validate_oscal_content when it is JSON text. That is a direct when/when-not/alternative statement with no inference required.

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