Skip to main content
Glama
Sign In
MCP Server for OSCAL

MCP Server for OSCAL

by dfkunstler
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

validate_oscal_content

Validates OSCAL JSON documents and returns per-level results for syntax, JSON Schema, OSCAL model, and oscal-cli checks, skipping deeper checks when parsing fails.

Instructions

Validate OSCAL JSON text and return per-level results for JSON syntax, JSON Schema, the OSCAL model, and oscal-cli (skipped when not installed). Later levels are skipped when the JSON does not parse.

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": {
      "content": "<content>"
    },
    "name": "validate_oscal_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
contentYesOSCAL JSON document as a string.
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 / content / description
      Added value: +"OSCAL JSON document as a string."
    • 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

A3.7/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 does well: it names the four validation levels and, importantly, discloses the cascade rule that later levels are skipped when JSON fails to parse, and that oscal-cli is skipped when not installed. The remaining gap is that the shape of 'per-level results' is never described, which matters since there is no output schema.

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 dense sentences, front-loaded with the verb and resource, followed immediately by the behavioral cascade rule. No filler and nothing repeated from the schema.

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

Completeness3/5

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

For a 2-parameter read tool with no annotations or output schema, the description explains the validation pipeline well but omits two things an agent needs: how this differs from validate_oscal_file, and roughly what a per-level result looks like (status fields, error reporting). Adequate but incomplete.

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 are documented in-schema, including model_type's example and the note that it can be omitted for auto-detection. The description adds no parameter detail beyond restating that the input is OSCAL JSON text, so baseline 3 applies.

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?

States a specific verb and resource: validate OSCAL JSON text, and enumerates the four validation levels performed. It does not differentiate itself from the sibling validate_oscal_file, leaving the agent to infer that this tool takes a string rather than a path.

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 required 'content' string parameter suggests this is the in-memory counterpart to validate_oscal_file, but the description never states when to choose this over the file-based sibling or mention prerequisites. No explicit when-not guidance is given.

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