Search FIPS 140 validations by module name or vendor. Use this to answer whether a given product or vendor holds a current validation, and at what level.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| limit | No | ||
| query | Yes | Substring of the module name or vendor | |
| status | No | ||
| standard | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself must convey behavioral meaning. It transparently frames the tool as a read-style search and states the core outcome ('current validation' and 'level'). However, it does not disclose how status filtering behaves, whether results may include historical or revoked validations by default, or what the response contains beyond the implied level.
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 short, purposeful sentences with no filler. The core search behavior is front-loaded, and the use case is stated immediately after. 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?
For a tool with five parameters, no output schema, and no annotations, the description is somewhat thin. It defines the main use case and required query, so basic invocation is clear, but it omits guidance on filters such as status and level, and does not clarify whether the tool returns only current validations or all matching validations. Given the sibling set, a bit more context would help avoid mis-selection.
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 description maps 'query' to module name/vendor and hints at the 'level' concept, but it does not explain the 'status', 'limit', or 'level' parameters in any detail. The schema documents only the query parameter explicitly; the 'status' enum and 'limit' default are self-evident but under-described. The description adds some value but leaves meaningful gaps.
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 states a specific action ('Search'), a concrete resource ('FIPS 140 validations'), and the query dimensions ('module name or vendor'). It also clarifies the intended use case: determining whether a product/vendor holds a current validation and at what level. This is enough to distinguish it from the sibling tools such as fips_in_process or fips_sunset.
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 phrase 'Use this to answer whether a given product or vendor holds a current validation, and at what level' gives clear, actionable guidance for when the tool should be chosen. It does not explicitly name sibling alternatives or state when not to use them, so it falls just 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.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect: certificate number lookup, search by name/vendor, vendor portfolio, sunset dates, in-process submissions, and CVE associations. The only mild overlap is between fips_search and fips_vendor when querying by vendor, but the descriptions clarify that one checks current validation while the other returns the full grouped portfolio.
All tool names follow a consistent fips_<topic> pattern in lowercase snake_case. Even though most are noun-like rather than verb_noun, the prefix and naming style are uniform and predictable across the set.
Six tools is well-scoped for a FIPS 140 certificate tracker: each covers a distinct query type without redundancy. The count feels intentional and neither too thin nor bloated.
The tool set covers the main certificate lifecycle: in-process submissions, active certificates, sunset status, historical/revoked details via certificate lookup, vendor-level viewing, and CVE association. It also includes cross-referencing hints such as checking for 140-3 successors before reporting a gap, so the surface appears complete for the domain.