Trestle MCP

Official

by oscal-compass

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation5/5
Each tool has a clear, distinct purpose: workspace init, model import, catalog/profile generation, profile assembly/resolution, and CSV conversion. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'trestle_' prefix with snake_case verb_noun or verb_preposition patterns. Subgroups like 'trestle_author_*' are uniform.
Tool Count5/5
7 tools cover a well-scoped domain of OSCAL model management. The count is neither too few nor too many given the specific focus.
Completeness4/5
Core workflows for catalog and profile authoring are well-covered, but missing tools for catalog assembly, component definition generation, or SSP handling create minor gaps.
Average 4.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the resolution process (resolves to a catalog), mentions output formatting options, and specifies the file path convention ('profiles/<name>/profile.json'). The return type and error behavior are described. Annotations indicate no destructiveness or idempotency, which is consistent. Some behavioral details like file creation are implied but not explicit.
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?
The description is well-structured with a clear purpose statement, a detailed parameter list, and an examples section. It is front-loaded with the main action, but the parameter list is somewhat lengthy and could be more concise without losing clarity.
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?
The description covers the main purpose, parameters, return value, and an example. It mentions the file path convention and optional parameters. However, it does not explain prerequisites (e.g., existence of the profile) or the effect of 'trestle_root', leaving some gaps for a complete context.
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?
The input schema has detailed descriptions for each parameter, and the tool description repeats this information in the Args section with added context like default values and examples. However, the repetition does not significantly add meaning beyond the schema, resulting in a baseline score of 3.
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 clearly states the action 'resolve' and the resource 'OSCAL profile to catalog', matching the title. It specifies the operation and distinguishes from sibling tools like 'trestle_author_profile_generate' or 'trestle_author_profile_assemble'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool over alternatives. No comparisons or explicit conditions are given, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool writes markdown files and can overwrite them via force_overwrite. This aligns with annotations (non-read-only, non-destructive, but overwrite is noted). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long with code blocks and redundant parameter listings. It could be more concise by omitting the duplicate parameter details.
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?
Given the complexity (7 parameters, nested object), the description covers the main functionality, parameters, return, and usage examples. It does not explain the output schema but that is not required. It is fairly complete.
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?
The schema already describes all parameters, and the description's 'Args' section largely duplicates that information without adding significant new meaning. The descriptions are similar, so minimal added value.
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 clearly states the tool generates catalog controls in markdown form, with a specific verb and resource. Sibling tools are all different (profile operations, import, init), so no confusion.
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?
The description includes explicit 'Use when' and 'Don't use when' examples, providing clear usage contexts. However, it does not directly reference sibling tools as alternatives, so it is not perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=false and destructiveHint=false, so no contradiction. Description explains it produces an output file and returns success/error message, but does not detail potential side effects or permissions beyond file creation.
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?
Well-structured with bullet points and examples, but could be slightly more concise. No redundant sentences.
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?
Comprehensively covers the tool's purpose, input requirements, output, and examples. With an output schema present, no need to describe return values in detail.
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?
The input schema has detailed descriptions for each parameter, so the description adds moderate value by explaining the required CSV columns and overall workflow. Schema coverage is effectively high, so baseline applies.
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 clearly states the tool converts CSV to OSCAL component definition JSON. It specifies the command and the CSV format, distinguishing it from sibling trestle tools which handle catalog, profile, import, and init tasks.
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?
Includes explicit 'Use when' and 'Don't use when' examples, providing context for appropriate usage. Does not explicitly compare to sibling tools, but the task is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (writes), destructiveHint=false (non-destructive), and idempotentHint=false. The description adds that the tool writes a profile.json file and returns a success/error string. While it doesn't detail permissions or exact side effects, it aligns with annotations and provides basic behavioral context. The openWorldHint=true suggests no external dependencies are hidden, but the description lacks explicit statements about file system impact or required environment setup.
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?
The description is well-structured with headings (purpose, args, returns, examples) and bullet points, making it easy to scan. It front-loads the core purpose. However, it is somewhat verbose; the 'Args' section could be more concise since the schema already describes parameters. The examples are helpful but repeated phrases ('Use when') could be trimmed. Overall, it is efficient for a complex tool with many parameters.
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?
The description covers the tool's purpose, all parameters with descriptions, return value, and usage examples including contraindications. It does not explain the output file structure (e.g., profile.json contents) beyond being a JSON, but the output schema is marked as present. Given the complexity (1 complex param with many sub-params), the description is complete enough for an agent to invoke correctly. Missing details like required trestle root setup or dependency on trestle_init are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although context signals report 0% schema description coverage (likely due to the top-level 'params' object lacking a description), the provided schema includes descriptions for each sub-property in the $defs. The description's 'Args' section reiterates all parameters with concise explanations and includes formatting hints (e.g., comma-separated for sections). This adds meaning beyond the schema, especially for optional parameters with defaults (e.g., set_parameters, regenerate). A slight deduction for not explaining the meaning of 'sections' in more detail.
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 clearly states the tool assembles markdown controls into an OSCAL Profile JSON file. It specifies the verb 'assemble' and the resource 'Profile JSON from Markdown Directory', distinguishing it from siblings like profile_generate (which likely generates markdown from profile) and profile_resolve (which resolves profiles). The title and first sentence are unambiguous.
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?
The description includes explicit 'Use when' and 'Don't use when' examples, providing clear guidance on appropriate contexts (e.g., CI/CD assembly, parameter expansion) and contraindications (missing or malformed markdown). However, it does not directly compare to sibling tools like trestle_author_profile_generate or trestle_author_profile_resolve, which would further clarify when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse but the description adds significant behavioral context: file saving paths per OSCAL type, argument details, and return type. No contradiction with annotations. Describes the import process well.
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?
The description is well-structured with sections, front-loaded purpose, and examples. It is somewhat lengthy but each sentence adds value. Could be slightly more concise.
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?
Given the tool's complexity (one compound parameter with five sub-parameters) and the presence of an output schema, the description covers input format, output, and examples. It is sufficiently complete for an agent to use correctly.
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 0% per context signal, so the description must compensate. It lists all parameters with brief explanations but does not add much beyond the schema's own descriptions. Adequate but not exceptional.
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 explicitly states 'Import an existing OSCAL model into the trestle workspace' and details the types of OSCAL models it handles. It distinguishes itself from sibling tools (generation, assembly, resolution, initialization, CSV conversion) by being the import tool.
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?
The description provides clear guidance on when to use the tool (importing OSCAL models from URLs or local files) and includes examples. It does not explicitly state when not to use it or alternatives, but the sibling tool list implies the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses file generation behavior and overwrite options, complementing annotations. Annotations already indicate non-read-only and open-world behavior, and the description adds context about creation and overwriting.
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?
Description is front-loaded with purpose, followed by structured parameter list and examples. Slightly verbose but well-organized and efficient.
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?
Covers input, output (returns string), and usage examples. Lacks some details on default behaviors and output format, but adequate given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema provides descriptions for each property (0% top-level coverage), the tool description lists and explains each parameter, adding clarity on their roles and defaults.
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 clearly states 'Generate markdown documentation set for controls defined in specified profile' with specific verb and resource. It distinguishes from siblings like trestle_author_catalog_generate by focusing on profile controls.
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?
Provides explicit use cases ('Use when: ...') and a negative case ('Don't use when: Profile file does not exist'). However, it does not differentiate from sibling tools like trestle_author_catalog_generate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent behavior, which the description does not contradict. The description adds context about creating directory structure and available modes, going beyond what annotations provide. No mention of side effects, but idempotent implies safety.
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?
Well-structured with a clear purpose, list of supported models, args section, returns, and examples. Front-loaded with main action, each sentence adds value without redundancy.
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?
Comprehensive for a initialization tool: covers purpose, modes, return type, and usage examples. Output schema reduces need for extensive return descriptions; the provided 'Success message or error details' is adequate.
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?
The input schema already provides descriptions for all parameters (mode, trestle_root, verbose). The description adds no new parameter-level details beyond listing them generically, so it does not significantly improve understanding beyond the schema.
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 clearly states the verb 'initialize' and the resource 'trestle working directory'. It lists supported OSCAL model types, distinguishing it from sibling tools like trestle_import or trestle_task_* which have different purposes.
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?
Includes 'Use when' and 'Don't use when' examples, providing clear guidance on appropriate contexts. Does not explicitly mention sibling tools as alternatives, but the 'Don't use when workspace is already initialized' is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![compliance-trestle-mcp MCP server](https://glama.ai/mcp/servers/oscal-compass/compliance-trestle-mcp/badges/card.svg)](https://glama.ai/mcp/servers/oscal-compass/compliance-trestle-mcp)

Score Badge

Copy to your README.md:

[![compliance-trestle-mcp MCP server](https://glama.ai/mcp/servers/oscal-compass/compliance-trestle-mcp/badges/score.svg)](https://glama.ai/mcp/servers/oscal-compass/compliance-trestle-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/oscal-compass/compliance-trestle-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server