Licensy
Server Details
Real-time U.S. medical license verification across all 50 states + DC.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 9 of 9 tools scored.
Each tool has a distinct purpose: bulk_verify for batch checks, verify_license for single detailed, get_license_status for minimal status, get_license_history for retroactive queries, list_physician_licenses for multi-state overview, search_disciplinary_actions for sanctions, get_screenshot_url for audit evidence, and subscribe_to_changes/unsubscribe for webhook management. Overlaps are clearly delineated by use case and input/output differences.
All tool names follow a consistent verb_noun pattern: get_*, list_*, search_*, subscribe_to_changes, unsubscribe, bulk_verify. The naming is predictable and intuitive, making it easy for an agent to infer functionality from the name alone.
With 9 tools, the set is well-scoped for medical license verification. Each tool serves a necessary function without redundancy, covering single queries, bulk operations, historical lookups, disciplinary searches, audit evidence, and webhook subscriptions. The count feels neither sparse nor bloated.
The tool surface comprehensively covers the core workflows: verifying current status (single and bulk), historical verification, listing all licenses, disciplinary actions, audit-grade screenshots, and change notifications. No obvious gaps exist for the server's stated purpose of license verification and monitoring.
Available Tools
9 toolsbulk_verifyAInspect
Verify medical licenses for many (NPI, state) pairs in a single call. Returns one result per input, in input order. Use this instead of calling verify_license in a loop — bulk_verify parallelises server-side, returns faster, and is billed as a single call.
Limits: Pro tier max 100 pairs per call; Enterprise max 1000.
Use this when:
Initial roster ingestion for a credentialing project
Quarterly recredentialing audit of a multi-state group
Pre-call verification of a physician list before scheduling
Paid tier only (Pro or Enterprise).
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: parallel server-side execution, faster returns, billing as a single call, returned results in input order, and tier-based limits (Pro 100, Enterprise 1000). No annotations are present, so the description carries the full burden and meets it well.
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 (7 sentences) with each sentence adding value. It is front-loaded with the purpose and immediately provides comparison to sibling, followed by limits, use cases, and billing. No extraneous information.
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 the presence of an output schema, the description does not need to detail return values but still mentions input order preservation. It covers use cases, limits, billing, and tier restrictions, providing a complete picture for an agent to decide and invoke correctly.
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 clarifies the input structure (many NPI-state pairs) and repeats the limit information from the schema's array description. While the schema has minimal descriptions (0% coverage), the tool's description adds context but not extensive parameter documentation 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 the tool's purpose: 'Verify medical licenses for many (NPI, state) pairs in a single call.' It distinguishes itself from the sibling tool verify_license by explicitly recommending bulk_verify instead of looping verify_license.
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 guidance on when to use bulk_verify, including specific use cases (roster ingestion, quarterly recredentialing audit, pre-call verification) and contrasts it with verify_license for single calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_license_historyAInspect
Return a physician's license status as it was on a specific past date (point-in-time / retroactive lookup).
Use this when:
Insurance company asks 'was this physician licensed when they treated patient X on 2024-08-12?'
Legal discovery for a malpractice case
Retroactive credentialing audit
Input: NPI + state + as_of_date (ISO 8601).
Coverage caveat: full append-only license history is on the roadmap. v1 returns best-available data and a coverage_start date marking the earliest reliable point-in-time queries.
Paid tier only (Pro or Enterprise).
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 v1 returns best-available data with a coverage_start date, acknowledges roadmap limitations, and states the paid tier requirement. This sets appropriate 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 concise and well-structured: a clear one-sentence purpose, bullet-point use cases, input summary, and a caveat. Every sentence adds information without 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?
Given the output schema exists, the description does not need to explain return values. It provides a useful hint about the coverage_start field and the v1 limitation. The context is sufficient for a specialized historical lookup tool.
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 0%, but the description adds value by explicitly listing the input fields (NPI, state, as_of_date) and their format (ISO 8601), compensating for the sparse schema documentation.
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 purpose: returning a physician's license status as of a specific past date (point-in-time/retroactive lookup). It distinguishes from siblings like verify_license or get_license_status by emphasizing historical data.
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 lists use cases (insurance company query, legal discovery, retroactive audit) and mentions the tool is paid tier only. It does not explicitly state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_license_statusAInspect
Return only the license status string for a single physician in a single state. The minimal-output companion to verify_license: optimized for agents that need only a yes/no decision and want to minimize tokens in the LLM context.
Use this when:
You need a one-word answer for routing logic (active vs anything else)
You're checking a license inside a tight inner loop
You want to minimize tokens spent on auxiliary fields
Use verify_license instead when you need expiration date, license_active boolean, or any other field.
Input: NPI (10 digits), state. Output: a single status from the controlled vocabulary: active | expired | lapsed | inactive | suspended | revoked | surrendered | pending | not_found.
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 the output is a single status from a controlled vocabulary and lists the possible values. It does not discuss side effects or error states, but for a simple read-only check this is sufficient.
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 well-structured with clear sections: what it does, when to use, when not to use, input, output. Every sentence adds value, and it is front-loaded with the core purpose.
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 the tool's simplicity (one nested parameter, no annotations, output schema described), the description is complete. It covers input format, output values, and usage context, leaving no major gaps.
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 0%, so the description must compensate. It specifies the input as 'NPI (10 digits), state' and lists the output vocabulary, adding meaning beyond the schema's pattern and length constraints.
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: 'Return only the license status string for a single physician in a single state.' It also distinguishes itself from the sibling tool verify_license by noting it is a 'minimal-output companion' optimized for routing logic.
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?
Explicit usage guidelines are provided: three 'Use this when' scenarios and one 'Use verify_license instead' condition. This helps the agent decide between this tool and its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screenshot_urlAInspect
Return an audit-grade screenshot of the state medical board page used to verify a physician's license. The URL is signed and valid for 15 minutes.
Use this when:
You need primary-source evidence for an audit, credentialing file, or insurance contract
The end user asks 'where did this come from?'
You're generating a credentialing PDF that needs proof attachments
Identify the license by: NPI + state, OR by license_id if you already fetched it via verify_license / list_physician_licenses.
Free-tier callers receive a structured tier_upgrade_required response. Paid tier (Pro / Enterprise) only.
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that the URL is signed and valid for 15 minutes, and that free-tier callers receive a structured tier_upgrade_required response. It implies paid-only access but doesn't detail auth requirements or rate limits.
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 well-structured with bullet points and separate sections for usage and identification. Every sentence adds value, and the key purpose is stated first without 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?
The description covers purpose, usage context, identification methods, and tier restrictions. An output schema exists for return values. It lacks detail on error scenarios beyond the free-tier response, but overall is complete given the tool's 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 has 0% description coverage, so the description must compensate. It explains the two identification methods (NPI+state vs. license_id) and that license_id is internal and used for exact rows from previous fetches. This adds meaning but does not fully detail all parameter aspects.
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 specifically states 'Return an audit-grade screenshot of the state medical board page used to verify a physician's license,' clearly defining the action and resource. It distinguishes from siblings like verify_license (which checks status) by emphasizing audit-grade screenshot.
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?
Explicit use cases are listed ('Use this when: ...'), and identification methods are provided (NPI+state or license_id). However, it does not explicitly mention when NOT to use the tool or direct to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_physician_licensesAInspect
List all U.S. medical licenses Licensy has on file for a single physician (by NPI), one per state. Each entry shows current status and expiration date.
Use this when:
Surveying a physician's multi-state license portfolio
Recredentialing across multiple states at once
Checking which states a physician is licensed in
Do NOT use this for:
A single-state yes/no — use get_license_status (cheaper)
Bulk verification across multiple NPIs — use bulk_verify
Input: NPI (10 digits). Optional include_inactive flag (default false). Output: array of {status, state, expiration_date, license_active}.
Free tier returns these summary fields. Paid tier callers receive the full license record per state.
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses tier-dependent output behavior (free vs paid) and output structure. Lacks explicit mention of read-only nature or rate limits, but adequately transparent for a list operation.
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?
Well-structured with clear sections for purpose, when to use, when not to use, input, output, and tier info. Information is front-loaded and every sentence serves a purpose.
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 the output schema exists (context indicates true), the description adequately covers input details, output summary, tier differentiation, and clear boundaries relative to siblings. No significant gaps.
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 0% according to context. Description restates parameters (NPI 10 digits, include_inactive default false) but adds minimal semantic value beyond what the schema already provides. Doesn't explain practical meaning or constraints.
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?
Clearly states the action (list), resource (all U.S. medical licenses for a single physician by NPI), and scope (one per state). Explicitly distinguishes from siblings like get_license_status and bulk_verify.
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 'Use this when' and 'Do NOT use this for' sections with specific examples and alternative tools, giving strong guidance on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_disciplinary_actionsAInspect
Search for known disciplinary actions against a physician (suspension, revocation, surrender, probation). Sourced from state medical board status text.
Use this when:
Pre-employment screening
Recredentialing — required by most insurance contracts
Investigating a referral source
Input: NPI (preferred) OR full name. Optional state filter. Output: array of {state, action_type, date, source_url}. Action types: suspension | revocation | surrender | probation | reprimand | other.
Coverage note: this surfaces board-status-level signal. Underlying PDF documents are on the roadmap.
Paid tier only (Pro or Enterprise).
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description fully discloses data source (state medical board status text), limitations (board-status-level signal, roadmap), and access restriction (Paid tier only).
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?
Well-structured with purpose, use cases, input/output format, and notes. Every sentence adds value; no fluff.
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 nested parameters and no annotations, the description covers all necessary details: input constraints, output format, coverage scope, and access restrictions.
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?
Adds meaning beyond schema by specifying preferred input (NPI vs full name) and that state is optional. Schema coverage is 0%, so description compensates well.
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 searches for disciplinary actions against physicians, listing specific action types (suspension, revocation, etc.) and distinguishing from siblings like verify_license.
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 use cases (pre-employment screening, recredentialing, referral investigation) and a coverage note, guiding when to use without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
subscribe_to_changesAInspect
Subscribe a webhook URL to license-change events for one or more NPIs. Licensy POSTs a signed JSON payload to your URL when a subscribed event fires.
Events: status_change — license status changes (active → expired, etc.) expiration_warning_60d — license expires in 60 days new_disciplinary_action — new sanction added
Status: webhook delivery is on the roadmap. This tool records the subscription intent today; deliveries will begin once the dispatcher ships.
Paid tier only (Pro or Enterprise).
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: records intent only, paid tier restriction, HTTPS requirement, signed JSON payload, and lists events. Does not address rate limits or auth beyond tier, but still good coverage.
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 well-structured: intro, event list, status note, tier requirement. Every sentence adds value without 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?
Given the presence of an output schema (reducing need to explain return values), the description fully covers purpose, parameters, events, and current delivery status, making it complete for agent use.
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?
Despite 0% schema description coverage, the description adds meaning by explaining NPIs as '10-digit', webhook_url as 'HTTPS endpoint', and detailing events. Adds value beyond the schema's basic descriptions.
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 subscribes a webhook URL to license-change events for one or more NPIs, using a specific verb and resource. It also distinguishes from the sibling tool 'unsubscribe'.
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?
It explicitly mentions 'Paid tier only (Pro or Enterprise)' and notes that delivery is on the roadmap, providing usage context. However, it does not give explicit when-not or alternative usage guidance beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
unsubscribeAInspect
Cancel a webhook subscription you previously created via subscribe_to_changes. Paid tier only (Pro or Enterprise).
Use this when the agent's workflow that wanted the events has completed, or the customer wants to stop receiving change-notifications for a set of NPIs.
Input: subscription_id (string, returned from subscribe_to_changes). Output: {success: true} on cancellation.
Idempotent — repeat calls with the same id return success without error.
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency and output format. No annotations provided, so description carries full burden. Could discuss invalid subscription handling, but idempotency implies success on repeat calls.
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?
Four sentences front-loading the core action, includes input/output details and idempotency. No unnecessary words.
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?
Covers purpose, usage, input, output, idempotency, tier restriction. Output schema exists so return value description is sufficient.
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?
With 0% schema description coverage, description adds value by specifying subscription_id origin (from subscribe_to_changes) and type. Does not clarify nested structure, but input format is clear.
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?
Clearly states it cancels a webhook subscription created via subscribe_to_changes, distinguishing it from sibling tools. Use case is also provided.
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?
Specifies when to use: when workflow completed or customer wants to stop notifications. Also notes paid tier requirement. Could explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_licenseAInspect
Verify a U.S. physician's medical license status in a specific state. Returns current status (active/expired/suspended/etc.), expiration date, and a confidence indicator.
Use this when:
Confirming a physician is currently licensed before scheduling care
Validating credentials during onboarding or recredentialing
Answering 'is Dr. X licensed in [state]?' questions
Do NOT use this for:
Bulk verification of >1 NPI — use bulk_verify instead (paid tier)
Historical 'was this physician licensed on date X' — use get_license_history instead (paid tier)
Input: NPI (preferred) OR (license_number + state), plus state. State accepts either 2-letter code ('CA') or full name ('California').
Output: status, state, expiration_date, license_active. Paid tiers additionally receive license_number, issuance_date, board_source, last_refreshed_at, screenshot_url for audit-grade primary-source verification.
Data is sourced directly from state medical boards and refreshed every 24 hours. Licensy covers all 50 states + DC.
| Name | Required | Description | Default |
|---|---|---|---|
| inp | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data source (state medical boards), refresh frequency (every 24 hours), geographic coverage (all 50 states + DC), and differential output for paid tiers. Lacks explicit statement that tool is read-only, but implied by verification context.
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?
Well-structured with clear headings and bullet points. Every sentence provides essential information, no redundancy. Length is appropriate for the complexity of inputs and outputs.
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?
Covers input choices, output fields (including paid tier extras), data source and refresh. Mentions a 'confidence indicator' but does not explain it. With an output schema presumably present, missing details are minor. Adequate for an AI agent to invoke correctly.
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 descriptions are present but tool description adds value by clarifying preferred input (NPI vs license_number+state), state format flexibility (code or full name), and required state. This goes beyond raw schema, though schema also includes descriptions for each parameter.
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 it verifies a U.S. physician's medical license status in a specific state, listing returned fields (status, expiration date, confidence indicator). It distinguishes from sibling tools like bulk_verify and get_license_history by explicitly stating what each is used for.
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 lists when to use (confirming licensing, credentialing, answering 'is Dr. X licensed?') and when not to use (bulk verification, historical checks), naming alternatives (bulk_verify, get_license_history). Covers both use and non-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!