NIST 800-171 controls and 800-171A objectives, crosswalks, exact SPRS scoring, POA&M generation.
Average 4.4/5 across 8 of 8 tools scored.
Each tool targets a distinct aspect of CMMC/NIST 800-171: scoring, crosswalking, level determination, POA&M generation, assessment objectives, control listing, Level 1 practices, and individual control lookup. There is no meaningful overlap—even list_controls and lookup_control serve different granularities, and calculate_sprs_score uses lookup-style data but performs a distinct computation.
All tool names follow a consistent verb_noun pattern with snake_case: calculate_, crosswalk_, determine_, generate_, get_, list_, list_, lookup_. Verbs clearly indicate the action and nouns indicate the resource, making the API predictable and self-documenting.
With 8 tools, the server is well-scoped for its purpose. Each tool covers a necessary function without redundancy, and the count is comfortably within the 3-15 range that supports a focused domain without overwhelming users.
The tool surface covers the full lifecycle of CMMC/NIST 800-171 compliance: level determination, control enumeration and details, assessment objectives, SPRS scoring, POA&M generation, cross-referencing, and Level 1 practices. There are no obvious dead ends—any typical compliance question can be answered or acted upon using these tools.
calculate_sprs_scoreCalculate an SPRS scoreACompute an exact SPRS score per the DoD Assessment Methodology: start at 110 and subtract each unimplemented requirement's Annex A weight (floor −203). Pass the control numbers that are NOT implemented; optionally pass 3.5.3 and/or 3.13.11 as partially implemented for their sliding-scale values (MFA for privileged/remote only = −3; encryption present but not FIPS-validated = −3). Also reports whether the score clears the 88-point conditional CMMC Level 2 certification threshold and flags a missing SSP (3.12.4), which blocks SPRS submission entirely.
| Name | Required | Description | Default |
|---|---|---|---|
| not_implemented | Yes | Rev 2 control numbers not implemented, e.g. ["3.5.3", "3.11.2"]. An empty array means all 110 implemented (score 110). Rev 3 identifiers are rejected - there is no DoD scoring methodology for Rev 3. | |
| partially_implemented | No | Sliding-scale controls at their partial value: 3.5.3 (MFA for privileged and remote users only) and/or 3.13.11 (encryption employed but not FIPS-validated). Deducts 3 instead of 5. |
| Name | Required | Description |
|---|---|---|
| scale | Yes | |
| deductions | Yes | |
| sprs_score | Yes | The computed score, from 110 down to the -203 floor. |
| missing_ssp | No | Present when 3.12.4 is unimplemented, in which case no score can be submitted to SPRS at all. |
| conditional_note | No | |
| unknown_controls | No | Inputs that matched no requirement - treat as caller error, not as implemented. |
| total_points_deducted | Yes | |
| meets_conditional_level_2_threshold | Yes | Whether the score reaches 88. Clearing it is necessary but not sufficient - every open item must also be POA&M-eligible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the description is free to add behavioral detail. It does so richly: sliding-scale values, the 88-point threshold, SSP-blocking behavior, and the floor of −203. These are not inferable from the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but packed with necessary operational detail. It front-loads the core purpose and then layers on edge cases. Some redundancy exists (e.g., repeating the 3.5.3/3.13.11 values in both description and schema), but overall every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to define the return shape. It fully covers the scoring algorithm, valid inputs, exclusions (Rev 3), threshold logic, and a blocking condition (SSP missing). No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of an empty array ('all 110 implemented') and clarifies that partial controls deduct 3 instead of 5, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Compute an exact SPRS score per the DoD Assessment Methodology'. It immediately distinguishes the tool from siblings like determine_cmmc_level and crosswalk_control by focusing on the SPRS scoring algorithm with exact starting point and floor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit input guidance: 'Pass the control numbers that are NOT implemented' and notes optional partial implementation of specific controls. It also flags that Rev 3 identifiers are rejected. It doesn't name alternative tools, but the context makes the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_contract_type_eligibilityCan you accept this contract type?ADetermine whether a contractor can legally be awarded a given contract type, based on the business systems that type requires. A cost-reimbursement contract may be awarded only if the accounting system is adequate for determining costs (FAR 16.301-3), and T&M billing cannot be substantiated without compliant timekeeping - so this is an eligibility gate, not a preference. Call this before a bid/no-bid, when a solicitation names a contract type, or when someone asks what a pre-award survey will examine. Also returns the SF1408 criteria and the six DFARS business systems whose deficiencies trigger payment withholding after award.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_type | No | The contract type named in the solicitation. Omit to compare all types. | |
| include_sf1408 | No | Include the SF1408 pre-award accounting system survey criteria. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent behavior. The description adds legal context, citing FAR 16.301-3 for cost-reimbursement and timekeeping requirements for T&M, and explains what the tool returns (SF1408 criteria and DFARS business systems). This goes well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: purpose, legal rationale, usage context, return value. Front-loaded with the main verb; each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying key return content (SF1408 criteria, six DFARS business systems). It also covers usage, legal basis, and optionality of parameters. For its complexity, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, including enums and handling of omitted contract_type. The tool description does not add much parameter-level detail beyond reiterating the SF1408 inclusion. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Determine whether a contractor can legally be awarded a given contract type.' It also grounds the purpose in FAR references, distinguishing this from sibling tools about controls/CMMC. The title 'Can you accept this contract type?' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'before a bid/no-bid, when a solicitation names a contract type, or when someone asks what a pre-award survey will examine.' It also clarifies the tool is an 'eligibility gate, not a preference,' preventing misuse. Does not name sibling alternatives, but sibling tools are clearly distinct, so the guidance is complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crosswalk_controlCrosswalk a control across frameworksAMap a security control across frameworks: NIST SP 800-171 Rev 2 ↔ NIST SP 800-53 (FedRAMP Moderate) ↔ NIST CSF 2.0 ↔ SOC 2 Trust Services Criteria. Accepts an 800-171 number ("3.5.3"), an 800-53 id ("AC-2"), a CSF category ("PR.AA" style / "GV.RM"), or a SOC 2 criterion ("CC6"). Call this when the user asks what a control corresponds to in another framework, or how existing FedRAMP/SOC 2/CSF work maps onto CMMC. These are practitioner mappings, not the NIST-published authoritative crosswalk.
| Name | Required | Description | Default |
|---|---|---|---|
| control | Yes | A control id from any supported framework, e.g. "3.1.1", "AC-2", "GV.RM", or "CC6" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior, so the bar is lower. The description adds valuable behavioral context by noting that these are 'practitioner mappings, not the NIST-published authoritative crosswalk,' which sets expectations about the reliability and origin of the mappings. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the first states the core purpose and frameworks, the second lists valid input formats, and the third gives usage context. There is no fluff or redundant information; every sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, input formats, and usage context well. However, since there is no output schema, it does not specify what the tool returns (e.g., the mapped control IDs or full crosswalk details). This is a minor gap, but the tool is simple enough that the return behavior can be inferred from the purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the parameter fully, including examples and supported framework ids. The description repeats similar examples but does not add significant new meaning beyond what the schema already provides. With schema coverage at 100%, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'map' and identifies the resource ('security control') along with the exact frameworks involved (800-171, 800-53, CSF, SOC 2). This clearly distinguishes the tool from sibling tools like lookup_control or list_controls, as it focuses specifically on cross-framework mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool ('when the user asks what a control corresponds to in another framework') and gives an additional concrete use case (mapping existing FedRAMP/SOC 2/CSF work onto CMMC). It does not explicitly mention when not to use it or name alternative tools, but the usage context is clear enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crosswalk_revisionsCompare 800-171 Rev 2 and Rev 3AExplain how NIST SP 800-171 Rev 2 and Rev 3 differ, and what happened to a specific requirement between them. Call this when someone is implementing Rev 3 early, holds a Rev 3 citation and needs the Rev 2 obligation, or asks which revision applies to them. Answers the question DoD guidance forces on early adopters: assessments still run against Rev 2, so Rev 2 gaps must be closed regardless of what has been built to Rev 3.
| Name | Required | Description | Default |
|---|---|---|---|
| requirement | No | Optional: a specific requirement in either scheme, e.g. "3.5.3" (Rev 2) or "03.05.03" (Rev 3). Omit for the structural summary alone. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description goes beyond that by adding domain behavior: assessments still run against Rev 2, so Rev 2 gaps must be closed regardless of Rev 3 implementations. This tells the agent what kind of advice the tool outputs, and 'what happened to a specific requirement' implies the tool reports changes like moved/added/rescinded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that front-load the core purpose, then provide targeted usage scenarios and a policy rationale. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one optional parameter and no output schema, the description is outstanding. It covers the tool's function, the specific triggers for invocation, and the crucial domain rule about Rev 2 assessment obligations. The structural-summary behavior is covered in the schema, and the description adds meaningful policy context beyond the structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description and examples for the optional 'requirement' parameter. The description reinforces that the parameter is a specific requirement, but it adds no new semantic details beyond the schema. The baseline of 3 is appropriate because the schema carries the burden, and this description does not materially enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Explain how NIST SP 800-171 Rev 2 and Rev 3 differ, and what happened to a specific requirement between them.' This clearly distinguishes it from sibling tools like crosswalk_control (control-level mapping) and lookup_rev3_requirement (single-revision lookup) by focusing on the comparison between revisions and the fate of specific requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit call-this-when guidance: 'Call this when someone is implementing Rev 3 early, holds a Rev 3 citation and needs the Rev 2 obligation, or asks which revision applies to them.' It also identifies the underlying DoD policy driver. It does not explicitly name alternative tools to avoid, but the sibling list and the 'versus' framing create sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
determine_cmmc_levelDetermine required CMMC levelADetermine which CMMC level (1, 2, or 3) applies to a defense contractor based on the data they handle and the clauses in their contracts, and - separately - which assessment type may actually be designated today. Those are not the same question: CMMC Phase II was suspended on 13 July 2026, so C3PAO and DIBCAC assessments cannot currently be designated even where the level calls for one. Call this when the user asks "what CMMC level do I need", whether FCI-only work needs CMMC, or what DFARS 252.204-7012/7019/7020/7021 imply.
| Name | Required | Description | Default |
|---|---|---|---|
| handles_cui | Yes | Does the organization store, process, or transmit Controlled Unclassified Information (CUI) - e.g. technical data, drawings, specs above general descriptive material? | |
| contract_clauses | No | FAR/DFARS clauses present in their contracts, if known |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, but the description adds crucial context: 'CMMC Phase II was suspended on 13 July 2026, so C3PAO and DIBCAC assessments cannot currently be designated even where the level calls for one.' This time-sensitive regulatory caveat goes beyond annotations and tells the agent about current real-world limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by necessary context. The second sentence includes critical regulatory timing and contract clause examples, all without redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description implies the output by stating it 'Determine[s] which CMMC level... and - separately - which assessment type may actually be designated today.' It includes enough context about when to use the tool and the suspension nuance, but does not explicitly describe the return format or whether reasoning is included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for 'handles_cui' and 'contract_clauses'. The description adds only marginal semantic value by mentioning 'data they handle' and 'clauses in their contracts', which maps directly to the schema. It does not add syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Determine which CMMC level (1, 2, or 3) applies to a defense contractor based on the data they handle and the clauses in their contracts.' It also distinguishes the separate question of 'which assessment type may actually be designated today,' adding scope that differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit triggers: 'Call this when the user asks "what CMMC level do I need", whether FCI-only work needs CMMC, or what DFARS 252.204-7012/7019/7020/7021 imply.' It clarifies that the level question and current assessment type question are different, but does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_poam_entriesGenerate POA&M entries for control gapsATurn a list of unimplemented NIST SP 800-171 controls into structured Plan of Action & Milestones (POA&M) entries - deficiency description, planned remediation, priority derived from the SPRS weight, and target dates per DoD-aligned governance (90 days for high-priority items, 180 for standard). Also returns the governance rules a POA&M must satisfy to survive a CMMC assessment. Call this when the user has assessment gaps and needs a remediation plan artifact.
| Name | Required | Description | Default |
|---|---|---|---|
| gaps | Yes | The unimplemented or partially implemented controls |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is fully consistent with them, adding no contradiction. It adds rich behavioral context: priority derived from SPRS weight, 90/180-day target dates, and the fact that it also returns CMMC assessment governance rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary function and then key output details. Every sentence earns its place with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema, so the description needs to cover inputs, outputs, and key behavioral rules. It does so thoroughly: inputs (list of controls), outputs (structured entries and governance rules), and specific policy details (90/180 days, CMMC survival rules).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'gaps' parameter with full descriptions and examples (e.g. control '3.5.3'), covering 100% of parameters. The description does not add any new parameter-level detail beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Turn ... into structured POA&M entries' and identifies both the input (unimplemented NIST SP 800-171 controls) and output (structured entries plus governance rules). It is clearly distinct from sibling tools like calculate_sprs_score or determine_cmmc_level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call: 'Call this when the user has assessment gaps and needs a remediation plan artifact.' It does not mention when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_assessment_objectivesGet 800-171A assessment objectives for a controlAGet the official NIST SP 800-171A assessment objectives for one NIST SP 800-171 Rev 2 requirement - the exact "Determine if..." objectives a CMMC Level 2 assessor scores, plus the potential assessment methods (what an assessor examines, who they interview, what they test). Call this when the user asks how a control is assessed, what evidence an assessor will look for, or how to prepare a specific control for a C3PAO assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| control | Yes | Control number, e.g. "3.5.3" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by noting that it returns the exact 'Determine if...' objectives and potential assessment methods, and that it is scoped to a single requirement. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states what the tool does, the second explains when to use it. It is front-loaded and every sentence adds value with no extraneous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description provides sufficient coverage: it explains the exact content returned (objectives and methods), the single-requirement scope, and appropriate trigger contexts. Good annotations reduce the need for additional behavioral caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'control' described as 'Control number, e.g. "3.5.3"'. The description reinforces that the tool works with one Rev 2 requirement but does not add new parameter syntax or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the exact resource ('official NIST SP 800-171A assessment objectives for one NIST SP 800-171 Rev 2 requirement') and details the content (objectives and assessment methods). It clearly distinguishes itself from sibling tools like lookup_control or list_controls, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool: 'when the user asks how a control is assessed, what evidence an assessor will look for, or how to prepare a specific control for a C3PAO assessment.' It does not mention alternatives or explicit when-not-to-use scenarios, but the usage context is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_controlsList NIST 800-171 controlsAList NIST SP 800-171 Rev 2 requirements with their DoD Assessment Methodology (SPRS) weights, optionally filtered by control family name or by point weight (5, 3, or 1). Call this to enumerate the 110 CMMC Level 2 controls, to find all 5-point (highest-impact) requirements, or to see everything in one family such as Access Control. Returns identifiers and weights only - use lookup_control for one requirement's full text, or pass verbose to include every requirement's text at roughly twenty times the size.
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Filter by control family | |
| weight | No | Filter by DoD assessment point weight | |
| verbose | No | Include the full requirement text for every result. Off by default: an unfiltered verbose listing is ~25× larger and is rarely what the question needs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent, so the description appropriately focuses on additional behavioral detail: it returns identifiers/weights only by default, and verbose includes full text at roughly 25× the size. This warns the agent about payload size and default output shape, which is valuable context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and then usage scenarios, an alternative, and a performance caveat. Every sentence adds essential information with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with three optional parameters and no output schema, the description covers the main use cases, return value scope, alternative tools, and a size warning for verbose mode. It provides enough context for an agent to decide when to call this tool and what to expect in response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions and enums/consts, so baseline is 3. The description adds only marginal semantic context (e.g., point weight values 5/3/1 and a family example), but doesn't explain parameters beyond what the schema already conveys, so it doesn't warrant a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists NIST SP 800-171 Rev 2 requirements with SPRS weights and supports filtering by family or weight. It explicitly distinguishes itself from siblings by noting lookup_control is for full text of a single requirement and that this tool returns identifiers/weights only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: enumerate all 110 CMMC Level 2 controls, find high-impact 5-point requirements, or view a whole family like Access Control. It also names the alternative lookup_control for single-requirement full text and clarifies when to use verbose, giving clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_level1_practicesList the 17 CMMC Level 1 practicesAList all 17 CMMC Level 1 basic safeguarding practices with their FAR 52.204-21 clause citations - the complete requirement set for contractors handling Federal Contract Information (FCI) only. Call this when the user asks what CMMC Level 1 requires.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is handled. The description adds valuable context beyond that: it specifies the list includes FAR 52.204-21 citations, is the complete requirement set, and is scoped to FCI-only contractors. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action and content, the second gives the usage trigger. It is front-loaded, direct, and contains zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter list tool with no output schema. The description fully captures what the tool returns, the scope, and when to invoke it. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which is the baseline-4 case. The description doesn't need to explain parameters, and it doesn't add confusion. Since there is nothing to document, a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('list'), the exact resource ('all 17 CMMC Level 1 basic safeguarding practices'), and adds the FAR clause citation detail. It also distinguishes from sibling tools by explicitly framing this as the 'complete requirement set' for Level 1, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear trigger: 'Call this when the user asks what CMMC Level 1 requires.' This gives explicit when-to-use context. It doesn't explicitly mention excluding alternatives, but the sibling names and the specificity of this tool make the scenario clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_clauseLook up a FAR/DFARS cybersecurity clauseAExplain what a FAR or DFARS cybersecurity clause obliges a contractor to do: what triggers it, the concrete duties, the reporting deadlines, what it flows down to subcontractors, and which other clauses come with it. Covers 52.204-21, 252.204-7008, 252.204-7012, 252.204-7019, 252.204-7020, 252.204-7021, 252.239-7010. Call this when someone asks "my contract has 7012 in it, what do I have to do", which clauses require CMMC, what flows down to a subcontractor, or how long they have to report an incident. Does NOT reproduce clause text verbatim - the text is law, it gets amended, and quoting a stale copy into a contract dispute is worse than a citation; each answer links the authoritative text at acquisition.gov.
| Name | Required | Description | Default |
|---|---|---|---|
| clause | No | Clause number - "7012", "252.204-7012", or "DFARS 252.204-7012" all work. Omit to list every clause covered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: it returns explanations and links to authoritative text rather than verbatim quotes, and explains why (law gets amended, stale quotes in disputes are harmful). This goes beyond the annotations and helps the agent set proper user expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then structured into coverage, use cases, and limitations. It's longer than average, but every sentence carries meaningful information—the clause list, call triggers, and the critical caveat about not quoting verbatim. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description must convey what the tool returns, and it does: a plain-language explanation of duties, triggers, deadlines, flowdown, related clauses, and links to authoritative text. It also lists all covered clauses and explains the non-verbatim behavior. No important aspect is missing for a lookup tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the 'clause' parameter 100% with format examples and the omission behavior. The description adds the full list of supported clause numbers (52.204-21, etc.), which is not in the schema and gives the agent concrete valid values. This extra information elevates the score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Explain') and a clear resource ('a FAR/DFARS cybersecurity clause'), then enumerates exactly what aspects are covered: triggers, duties, deadlines, flowdown, and related clauses. It lists the specific clause numbers, which distinguishes it from siblings like lookup_control (which handles individual controls) and lookup_rev3_requirement (which likely targets revision requirements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this when...' and provides concrete example queries ('my contract has 7012 in it...') and topics (CMMC requirements, flowdown, incident reporting). It also states what the tool does NOT do (reproduce verbatim text) and why, giving the agent clear boundaries. While it doesn't name alternative tools, the exclusions and use cases are sufficiently explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_controlLook up a NIST 800-171 controlAGet one NIST SP 800-171 Rev 2 security requirement by number (e.g. "3.5.3"): the full requirement text, its control family, and its exact DoD Assessment Methodology (SPRS) point weight, including the sliding-scale rules for 3.5.3 (MFA) and 3.13.11 (FIPS cryptography). Call this when the user asks what a specific 800-171 or CMMC Level 2 control requires or how many SPRS points it is worth. Pass sections to get the 800-171A assessment objectives and the framework crosswalk in the same call instead of three.
| Name | Required | Description | Default |
|---|---|---|---|
| control | Yes | Control number, e.g. "3.1.1" or "3.13.11" | |
| sections | No | Extra views to include: "objectives" for the 800-171A assessment objectives (how an assessor tests it), "crosswalk" for the 800-53 / CSF 2.0 / SOC 2 mappings. Omit for the requirement and its weight alone. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds valuable behavioral context: the inclusion of sliding-scale rules for specific controls (3.5.3 and 3.13.11) and that passing sections returns additional views. This goes beyond annotation-provided information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence immediately states the core action and resource, followed by the key output details and the optional sections behavior. Every sentence adds value, with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description appropriately explains what the tool returns (full requirement text, control family, SPRS point weight, sliding-scale rules, and optional objectives/crosswalk). It covers the essential behavior for effective use, though it does not address error handling or edge cases like invalid control numbers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for both parameters, including descriptions for 'control' and 'sections.' The description reinforces this with examples ('3.5.3') and clarifies the 'sections' parameter's effect, but adds no fundamentally new semantic information beyond the schema—hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get one NIST SP 800-171 Rev 2 security requirement by number' with specific output components (requirement text, control family, SPRS weight). It distinguishes from siblings by covering combined lookups (objectives, crosswalk) and referencing Rev 2 while sibling lookup_rev3_requirement exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Call this when the user asks what a specific 800-171 or CMMC Level 2 control requires or how many SPRS points it is worth.' It also hints at alternatives by saying 'instead of three' but does not name them, so it lacks explicit when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_rev3_requirementLook up a NIST 800-171 Rev 3 requirement (advisory)AGet one NIST SP 800-171 REVISION 3 requirement by its zero-padded number (e.g. "03.01.01"): the requirement statement, its organization-defined parameters, the 800-171A Rev 3 assessment objectives, and whether it was withdrawn. Rev 3 has 97 active requirements of 130 numbered across 17 families, with 88 ODPs and 422 objectives. IMPORTANT: Rev 3 is NOT currently binding for DoD contracts - DFARS 252.204-7012 is pinned to Rev 2 by class deviation, and SPRS scores Rev 2 only. Use lookup_control for anything contractual; use this when the user is planning ahead, doing civilian-agency CUI work, or has explicitly asked about Rev 3. Identifiers differ between revisions and collide: Rev 2's 3.1.1 is not Rev 3's 03.01.01.
| Name | Required | Description | Default |
|---|---|---|---|
| requirement | Yes | Rev 3 requirement number, e.g. "03.01.01" or "3.1.1" (zero-padded automatically). This is a Rev 3 identifier - it is NOT the same requirement as the Rev 2 control with the similar number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent, but the description adds substantial behavioral context: Rev 3 is advisory and not binding for DoD, the tool returns a withdrawal flag, and identifiers between revisions collide. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and return list, then adds important caveats. The stats about 97 active requirements and objectives are extra but useful. It is slightly verbose but every section earns its place, especially the critical advisory warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing what the tool returns (requirement statement, ODPs, objectives, withdrawal status). It also covers usage context and pitfalls. Minor gaps like error behavior or exact response format remain, but for a simple advisory lookup this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of the single parameter, already explaining zero-padding and the Rev 2/Rev 3 identifier difference. The description reinforces this with an example and the collision warning, but does not add new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get one NIST SP 800-171 REVISION 3 requirement by its zero-padded number' and lists the exact contents returned (statement, ODPs, objectives, withdrawal flag). It explicitly distinguishes itself from lookup_control, which satisfies the sibling differentiation criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance: 'Use lookup_control for anything contractual; use this when the user is planning ahead, doing civilian-agency CUI work, or has explicitly asked about Rev 3.' It also warns about identifier collisions between Rev 2 and Rev 3, providing clear decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scope_assessmentDetermine CMMC assessment scopeAWork out which assets fall inside a CMMC assessment boundary, and what each category obliges. Returns the DoD asset categories (CUI Asset, Security Protection Asset, Contractor Risk Managed Asset, Specialized Asset, Out-of-Scope) with how each is treated at assessment, plus the CUI categories that most often pull a defense contractor into scope unexpectedly. Call this when someone asks what is in scope, how to reduce assessment cost, whether an enclave helps, or whether a specific system counts. Scope decides the size and cost of the whole engagement, so getting it wrong is expensive in both directions.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | CMMC level being scoped. Level 1 has no asset taxonomy - everything touching FCI is in scope. | |
| include_cui_categories | No | Include the common CUI categories and the traps that hide them. Useful when the contractor is unsure whether they hold CUI at all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety traits. It adds behavioral context by explaining what the tool returns (DoD asset categories with treatment details, plus CUI categories that commonly surprise contractors) and the significance of scope decisions on cost. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: (1) the core function, (2) the return value, and (3) when to use it. It is front-loaded with the primary action, avoids redundancy, and includes only one contextual sentence about cost implications, which adds urgency rather than fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, full schema coverage, and no output schema, the description carries the burden of explaining what the tool returns. It does so by enumerating the asset categories and CUI categories, which is sufficient for an agent to select and invoke the tool. It could be more explicit about the output structure (e.g., whether it's a list or detailed report), but the missing details are not critical for correct invocation, so this is slightly above the baseline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic value for the include_cui_categories parameter by noting 'the CUI categories that most often pull a defense contractor into scope unexpectedly,' which enriches the schema's phrase 'traps that hide them.' It does not discuss the level parameter further, but the schema already adequately describes it, including the Level 1 nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Work out which assets fall inside a CMMC assessment boundary, and what each category obliges.' It uses a specific verb ('work out') and resource ('CMMC assessment boundary'), and distinguishes itself from siblings like determine_cmmc_level by focusing on asset scope rather than level determination. The description also enumerates the returned asset categories, making the purpose concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts: 'Call this when someone asks what is in scope, how to reduce assessment cost, whether an enclave helps, or whether a specific system counts.' This is clear and actionable, though it does not explicitly mention alternatives or when-not-to-use. The guidance is sufficient for an agent to decide when this tool is appropriate, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
2,029 DISA STIG rules with official check/fix text, CCI mappings, and .ckl checklist export.
10,065 source-verified compliance nodes, 39 pillars, 25 MCP tools (EU AI Act, GDPR, NIST, MITRE).
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
BC/DR & compliance tools: DORA, NIS2, NIST CSF, GDPR, SOC 2, CMMC, CAF, ISO 27001, FCA/PRA.