Skip to main content
Glama

query_poam

Retrieve OSCAL Plans of Action and Milestones with metadata and child type counts for compliance tracking. Use this to query POA&M records by UUID, title, or list all.

Instructions

Return loaded OSCAL Plans of Action and Milestones with metadata and childTypeCounts. For POA&M items, use list_poam_items, 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_poam"
  }
}

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.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 safety burden; "Return" implies read-only behavior, and it names `metadata` and `childTypeCounts` as returned content. It does not disclose permissions, rate limits, error behavior, or the full return structure.

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 efficient sentences with the return purpose front-loaded and the item-level alternative immediately following. There is no wasted text.

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?

For a query tool with a fully documented input schema and no output schema, the description gives the essential return concept and item-level routing. It is largely complete, though it could say more about the returned document shape and its relationship to `list_poams`.

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 all four parameters including the `query_type` enum are documented in the schema. The description adds no parameter-level semantics beyond what the schema already provides, so baseline 3 is appropriate.

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 loaded OSCAL Plans of Action and Milestones with metadata and `childTypeCounts`. It also distinguishes item-level access by pointing to `list_poam_items` and `get_child_element`, though it does not explain when to use this versus sibling `list_poams`.

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?

Explicitly routes POA&M item lookups to `list_poam_items` and then `get_child_element`, giving a clear alternative for item-level use. However, it does not clarify when to choose `query_poam` over `list_poams` or other POA&M-related siblings.

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