DEA registration & controlled-substance authority tracking for prescribers — read-only demo.
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.
Average 4/5 across 5 of 5 tools scored.
Each tool has a distinct purpose—export, summary, expiring, expired, and search—but get_registrations_expiring and list_cannot_prescribe both deal with registration status and could be confused without reading carefully. Overall boundaries are mostly clear.
Names broadly follow a verb_noun pattern and are all snake_case, but verbs vary (export, get, list, search) and list_cannot_prescribe is a verb followed by a phrase rather than a clear noun. Still predictable and readable.
Five tools is well-scoped for a monitoring-focused domain. Each tool covers a distinct query need—summary, search, expiring, expired, and full export—without unnecessary bloat.
The tool set covers the core monitoring workflow well: search, aggregate summary, expiring, expired/ineligible, and full data export. A minor gap is the lack of a dedicated get-single-registration tool, though search can approximate it.
export_registration_reportAInspectExport the full controlled substance registration report as CSV text (prescriber, registration, expiry, status, reminder history).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 output is CSV text, which is important behavioral information (text string vs. structured object). It also clarifies that it exports the full report, implying no filtering. It does not mention performance or permission requirements, but for a read-only export operation this is acceptable.
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 a single, front-loaded sentence that states the action, scope, output format, and included fields. Every word 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?
Given the tool has no parameters and no output schema, the description adequately explains what the tool returns (CSV text) and what data it covers (prescriber, registration, expiry, status, reminder history). This is sufficient for an agent to select and invoke the tool 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?
There are zero parameters, and the schema is empty. Per the rubric, a baseline of 4 is appropriate when no parameters exist. The description also adds context about the output, which helps compensate for the absence of parameter 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 function: 'Export the full controlled substance registration report as CSV text.' It specifies the verb (Export), the resource (full controlled substance registration report), and the output format (CSV text). It distinguishes itself from sibling tools like get_authority_summary (summary), get_registrations_expiring (filtered), and search_registrations (search).
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 implies usage context by specifying 'full report' and 'CSV text', indicating this is for bulk export rather than filtered/summary views. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_authority_summaryAInspectGet the controlled substance authority summary: totals for tracked registrations, renewals not started, expired, due in 30 days, and awaiting issue.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'Get' implies a non-mutating read operation, and the description details what data is returned. However, it does not explicitly state read-only status, permission requirements, or any other behavioral constraints, though this is acceptable for a simple getter.
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 a single, efficiently structured sentence. It front-loads the action ('Get'), specifies the resource, and lists the output categories in a clear, ordered list without any 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?
Given the zero-parameter signature and absence of an output schema, the description adequately specifies what the tool returns by naming all the summary categories. It could mention the response format, but the level of detail is sufficient for a summary 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?
The tool has zero parameters, so there is no parameter documentation needed. The description focuses appropriately on the output, and with 100% schema coverage of an empty schema, the baseline of 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 tool retrieves a controlled substance authority summary and enumerates the specific totals included (tracked registrations, renewals not started, expired, due in 30 days, awaiting issue). This specific verb+resource combination distinguishes it from sibling tools like search_registrations or get_registrations_expiring.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not reference sibling tools, mention prerequisites, or explain when this summary would be preferred over more specific tools like get_registrations_expiring or export_registration_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_registrations_expiringAInspectList controlled substance registrations expiring within the next N days (default 90), including state CSRs and mid-level registrations.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-ahead window in days (default 90). |
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 adds useful context such as the default window and the types of registrations included, but it does not disclose potential behavioral traits like whether it is read-only, pagination, sorting, or any side effects. The verb 'list' implies a read-only operation, but this is not explicit.
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 a single, concise sentence that front-loads the key information (what it lists and the default window). No unnecessary words or repetition.
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 list tool with one optional parameter, the description is fairly complete. It states the resource, the scope, and the default value. However, it does not explain the output format, and there is no output schema to compensate, so it falls slightly short of a perfect score.
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 describes the 'days' parameter as 'Look-ahead window in days (default 90)' with 100% coverage. The description's mention of 'within the next N days (default 90)' reinforces this but does not add new 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 lists controlled substance registrations expiring within a specified number of days, with a default of 90 days. It also specifies the scope (state CSRs and mid-level registrations), which distinguishes it from the sibling tools like search_registrations or export_registration_report.
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 implies use for checking upcoming expirations but does not explicitly state when to use this tool versus alternatives like search_registrations or export_registration_report. There is no mention of exclusions or conditions where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_cannot_prescribeAInspectList prescribers whose DEA registration or state controlled substance license has expired — the practitioners who cannot legally write controlled prescriptions right now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It does clarify the core selection criterion and the legal consequence, but it does not disclose output shape, data freshness, permission requirements, or any read-only guarantee beyond the implication of the verb 'List'.
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 a single concise sentence that front-loads the core action and subject, then adds a clarifying definition after the em dash. Every word earns its place and no irrelevant details are included.
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 an unparameterized list tool with no output schema, this description provides the essential context: what is listed, the status condition, and the legal interpretation. It could be slightly stronger with a note on what information is returned per prescriber or how this differs from get_registrations_expiring, but it is substantially 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?
This tool has zero parameters and 100% schema coverage, so there is no parameter ambiguity. The description adds meaning by specifying the exact inclusion criterion for the returned records, which effectively answers the only question an agent would have about behavior.
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 'List' with a clear subject ('prescribers whose DEA registration or state controlled substance license has expired') and adds the operational meaning ('cannot legally write controlled prescriptions right now'). It is clear on its own, though it does not explicitly contrast itself with the closely related sibling get_registrations_expiring.
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 implies when to use the tool: when the agent needs prescribers currently ineligible to prescribe due to expired credentials. However, it gives no explicit guidance about when not to use it, such as distinguishing expiring registrations from already-expired ones, nor does it mention the sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_registrationsAInspectSearch controlled substance registrations by prescriber name, registration type, or location. Returns matching records with expiry date and status.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Text to match against prescriber or registration (case-insensitive; shorthand like "CSL" or "DEA number" works). Omit to list everything. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns matching records with expiry date and status, which is helpful. However, it does not mention that the operation is read-only (though 'search' implies it), nor does it describe sorting, pagination, or any limitations. The behavior is mostly straightforward, but the description adds only modest context beyond the obvious.
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 a single sentence that packs in the core purpose, search criteria, and return fields. It wastes no words and is immediately understandable, correctly front-loading the verb and resource.
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 search tool with one parameter and no output schema, the description is nearly complete: it states what it searches, the criteria, and what it returns. It does not explain the return format in detail, but the declared fields (expiry date and status) are likely sufficient for an agent. The lack of annotations is partly compensated by the clarity of the search behavior, though a note on read-only safety would improve completeness.
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 provides 100% coverage for the single parameter 'query', including its case-insensitive nature and shorthand support. The description adds semantic value by specifying that the search can be by prescriber name, registration type, or location—details not fully explicit in the schema. This goes beyond the baseline expected for full coverage.
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 controlled substance registrations, with a specific verb ('Search') and resource ('controlled substance registrations'). It also mentions the search dimensions (prescriber name, registration type, or location) and output fields (expiry date and status), which distinguishes it from siblings like export_registration_report or get_registrations_expiring.
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 implies usage for general searching of registrations, but it does not explicitly mention when to choose this over alternatives like get_registrations_expiring or get_authority_summary. The sibling tool names suggest distinct purposes, but the description lacks explicit when/when-not guidance or alternative references.
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
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!
