Trestle MCP

Official

Overview Schema Source Related Servers Discussions Admin

Convert FedRAMP XLSX to OSCAL POA&M

trestle_task_xlsx_to_oscal_poam

Converts FedRAMP XLSX spreadsheets to OSCAL POA&M JSON, parsing required columns and auto-generating linked observations and risks with deterministic UUIDs.

Instructions

Convert a FedRAMP XLSX spreadsheet to an OSCAL POA&M JSON file.

This tool runs the trestle task xlsx-to-oscal-poam command, which reads a FedRAMP-format .xlsx spreadsheet and produces an OSCAL plan-of-action-and-milestones .json file. The converter auto-generates the observations[] and risks[] and cross-links each poam-item to them with deterministic UUIDs.

This command must run inside a trestle workspace: initialize one first with trestle_init and pass its path as trestle_root (or run from within it).

The spreadsheet must have:

Row 1: title
Rows 2-4: instructions (ignored)
Row 5: column headers
Row 6+: data rows

Required columns:

POAM ID, Weakness Name, Weakness Description, Controls

Args: params (TrestleTaskXlsxToOscalPoamInput): Input parameters with: - title (str): POA&M title (required) - version (str): POA&M version (required) - xlsx_file (str): Path to the input .xlsx file (required) - output_dir (str): Output directory for the OSCAL JSON (required) - work_sheet_name (Optional[str]): Worksheet name (default: 'Open POA&M Items') - system_id (Optional[str]): System identifier (optional) - output_overwrite (bool): Overwrite existing output (default: true) - validate_required_fields (str): Required-field check: on/warn/off (default: warn) - quiet (bool): Suppress per-item output (default: false) - trestle_root (Optional[str]): Trestle workspace root path (optional) - verbose (bool): Display verbose output (optional)

Returns: str: Success or error message with output file location

Examples: - Use when: "Convert this FedRAMP POA&M spreadsheet to OSCAL" - Use when: "Generate plan-of-action-and-milestones.json from an xlsx" - Don't use when: The input is a CSV, or is missing required columns

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.1Aug 26, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations provide no helpful behavior hints (all false), so the description carries the full burden. It discloses that the task produces a JSON file, auto-generates observations[] and risks[] with deterministic UUIDs, may overwrite existing output via output_overwrite, and requires a trestle workspace. It also explains the spreadsheet row layout and required columns, which are critical behavioral inputs. No contradiction with annotations is present.

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?

The description is long, but the tool is complex and every section earns its place: summary, workspace prerequisite, spreadsheet format, required columns, parameter list, return value, and concrete usage examples. It is front-loaded with the one-line purpose, and the structure makes it easy for an agent to extract the key constraints quickly.

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?

For a conversion task with a complex input format, the description is complete: it covers the input file structure, required columns, workspace setup, output location semantics, validation behavior, and exclusion cases. The presence of an output schema slightly reduces the burden for return-value details, but the description still provides a Returns summary. An agent has everything needed to decide whether and how to invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It enumerates every parameter with its type, default, and whether it is required, including nuanced ones like validate_required_fields ('on/warn/off') and work_sheet_name ('Open POA&M Items'). It also adds meaning to xlsx_file by describing the exact spreadsheet layout and required columns that the schema only briefly touches on.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource+result statement: 'Convert a FedRAMP XLSX spreadsheet to an OSCAL POA&M JSON file.' It names the exact input format, the output format, and the underlying command, making the tool's purpose unmistakable. The sibling-differentiating details are present through the explicit 'Don't use when: The input is a CSV' exclusion, which separates it from CSV-oriented sibling tools.

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?

The description gives explicit when-to-use examples ('Convert this FedRAMP POA&M spreadsheet to OSCAL') and when-not-to-use conditions ('Don't use when: The input is a CSV, or is missing required columns'). It also states the prerequisite: the command must run inside a trestle workspace initialized with trestle_init. This gives an agent clear decision criteria and environmental setup guidance.

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

Deploy Server