Skip to main content
Glama
Sign In
MCP Server for OSCAL

MCP Server for OSCAL

by dfkunstler
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

query_assessment_plan

Retrieve loaded OSCAL Assessment Plans with childTypeCounts; page results or filter by UUID/title, then use linked child tools to list tasks and activities.

Instructions

Return loaded OSCAL Assessment Plans with childTypeCounts. For child elements, use list_assessment_plan_tasks or list_assessment_plan_activities, then get_child_element.

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_assessment_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum items per page, 1-100.
offsetNoZero-based index of the first item.
query_typeNo"all" (paged), "by_uuid", or "by_title" (exact, then full-text).all
query_valueNoUUID or title to match. Required for by_uuid and by_title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 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 / query_type / description
      Added value: +"\"all\" (paged), \"by_uuid\", or \"by_title\" (exact, then full-text)."
    • changedInput schema / properties / query_type / enum
      Previous value: -[
-  "all",
-  "by_uuid",
-  "by_title",
-  "by_type"
-]New value: +[
+  "all",
+  "by_uuid",
+  "by_title"
+]
    • addedInput schema / properties / query_value / description
      Added value: +"UUID or title to match. Required for by_uuid and by_title."
  2. First observedv0.1.0

TDQS

A3.6/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 safety-profile burden. 'Return' and 'loaded' imply a read-only operation over already-ingested documents, but the description never confirms read-only semantics, says whether an unloaded document yields empty results or an error, or describes result ordering. It is adequate but thin for a zero-annotation tool.

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?

Two tight sentences with the resource named up front and the child-element escape hatch second. No waste, though the mid-sentence line break and the unexplained `childTypeCounts` token slightly blunt the front-loading.

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?

Wait — scoring independently: there is no output schema, and the description does name the returned field childTypeCounts, which helps an agent interpret output. Combined with the explicit child-element routing, an agent has enough to call it correctly; the only gap is the loaded-document prerequisite, which is why this sits at 4 rather than 5.

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, query_type and query_value are all documented in the schema itself. The description adds no meaning beyond that — notably it never explains that query_type='by_title' does exact match then full-text fallback. Baseline 3 is correct.

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: return loaded OSCAL Assessment Plans along with childTypeCounts. It also names the sibling tools used to reach child elements. It stops short of distinguishing itself from the sibling list_assessment_plans, and never mentions the by_uuid/by_title filtering that presumably separates the two.

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?

Gives explicit routing for child elements (use list_assessment_plan_tasks / list_assessment_plan_activities, then get_child_element), which is genuinely useful. However it says nothing about when to pick this over list_assessment_plans or query_assessment_results, and no prerequisites (e.g. a document must already be loaded) are stated.

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