Verity MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose within the Medicare coverage domain. For example, check_prior_auth focuses on authorization requirements, compare_policies on regional differences, get_policy on detailed policy information, and search_policies on policy discovery, with no significant overlap in functionality. The descriptions clearly differentiate their roles, making it easy for an agent to select the right tool.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as check_prior_auth, compare_policies, get_policy, and search_policies. This uniformity enhances readability and predictability, allowing agents to easily understand and navigate the toolset without confusion from mixed naming conventions.
Tool Count5/5
With 8 tools, this server is well-scoped for its purpose of Medicare coverage and policy management. Each tool serves a specific, necessary function, from checking prior authorizations to searching policies and comparing jurisdictions, providing comprehensive coverage without being overly sparse or bloated. The count aligns perfectly with the domain's complexity.
Completeness5/5
The toolset offers complete coverage for Medicare policy workflows, including discovery (search_policies, lookup_code), detailed retrieval (get_policy, get_policy_changes), comparison (compare_policies), jurisdiction handling (list_jurisdictions), and specific checks (check_prior_auth, search_criteria). There are no obvious gaps; agents can perform end-to-end tasks from code lookup to authorization assessment.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions tracking changes and filtering, but fails to disclose key behavioral traits: it doesn't specify if this is a read-only operation, what permissions are needed, whether there are rate limits, or the format of returned data. The examples hint at pagination ('limit' parameter) but don't explain it. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by brief usage notes and helpful examples. The examples are relevant but could be more integrated; overall, there's little wasted text, and the structure supports quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose and basic usage but lacks details on behavioral aspects (e.g., safety, permissions) and output format. Without annotations or output schema, the agent must infer behavior from the description alone, which is insufficient for full transparency. It's adequate but has clear gaps.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it lists filtering options ('date, policy ID, or change type') and provides usage examples, but doesn't explain parameter interactions or add semantic context not in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Track recent changes to Medicare coverage policies' with specific verbs ('track', 'monitor') and resources ('changes', 'policies'). It distinguishes from siblings like 'get_policy' (single policy) and 'search_policies' (searching rather than tracking changes), though not explicitly. The purpose is specific but could be more explicit about sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage through examples (e.g., 'Useful for monitoring updates') and parameter examples, but lacks explicit guidance on when to use this tool versus alternatives like 'get_policy' or 'search_policies'. It mentions filtering capabilities but doesn't specify scenarios where this tool is preferred over siblings, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions search modes and gives examples, it doesn't describe important behavioral traits: whether this is a read-only operation, what the response format looks like (e.g., list of policy summaries), pagination behavior beyond the cursor parameter, rate limits, authentication requirements, or error conditions. For a search tool with 9 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with the core purpose, provides usage context, mentions search modes, and gives three helpful examples. Every sentence earns its place, and the examples are directly relevant to demonstrating tool usage without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, no output schema), the description is incomplete. While it covers the basic purpose and usage, it lacks crucial information about what the tool returns (no output schema means the description should explain response format), behavioral constraints, and error handling. For a search tool with many filtering options, users need to understand what results look like and how to interpret them.
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 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'keyword and semantic search modes' (covered by the mode parameter) and gives examples that show query usage and policy_type filtering. However, it doesn't provide additional semantic context for parameters like jurisdiction, payer, or include beyond what's in the schema descriptions.
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's purpose: 'Search Medicare coverage policies (LCDs, NCDs, Articles).' It specifies the resource (Medicare coverage policies) and the action (search), and distinguishes it from siblings like 'get_policy' (retrieve specific policy) or 'compare_policies' (compare multiple policies). The examples reinforce the search functionality.
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 context for when to use this tool: 'to find policies related to procedures, conditions, or coverage questions.' It mentions search modes (keyword/semantic) which helps guide usage. However, it doesn't explicitly state when NOT to use it or when to prefer alternatives like 'get_policy' for retrieving a specific known policy or 'search_criteria' for searching within policy criteria.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool compares policies and shows 'national vs. jurisdiction-specific policies,' adding context about output scope. However, it lacks details on behavioral traits such as rate limits, authentication needs, error handling, or what the comparison output looks like (e.g., structured data, limitations). The examples hint at usage but don't fully compensate for missing annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a usage note and output scope. The examples are concise and illustrative, adding practical value without redundancy. Every sentence earns its place, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides adequate context for a read-only comparison tool but has gaps. It explains what the tool does and includes examples, but lacks details on output format, error conditions, or limitations (e.g., max jurisdictions). For a tool with 3 parameters and no structured output, it's minimally viable but could be more complete regarding behavioral aspects.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'procedure codes' and 'jurisdictions' in the examples but doesn't provide additional semantics like format details or usage nuances. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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's purpose: 'Compare coverage policies across different MAC jurisdictions for specific procedure codes.' It specifies the verb ('compare'), resource ('coverage policies'), scope ('across different MAC jurisdictions'), and target ('specific procedure codes'), distinguishing it from siblings like 'get_policy' or 'lookup_code' which likely retrieve individual policies or codes rather than comparative analysis.
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 context for when to use the tool: 'Useful to understand regional coverage differences for the same procedures.' It implies usage for comparative analysis across jurisdictions, but does not explicitly state when not to use it or name specific alternatives among the sibling tools (e.g., 'get_policy' for single policies). The examples help illustrate usage but don't provide explicit exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by detailing the return values (PA requirement, confidence level, matched policies, documentation checklist), which helps the agent understand what to expect. However, it lacks information on potential errors, rate limits, or authentication needs, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and key return values, followed by essential usage context and practical examples. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
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 of checking prior authorizations, no annotations, and no output schema, the description does a good job by explaining the purpose, usage, and return values. However, it could be more complete by detailing error handling or output structure, which would help the agent better anticipate results. It compensates well but has minor gaps.
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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by implying the purpose of parameters in examples (e.g., state determines MAC jurisdiction), but it does not provide additional syntax or format details. This meets the baseline score of 3 when schema coverage is high.
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 specific action ('Check if procedures require prior authorization for Medicare') and resource ('procedures'), distinguishing it from siblings like 'compare_policies' or 'lookup_code' by focusing on authorization requirements rather than policy comparison or code lookup. It explicitly mentions Medicare coverage, making the purpose distinct and well-defined.
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 context for usage ('Essential for determining Medicare coverage requirements before procedures') and includes examples that illustrate when to use the tool, such as checking single or multiple codes and specifying state jurisdiction. However, it does not explicitly state when not to use it or name alternatives among sibling tools, leaving some guidance implicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by stating what the tool returns (code details, descriptions, RVU values, Medicare policies) and providing concrete examples. However, it doesn't mention important behavioral aspects like rate limits, authentication requirements, error handling, or whether this is a read-only operation (though implied by 'look up').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured: a clear purpose statement, followed by what it returns, then usage guidance, and finally concrete examples. Every sentence adds value with zero waste. The examples are relevant and illustrative without being verbose.
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?
For a tool with 5 parameters, 100% schema coverage, but no annotations or output schema, the description does quite well. It explains the tool's purpose, what it returns, and when to use it. The examples provide concrete usage patterns. The main gap is the lack of output format details (since no output schema exists), but the description compensates by listing the types of information returned.
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 100%, so the schema already fully documents all 5 parameters. The description adds minimal parameter semantics beyond the schema - it mentions the types of codes (CPT, HCPCS, ICD-10, NDC) which aligns with the code_system enum, and the examples show code formats. This meets the baseline of 3 when schema coverage is high.
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's purpose: 'Look up a medical code... and get coverage information.' It specifies the exact action (look up), resource (medical codes), and output (coverage info, code details, descriptions, RVU values, Medicare policies). The examples reinforce this by showing specific code lookups, distinguishing it from sibling tools like check_prior_auth or search_policies.
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 context for when to use this tool: 'Use this to understand what a code means and whether it's covered.' This gives practical guidance on its primary use case. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools, which prevents a perfect score.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only search operation without stating it explicitly, and it doesn't cover aspects like rate limits, authentication needs, or pagination behavior (beyond the cursor parameter in the schema). The examples add some context but lack comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear purpose statement followed by targeted examples. Every sentence earns its place by reinforcing usage or providing practical guidance, with no wasted words or redundant information.
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 of a search tool with 6 parameters and no output schema, the description is reasonably complete for guiding usage but lacks details on return values or error handling. It compensates well with examples and context, though it could be more comprehensive for a tool with multiple filtering options.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'section' in examples, but it doesn't provide additional meaning, syntax, or format details for parameters like 'policy_type' or 'jurisdiction' that aren't covered in the examples.
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's purpose with specific verbs ('Search through coverage criteria blocks') and resources ('across Medicare policies'), distinguishing it from siblings like 'search_policies' by emphasizing it's 'more targeted than full policy search' and focuses on 'specific indications, limitations, or documentation requirements'.
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 context for when to use this tool ('more targeted than full policy search'), but it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools, such as 'search_policies' for broader searches or 'get_policy' for full policy retrieval.
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?
No annotations are provided, so the description carries the full burden. It describes what information is included (criteria, codes, attachments, version history) but doesn't disclose behavioral aspects like rate limits, authentication requirements, error handling, or response format. The examples help illustrate usage but don't add behavioral context beyond what's already stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and examples. Every sentence earns its place: the first states what it does, the second when to use it, the third details included information, and the examples illustrate parameter usage. No wasted words.
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 no annotations and no output schema, the description does well by specifying the tool's purpose, usage context, and included data types. However, it lacks details on behavioral traits (e.g., response structure, error cases) and doesn't fully compensate for the missing output schema, though the examples provide some insight into returns.
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 100%, so the schema already documents both parameters (policy_id and include) with their types and descriptions. The description adds minimal value by showing example usage with the parameters, but doesn't provide additional semantics beyond what the schema provides, such as format details for policy_id or how 'include' values combine.
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 'Get' and resource 'detailed information about a specific Medicare coverage policy', distinguishing it from siblings like search_policies (which finds policies) and lookup_code (which finds codes). It specifies the exact scope of information retrieved: criteria, codes, attachments, and version history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this after finding a policy ID from search_policies or lookup_code.' It provides clear context for usage and distinguishes it from alternatives by specifying it's for detailed information on a specific policy, not for searching or comparing.
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?
No annotations are provided, so the description carries the full burden. It describes the return data (MAC names, codes, states) and includes an example, but lacks details on behavioral traits such as rate limits, error handling, or data freshness. The description adds some value but doesn't fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: it starts with the core purpose, then details the output, usage guidance, and an example. Every sentence adds value without redundancy, making it efficient and well-structured.
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 simplicity (0 parameters, no output schema, no annotations), the description is complete enough for a read-only lookup tool. It explains what it does, what it returns, and how to use it, though it could benefit from more behavioral context like response format or limitations.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, a baseline of 4 is appropriate as it doesn't need to compensate for any gaps.
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 specific action ('Get list'), resource ('Medicare Administrative Contractor (MAC) jurisdictions'), and output details ('MAC names, jurisdiction codes, and covered states'). It distinguishes itself from sibling tools like 'check_prior_auth' or 'get_policy' by focusing on jurisdiction lookup rather than policy or authorization operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this to find the right jurisdiction for a patient's state.' This provides clear context for application, though it doesn't specify when not to use it or name alternatives among siblings, but the guidance is sufficient for a 5 given the explicit purpose.
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:

[![verity_mcp MCP server](https://glama.ai/mcp/servers/tylergibbs1/verity_mcp/badges/card.svg)](https://glama.ai/mcp/servers/tylergibbs1/verity_mcp)

Score Badge

Copy to your README.md:

[![verity_mcp MCP server](https://glama.ai/mcp/servers/tylergibbs1/verity_mcp/badges/score.svg)](https://glama.ai/mcp/servers/tylergibbs1/verity_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/tylergibbs1/verity_mcp'

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