The evidence layer for MCP: live operational grades plus Trust Receipts for every registry server.
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.3/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: getting grades, detailed evidence, listing top servers, searching servers by task, searching tools, searching trust evidence, and submitting feedback. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_server_grade, search_servers, submit_feedback). The naming is predictable and uniform.
With 7 tools, the surface is well-scoped for a registry and evidence server. Each tool serves a distinct purpose, covering retrieval, search, and feedback submission without unnecessary bloat.
The tool set covers core operations (getting grades, search, feedback), but there are minor gaps: no tool to list all servers (only top graded) and no direct way to list tools for a specific server. These are workable but not fully complete.
get_server_gradeGet Server GradeAGet the full grade and verbatim probe evidence for one MCP server, by its official registry name (e.g. 'com.healthai/radar').
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Registry server name |
| Name | Required | Description |
|---|---|---|
| grade | Yes | |
| score | Yes | |
| version | No | |
| evidence | No | |
| repo_url | No | |
| probed_at | Yes | |
| reachable | No | |
| latency_ms | No | |
| remote_url | No | |
| tool_count | No | |
| description | No | |
| provisional | Yes | |
| server_name | Yes | |
| protocol_access | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns 'full grade and verbatim probe evidence', providing useful behavioral context beyond annotations.
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?
One clear, concise sentence with no wasted words. It front-loads the purpose and example.
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?
With an output schema available, the description sufficiently explains what is returned (grade and evidence). The tool is simple with one parameter, and the description covers the necessary 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?
The schema has 100% coverage for the single parameter 'name' with a basic description. The tool's description adds a concrete example ('com.healthai/radar'), enhancing understanding.
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 specific verb 'Get' and resource 'full grade and verbatim probe evidence', and distinguishes itself from siblings by focusing on a single server by registry name.
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 when you have the exact registry name, but does not explicitly state when not to use or mention alternatives like list_grades or search_servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trust_receiptGet Trust ReceiptAGet one MCP server's complete evidence receipt: operational grade, deterministic security/data-integrity/citation/claim observations, and reviewed real-usage field reports. Missing observations are explicitly unaudited, never treated as a pass.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Official registry server name |
| Name | Required | Description |
|---|---|---|
| server | Yes | |
| audit_state | Yes | |
| observations | Yes | |
| evidence_page | Yes | |
| interpretation | Yes | |
| trust_dimensions | Yes | |
| response_benchmarks | Yes | |
| reviewed_field_reports | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true) and non-destructive (destructiveHint=false). The description adds behavioral context by explicitly stating that missing observations are treated as unaudited, not as passes, which clarifies the interpretation of results beyond what annotations provide.
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: the first concisely states the tool's purpose and output components, and the second adds a critical nuance about missing observations. 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?
For a simple tool with one parameter and an existing output schema, the description covers the return value (components of receipt) and behavioral nuance (unaudited observations), making it complete for the agent's understanding.
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 (name) with 100% schema description coverage. The description adds no additional meaning beyond 'Get one MCP server's...', which is redundant with the schema's 'Official registry server name'. Baseline of 3 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 complete evidence receipt for an MCP server, listing specific components (operational grade, security/data-integrity/citation/claim observations, field reports), which distinguishes it from sibling tools like list_grades or search_trust_evidence.
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 a specific server's full trust receipt but lacks explicit guidance on when to use this versus alternatives, such as when to use list_grades for overviews or search_trust_evidence for specific evidence. No conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_gradesList Operational GradesAList the top graded MCP servers from the mcpqueen registry (deterministic probe grades with evidence). Returns grade, score 0-100, latency, tool count and auth state per server.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max servers to return (default 25, max 100) |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral context: deterministic probe grades with evidence, returning specific fields. No contradictions.
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, front-loaded with action, 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 output schema exists and parameters are simple, description covers purpose, return fields, and nature (deterministic, with evidence). Complete for agent usage.
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 100% coverage for the single parameter 'limit' with default and max. Description does not add beyond schema, but baseline 3 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?
Description clearly states it lists top graded MCP servers from the mcpqueen registry, with specific returned fields. Distinguishes from siblings like get_server_grade (single server) and search_servers (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?
Implied usage: use when you want a ranked list of top servers. No explicit when-not or alternatives, but sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_serversSearch MCP ServersASearch the MCP evidence registry using a natural multi-word task (e.g. 'reliable no-auth drug interaction server with citations'). Tokenizes and expands common synonyms, ranks metadata plus observed tool descriptions, and supports operational-grade/auth/latency/category filters. Use get_trust_receipt or search_trust_evidence for security, data, citation, claim, and response evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | Filter by authentication state (default any) | |
| limit | No | Max results (default 10, max 25) | |
| query | Yes | Keyword or task to search name/title/description for | |
| category | No | Optional category filter: Dev & Code, Data & Databases, Web & Search, AI & Agents, Finance & Crypto, Communication, Productivity, Security, Commerce, Media & Design, Cloud & Infra, Science & Health, Other | |
| minimum_grade | No | Worst acceptable live grade | |
| max_latency_ms | No | Maximum measured initialize latency in milliseconds |
| Name | Required | Description |
|---|---|---|
| message | No | |
| results | Yes | |
| feedback_reminder | Yes | |
| interpreted_terms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds details about tokenization, synonym expansion, and ranking, which are not in annotations. No contradictions.
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 two sentences: purpose with example in first, and process plus alternatives in second. No extraneous words, front-loaded with key 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 complexity (6 params, output schema exists), the description covers purpose, usage guidance, and behavioral details adequately. Lacks minor details like pagination but schema compensates.
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 100%, so parameters are well-documented. The description adds context beyond schema by explaining how the query is processed and grouping filters, enhancing understanding.
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 the MCP evidence registry using natural multi-word tasks, with specific features like synonym expansion and ranking. It distinguishes itself from siblings by specifying the registry and filters.
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 to use alternatives (get_trust_receipt, search_trust_evidence) for other evidence types, and gives a usage example. However, it doesn't fully differentiate from all siblings like search_tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_toolsSearch MCP ToolsASearch across the actual tools that graded MCP servers expose (their tool names and descriptions, captured live from tools/list) — not just server metadata. Use this when you need a specific capability or data type, e.g. 'get weather', 'query postgres', 'device recall', 'FDA 510k'. Returns the matching tools with the server that offers each, its grade, and the remote endpoint so you can connect directly.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | Filter by authentication state (default any) | |
| limit | No | Max matching tools (default 15, max 40) | |
| query | Yes | Capability, data type, or keyword to match against tool names and descriptions | |
| category | No | Optional server-category filter: Dev & Code, Data & Databases, Web & Search, AI & Agents, Finance & Crypto, Communication, Productivity, Security, Commerce, Media & Design, Cloud & Infra, Science & Health, Other | |
| minimum_grade | No | Worst acceptable live server grade | |
| max_latency_ms | No | Maximum measured initialize latency in milliseconds |
| Name | Required | Description |
|---|---|---|
| message | No | |
| results | Yes | |
| feedback_reminder | Yes | |
| interpreted_terms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe, non-destructive). The description adds context that the search operates on 'live' tool listings and returns matching tools with server details. It does not disclose any additional behavioral traits like rate limits or dependencies, but for a read-only search tool 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 a single, well-structured paragraph that front-loads the purpose, then gives usage guidance, and ends with output description. Every sentence contributes value with 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 tool has 6 parameters (all documented in schema) and an output schema, the description adequately explains the return format (matching tools with server, grade, endpoint). It covers all essential aspects for a search tool without leaving 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 100%, so the baseline is 3. The description does not repeat parameter details, which is appropriate given the schema is complete. It adds value with example queries but does not extend parameter meaning 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 searches actual tool names and descriptions from MCP servers, distinguishing it from sibling tools like search_servers which search server metadata. It also provides example queries, making the purpose immediately apparent.
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 tells when to use this tool ('when you need a specific capability or data type') and contrasts it with alternatives ('not just server metadata'). This provides clear guidance versus sibling tools like search_servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_trust_evidenceSearch Trust EvidenceASearch published MCP trust evidence and reviewed real-usage field reports. Use for questions such as which servers expose citations, have access caveats, make unverifiable corpus claims, or show security concerns. Returns verbatim observations with dates and source type, not a synthetic trust score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max evidence items (default 20, max 50) | |
| query | Yes | Evidence, claim, source, capability, caveat, or server keyword | |
| status | No | ||
| dimension | No |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| returned | Yes | |
| interpretation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. The description adds value by explaining the output nature: 'Returns verbatim observations with dates and source type, not a synthetic trust score.' No contradictions.
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 succinct sentences: first states purpose, second gives usage examples, third clarifies output. No wasted words. Front-loaded effectively.
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 and schema covers key parameters, the description provides sufficient context for an agent to understand when and how to use the tool. It covers behavioral traits (output type) and usage 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?
The input schema covers 2 of 4 parameters with descriptions (query and limit). The description does not elaborate on the enum parameters (status, dimension), though the example questions hint at dimensions. Schema coverage is 50%, so a baseline of 3 is appropriate; the description adds minimal additional param info.
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 MCP trust evidence and field reports, and gives specific example questions. This distinguishes it from siblings like get_server_grade and search_servers.
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 explicit example use cases ('Use for questions such as...'), which helps the agent decide when to invoke. It does not explicitly state when not to use, but the examples are clear enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackSubmit Field ReportAInspectSubmit a field report about an MCP server you have actually used (what worked, what failed, surprising behavior). Reports are quarantined for human review and never auto-published.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | The field report, 20-2000 chars, specific and factual | |
| agent_name | No | Optional: which agent/client is reporting | |
| server_name | Yes | Official registry name of the server the report is about |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | Yes | |
| server_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly, non-destructive; description adds that reports are quarantined for human review and never auto-published, giving valuable behavioral context beyond annotations.
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 fluff. First sentence states action and content; second explains outcome. Perfectly 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?
With only 3 simple parameters and an output schema present, the description fully covers what the tool does, what it accepts, and what happens to the report (quarantine). 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?
Schema description coverage is 100%, so the schema already documents parameters well. The description does not add extra meaning beyond the general purpose, so baseline score of 3 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 'Submit a field report about an MCP server' with specific content (what worked, what failed, surprising behavior). It distinguishes from sibling tools, which are all read/search operations, making the 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?
The description implies usage when you have used an MCP server and want to report, and sibling tools are all reads, so this is the only write tool. However, it does not explicitly state when not to use or provide alternatives, missing a chance for clearer guidance.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.