MCP Server for OSCAL

Overview Schema Source Related Servers Discussions Admin

query_component_definition

Retrieve OSCAL Components or a matching Capability from loaded Component Definitions by UUID, title, or type, with optional Component Definition filtering and paged JSON results.

Instructions

Return OSCAL Components from loaded Component Definitions as OSCAL JSON, or one Capability when a by_uuid or by_title query matches a Capability. Use when you need component details: call it directly with by_title or by_type when you know the name or type, else find UUIDs and titles first with list_components; use list_capabilities or get_capability only for Component Definitions that contain capabilities. Results are paged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "query_component_definition"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum items per page, 1-100.
`offset`	No	Zero-based index of the first item.
`query_type`	No	"all" (paged, large without a filter), "by_uuid", "by_title" (title, then property value), or "by_type" (Component type). by_uuid and by_title return a matching Capability first.	all
`query_value`	No	UUID, title, or Component type to match. Required unless query_type is "all".
`return_format`	No	Response format. Only "raw" (OSCAL JSON) is supported.	raw
`component_definition_filter`	No	UUID or exact title (case-insensitive) of one Component Definition to search. Omit to search all.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.7.1Oct 26, 2026

addedInput schema / properties / component_definition_filter / description

Added value: +"UUID or exact title (case-insensitive) of one Component Definition to search. Omit to search all."

addedInput schema / properties / limit / description
```
Added value: +"Maximum items per page, 1-100."
```

addedInput schema / properties / offset / description

Added value: +"Zero-based index of the first item."

addedInput schema / properties / query_type / description

Added value: +"\"all\" (paged, large without a filter), \"by_uuid\", \"by_title\" (title, then property value), or \"by_type\" (Component type). by_uuid and by_title return a matching Capability first."

addedInput schema / properties / query_value / description

Added value: +"UUID, title, or Component type to match. Required unless query_type is \"all\"."

addedInput schema / properties / return_format / description

Added value: +"Response format. Only \"raw\" (OSCAL JSON) is supported."

First observedv0.1.0Sep 30, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that results are paged, that by_uuid/by_title return a matching Capability first (a non-obvious behavior), and that unfiltered 'all' queries are large. It omits permission/scope caveats, but as a read-only query tool that is a minor gap.

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?

Front-loads the return shape, then the routing rules, then paging. It is dense and slightly run-on across the Capability clause, but every sentence carries actionable information with no filler.

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?

An output schema exists and parameter coverage is full, so the description only needs to cover routing and paging, which it does. The remaining ambiguity is how Component vs Capability results are distinguished in one response, but that is largely a return-shape concern handled by the output schema.

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 coverage is 100%, so every parameter including the query_type enum is already documented in the schema. The description reinforces the by_title/by_uuid Capability behavior and the 'else find UUIDs first' workflow, but adds little parameter detail beyond what structured fields provide, 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: returns OSCAL Components from Component Definitions as OSCAL JSON, plus the Capability special case. It implicitly differentiates from list_components and get_capability by naming them, though the dual return type (Components OR a Capability) makes the core purpose slightly harder to grasp at first read.

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 explicit routing: call directly with by_title or by_type when you know the name or type, otherwise find UUIDs and titles first via list_components. It also names the alternatives list_capabilities and get_capability and the condition (definitions containing capabilities) that selects them.

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

Deploy Server