Skip to main content
Glama
Sign In
MCP Server for OSCAL

MCP Server for OSCAL

by dfkunstler
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_catalog_controls

Lists controls in loaded OSCAL Catalogs with token ID, title, and parent document, using paging to locate controls before retrieving their OSCAL JSON.

Instructions

List controls in loaded OSCAL Catalogs with token ID (e.g. ac-1), title, and parent document. Get a control's OSCAL JSON with get_child_element. 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": "list_catalog_controls"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum items per page, 1-100.
offsetNoZero-based index of the first item.
parent_doc_uuidNoUUID of one parent document to scope results to. Omit for all documents.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.7.1
    • 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 / parent_doc_uuid / description
      Added value: +"UUID of one parent document to scope results to. Omit for all documents."
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses paging ('Results are paged') and the summary fields returned, but does not explicitly state read-only behavior or empty-result handling.

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 with zero waste, front-loading the purpose before the alternative and paging note. Every clause earns its place.

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?

With no output schema, the description lists the summary fields returned and notes paging, while the schema fully covers all three parameters. It lacks deeper context about catalog loading or scoping behavior, but is complete enough for a paged list tool.

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%, so limit, offset, and parent_doc_uuid are fully documented in the input schema. The description adds no parameter-specific meaning beyond that schema baseline.

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?

The description states a specific verb ('List controls') and resource ('loaded OSCAL Catalogs') and names the summary fields returned (token ID, title, parent document). It distinguishes from get_child_element for full JSON, but does not differentiate from siblings like query_catalog or list_catalog_groups.

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?

It explicitly names get_child_element as the alternative when a control's full OSCAL JSON is needed. There is no when-not guidance or comparison to query_catalog, but the intended context is clear.

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