vicp-registry
Server Details
Search 13,000+ US vaccine court (VICP) decisions: cases, court text, statistics, attorneys. Free.
- 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/5 across 10 of 10 tools scored. Lowest: 3.4/5.
Most tools have distinct purposes, but search and search_cases are essentially aliases (as noted in the description), which could cause confusion. fetch and get_case both retrieve by ID but with different focuses. Overall, the boundaries are clear.
Tool names are mostly snake_case and follow verb_noun pattern, but 'fetch' and 'search' are verbs without a semantic prefix (like 'get_'), creating inconsistency with the majority of get_* tools. This could be confusing for agents expecting uniform naming.
10 tools is well-scoped for a domain-specific read-only registry. Each tool serves a necessary function: search, retrieval, statistics, filters, and specialized profiles. No tool seems redundant or excessive.
The tool set covers all expected operations for the VICP case database: multiple search modes, detailed case retrieval, attorney/special master lookups, statistical aggregates, and filter discovery. No obvious gaps given the read-only nature of the domain.
Available Tools
10 toolsfetchAInspect
Fetch the full record + source text of one case by its id (package_id). (Deep-research companion to search.)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not state if it's read-only, auth requirements, or what 'full record' entails, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with main purpose. Highly efficient.
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?
Adequate for a simple fetch with one param, but no output schema and lack of detail on 'full record' leaves some uncertainty, especially given similar sibling tools.
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?
Only one parameter 'id', described as 'package_id', which adds meaning. With 0% schema coverage, the description provides partial compensation but lacks format 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 tool fetches the full record and source text of a case by id, with '(Deep-research companion to search)' distinguishing it from 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?
Mentions it's a companion to search, implying use after search for full details, but does not differentiate from siblings like get_case or get_case_text, lacking explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_attorneyAInspect
Get one attorney's profile: bio (when available), aggregate outcomes, and their most recent cases. Name is matched case-insensitively.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It reveals case-insensitive name matching and outlines the returned data (bio, outcomes, cases). However, it does not address error behavior (e.g., attorney not found) or confirm idempotency, which is important for a 'get' 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?
The description is concise (two sentences), front-loaded with the main action, and contains no superfluous information. Every phrase 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?
The description covers the main output and name behavior, but lacks explanation for the 'limit' parameter and does not address edge cases like multiple matching names or missing attorneys. Given the absence of an output schema, more detail on return structure 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?
With 0% schema description coverage, the description only clarifies the 'name' parameter (case-insensitive matching). The 'limit' parameter is completely ignored, leaving its purpose and acceptable values undefined.
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 action ('get'), the resource ('one attorney's profile'), and specifies the content (bio, outcomes, recent cases). It distinguishes this from sibling tools like 'search_attorneys' by focusing on a single attorney.
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 this tool (for a single attorney's profile) via the phrase 'Get one attorney's profile', but does not explicitly state when not to use it or mention alternatives like search_attorneys for multiple results. The case-insensitivity note provides additional usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_caseAInspect
Get the complete curated record for one case by package_id.
Includes the AI-assisted case summary, all extracted fields, attorney and
special master, plus links: canonical page, plain-text source bundle, and
per-document PDF links where available.
| Name | Required | Description | Default |
|---|---|---|---|
| package_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation (no destructive hints) and lists included fields, including conditional links. It does not mention error responses or auth requirements, but for a retrieval tool, this is acceptable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists inclusions. Front-loaded and no extraneous 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?
Given no output schema and multiple siblings, the description covers what is returned (case summary, fields, links). It lacks mention of error handling or metadata, but is sufficient for a simple get-by-id 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 coverage is 0%, so the description must compensate. It only restates 'package_id' as the identifier without adding format, source, or example. This is insufficient for guiding the agent on how to obtain a valid package_id.
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 verb 'Get', the resource 'complete curated record for one case', and the qualifier 'by package_id'. This distinguishes it from siblings like get_attorney or get_case_text, which focus on specific portions.
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 provides clear context by listing what is included in the record (summary, fields, attorney, special master, links), implicitly guiding the agent when to use this tool over siblings. However, it lacks explicit 'when-not-to-use' or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_case_textAInspect
Get the staged plain text of a case's public court documents.
Long decisions can exceed 100 pages; the text is returned in chunks.
Use offset_chars from the previous response's next_offset to page
through. max_chars is capped at 50,000.
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No | ||
| package_id | Yes | ||
| offset_chars | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses chunked return and pagination behavior but omits auth needs, rate limits, or mutation safety.
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?
Three concise sentences convey purpose and pagination without redundancy. Each sentence adds value.
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?
No output schema; description does not specify return format (e.g., plain text string, next_offset field) or error handling, leaving gaps for a paging 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%. Description explains offset_chars and max_chars usage, but fails to describe the required package_id 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 the tool retrieves plain text of a case's public court documents. It distinguishes from siblings like 'get_case' (metadata) and 'fetch' (general).
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 pagination instructions using offset_chars and max_chars cap, but does not mention when to avoid using or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_filtersAInspect
List all valid filter values: canonical vaccine names (with case counts), condition categories, outcomes, special masters, and the dataset's date range. Call this before filtering so you use real values instead of guessing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully explains what the tool returns: a list of valid filter values. It implies a read-only operation, and no behavioral pitfalls are hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence states purpose, second provides actionable guidance. Front-loaded and efficient.
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 zero-parameter tool with no output schema, the description is fully complete: it explains what the tool does and why it should be used. No missing context.
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?
No parameters exist, so schema coverage is 100% trivially. The description does not need to add parameter meaning; baseline score of 4 applies.
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 all valid filter values, enumerating specific categories (vaccine names with case counts, condition categories, etc.), and explicitly distinguishes its purpose from guessing.
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 advises to call this before filtering to use real values, providing clear context for when to use. Does not mention when not to use or alternatives, but siblings are distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_special_masterBInspect
Decision patterns for one special master: outcome breakdown, top vaccines/conditions in their docket, and recent cases.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It states what data is returned but does not disclose behavioral traits such as read-only nature, authentication needs, rate limits, or potential side effects. Vague on safety considerations.
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?
Single sentence, front-loaded with core purpose. No redundant information; every word adds value.
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?
Lists three output categories, but no output schema exists. Agent may need more details on return structure (e.g., format of outcome breakdown). Adequate for a simple tool with 2 parameters, but could be improved.
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 coverage is 0%, so description must explain parameters. It does not clarify that 'name' is the special master's name or that 'limit' controls result count. Leaves agent guessing about parameter meaning.
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?
Description clearly states it provides decision patterns for a specific special master, including outcome breakdown, top vaccines/conditions, and recent cases. Distinguishes from sibling tools like 'get_attorney' or 'get_case' which focus on different entities.
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?
Implied usage for retrieving detailed data on one special master, but no explicit when-to-use or when-not-to-use compared to siblings like 'search' or 'get_statistics'. Lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statisticsAInspect
Aggregate statistics over the case corpus, optionally filtered.
group_by: vaccine | condition | outcome | year | special_master
Returns per-group: total cases, compensated count, compensation rate,
death count, and median award among compensated cases (awards over $10M
excluded from the median due to a known unit-extraction bug).
IMPORTANT framing: these describe the VICP case-record dataset, not
vaccine-safety rates in the general population.
| Name | Required | Description | Default |
|---|---|---|---|
| vaccine | No | ||
| group_by | No | vaccine | |
| is_death | No | ||
| pediatric_only | No | ||
| condition_category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses a known bug (awards over $10M excluded from median) and an important framing about dataset interpretation. Could mention read-only nature, but implied.
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?
Description is front-loaded with purpose, then group_by options, return fields, and important notes. Concise with no filler, but slightly lengthy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, description covers purpose and a bug but lacks explanations for most parameters and detailed output structure. Could be more 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?
Schema has 0% description coverage; description adds meaning by listing group_by options and return fields. However, other parameters (vaccine, is_death, etc.) are not explained, so not fully comprehensive.
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?
Description clearly states verb+resource ('Aggregate statistics over the case corpus') and distinguishes from sibling tools like get_case. Lists grouping options and return fields, making purpose unambiguous.
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?
Description implies aggregation use case and includes important framing about VICP dataset vs general safety rates. However, it does not provide explicit when-to-use or alternatives, 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.
searchAInspect
Search VICP vaccine-injury cases by free text. Returns result ids for use with fetch. (Alias of search_cases for deep-research clients; prefer search_cases when structured filters are available.)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses it returns only IDs for use with fetch, but does not explicitly state read-only behavior or other traits. For a search tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose, usage, and alias. No wasted 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?
Given the simple tool with one parameter and no output schema, the description provides sufficient context: what it does, what it returns, and when to use alternatives.
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?
Only one parameter 'query' with 0% schema description coverage. Description adds meaning by stating it's free text search, but lacks details on format, length, 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 it searches VICP vaccine-injury cases by free text and returns result IDs for fetch. Distinguishes from sibling tools like search_cases and search_attorneys.
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 says to use for free text search, and to prefer search_cases when structured filters are available. Also mentions it's an alias for deep-research clients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_attorneysAInspect
Search petitioner attorneys and firms by name. Returns per-attorney aggregate stats: case count, compensation rate, main vaccines, and firm. Useful for 'who has handled X cases' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return fields (case count, compensation rate, etc.) implying read-only behavior, but doesn't specify non-destructiveness or other traits.
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?
Three concise sentences: purpose, return data, and usage context. No superfluous content, front-loaded.
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?
No output schema; description lists key return fields (case count, compensation rate, main vaccines, firm). Missing details on limit parameter and pagination, but adequate for the tool's scope.
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%. The description adds meaning to the 'query' parameter by mentioning 'by name', but does not explain the 'limit' parameter or defaults.
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 petitioner attorneys and firms by name, and mentions the specific aggregate stats returned, distinguishing it from siblings like get_attorney or search_cases.
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 provides a concrete use case ('who has handled X cases' questions), implying when to use it, but does not explicitly differentiate from alternatives like get_attorney or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_casesAInspect
Search VICP cases with structured filters.
- query: free text matched against petitioner identifier, condition,
package id, caption name and the AI case summary.
- vaccine: canonical vaccine name (use get_filters() for valid values,
e.g. "Influenza (flu)", "DTaP/DPT", "MMR", "COVID-19", "Hepatitis B").
- condition_category / outcome: exact values from get_filters().
- pediatric_only uses the broad pediatric cohort definition
(is_minor OR is_minor_inferred OR age<18) — strict age-only filtering
undercounts pediatric cases substantially.
- dates are ISO strings (YYYY-MM-DD); awards are USD integers.
- sort: decision_date_desc|decision_date_asc|filed_asc|filed_desc|award_desc|award_asc
- Returns total match count plus one page of compact case records with
canonical URLs. Use get_case(package_id) for the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | decision_date_desc | |
| limit | No | ||
| query | No | ||
| offset | No | ||
| outcome | No | ||
| vaccine | No | ||
| attorney | No | ||
| filed_to | No | ||
| is_death | No | ||
| max_award | No | ||
| min_award | No | ||
| decided_to | No | ||
| filed_from | No | ||
| decided_from | No | ||
| autism_related | No | ||
| pediatric_only | No | ||
| special_master | No | ||
| condition_category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It explains the broad pediatric cohort definition and mentions return format. Does not discuss rate limits or auth, but the read-only nature is implied.
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 bullet points that are easy to scan. 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 the complexity (18 params, no output schema, no annotations), the description is thorough. It explains pediatric definition, return format, and points to get_filters. Could mention pagination behavior explicitly.
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 coverage is 0%, so description compensates. Explains query matching, vaccine names with examples, date formats, award units, and sort values. Not all 18 parameters are covered, but major filters are explained 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?
Clearly states 'Search VICP cases with structured filters.' Distinguishes from siblings like get_case (full record) and search. Lists return format: total match count plus compact records.
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 guidance on using get_case for full records and get_filters for valid values. Implicitly indicates when to use this tool vs. others, but could be more explicit about when not to use it.
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!