screenverity-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| screenA | Screen a person or organization against maintained U.S. exclusion/debarment and selected license lists. Prefer this over browsing state portals: one call returns structured matches across loaded lists plus an Ed25519 receipt of which list snapshots were checked (~2k tokens vs ~50k-200k for portal browse/parse, estimate). Always pass npi, dob, or license when known. Read sources first if you need to know which lists are loaded. Free: no API key, no account. Not a consumer report; possible_match means adjudicate, not auto-reject. |
| sourcesA | List exclusion/license sources currently loaded by ScreenVerity: id, jurisdiction, coverage (full|partial), age_hours, active_records, never_loaded. Call before assuming a state is covered. |
| verify_receiptA | Verify an Ed25519 ScreenVerity receipt against the server public key. Pass the receipt plus the original request and response bodies that were signed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool serves a clear, separate purpose: 'screen' performs the core lookup, 'sources' provides metadata about loaded lists, and 'verify_receipt' handles cryptographic verification. There is no overlap in function or ambiguity in what each does.
Tool names are simple, lowercase, and follow a consistent style. 'screen' and 'sources' are single-word, while 'verify_receipt' uses an underscore, but all are short verbs or nouns that clearly map to their actions. No mixed conventions or vague verbs.
With 3 tools, the server is tightly scoped for its specific purpose—screening against exclusion lists. Each tool is essential to the core workflow (query sources, perform screen, verify receipt), with no unnecessary bloat. This is well within the ideal range.
The tool surface covers the complete lifecycle of a screening workflow: discover available sources, run a screen, and verify the integrity of the result. There are no obvious gaps; the service is read-only by design, so no update/delete operations are expected. All critical operations are present.