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 | |
| safety_notice | 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 mark the tool as readOnly and non-destructive, but the description adds critical behavioral nuance: 'Missing observations are explicitly unaudited, never treated as a pass.' This tells the agent that absent evidence is not equivalent to a clean record—a key interpretation detail not available from annotations or schema.
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 long, with the first sentence front-loading the tool's purpose and contents, and the second providing a critical caveat. No fluff or redundant information; every word 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?
With a single parameter, an output schema present, and annotations for safety, the description covers the essential contextual elements: what the receipt contains, how to interpret missing observations, and that it's a read-only operation. No further explanation of return values is needed since an output schema exists.
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%, with the only parameter 'name' documented as 'Official registry server name.' The description does not add additional parameter semantics, but the schema already fully defines it, so the 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 uses a specific verb-resource pair ('Get one MCP server's complete evidence receipt') and enumerates the receipt's contents (operational grade, security/data-integrity/citation/claim observations, real-usage field reports). This clearly distinguishes it from sibling get_server_grade, which likely returns only the grade, by emphasizing the 'complete' receipt.
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 establishes clear context: use this tool when you need the full evidence receipt for a single MCP server. It does not explicitly name alternatives or exclusions, but the phrase 'complete evidence receipt' implies this is the comprehensive option versus more focused siblings. No explicit 'when not to use' guidance is given, so it falls just short of a 5.
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 | |
| safety_notice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, but the description adds behavioral context by stating grades are 'deterministic probe grades with evidence' and enumerating return fields (score, latency, tool count, auth state). This goes beyond the annotations and clarifies data provenance and ordering.
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 front-loads the main action and includes relevant return field details without redundancy. It is appropriately sized and structured for quick agent comprehension.
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 and an output schema, the description covers the source, ordering (top graded), and return fields. It is complete enough to support selection and invocation without ambiguity.
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 already fully documents the single limit parameter (default 25, max 100) at 100% coverage. The description does not add any extra meaning to the parameter, so it meets the baseline but doesn't exceed it.
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 top graded MCP servers from a specific registry, using the verb 'List' and specifying the resource and source. This distinguishes it from siblings like get_server_grade (single server) and search_servers (search semantics). It also includes details about deterministic grades and 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 use for obtaining a ranked list of top graded servers but does not explicitly mention alternatives or when not to use it. It lacks direct exclusions like 'use search_servers instead when filtering by name.' However, the purpose is clear enough to infer usage 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 | |
| safety_notice | Yes | |
| feedback_reminder | Yes | |
| interpreted_terms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral detail: tokenizing and expanding synonyms, ranking metadata plus observed tool descriptions, and supporting operational-grade/auth/latency/category filters. No contradiction.
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 sentence is front-loaded with purpose and example, second sentence gives alternative usage. No wasted words; all content contributes to understanding.
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 tool has an output schema and thorough annotations, plus a description covering behavior, filters, ranking logic, and alternative tools. This is complete for an agent to select 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?
Schema has 100% coverage of all 6 parameters with clear descriptions and enums. The description mentions filter types (auth/latency/category) and query expansion context, but it does not add substantial meaning beyond what the schema already documents.
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?
Specifically states 'Search the MCP evidence registry' with a natural multi-word task, clearly identifying the verb and resource. Differentiates from siblings like search_tools and search_trust_evidence by the registry scope and task-based approach.
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 direction: 'Use get_trust_receipt or search_trust_evidence for security, data, citation, claim, and response evidence.' This tells the agent when to choose alternatives, complementing the search use case.
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 | |
| safety_notice | Yes | |
| feedback_reminder | Yes | |
| interpreted_terms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: it searches live data from tools/list and returns the server, grade, and remote endpoint. This goes beyond the safety annotations, though it doesn't mention rate limits or auth specifics.
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 compact, front-loaded with the core purpose, and every sentence adds value—scope, usage examples, and return content. No fluff or 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?
For a search tool with six parameters and an output schema, the description covers the core functionality, the object being searched (tools vs servers), typical queries, and the result structure. The output schema handles return details, so nothing critical is missing.
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 all six parameters are documented in the schema. The description provides usage examples but does not add additional meaning beyond what the schema already states, so a 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 it searches across actual tools exposed by MCP servers, with examples like 'get weather' and 'query postgres'. It explicitly contrasts with 'server metadata', distinguishing it from sibling tools such as 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?
It explicitly says 'Use this when you need a specific capability or data type' and provides concrete examples. It implies not for server metadata, but does not explicitly name alternative tools or state when not to use, so it falls short of a 5.
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 | |
| safety_notice | Yes | |
| interpretation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that output is 'verbatim observations with dates and source type, not a synthetic trust score,' providing useful behavioral context beyond the 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?
The description is two sentences, front-loaded with purpose and followed by output scope. Every sentence adds value with no redundant phrasing.
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 annotations cover safety, the description adequately covers purpose, scope, and output nature. It does not detail all query/filter behaviors, but the tool is a search interface with clear intent and output characteristics.
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 cover query and limit, but status and dimension have no descriptions. The description's example questions add context for query, but does not explain enum semantics for the other two parameters. With 50% schema coverage, some compensation exists but it is incomplete.
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 ('Search') and resource ('published MCP trust evidence and reviewed real-usage field reports'). It distinguishes from siblings by clarifying that it returns evidence, not grades or synthetic scores, and provides concrete example questions it can answer.
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 evidence-gathering questions and explicitly contrasts with synthetic trust scores, guiding when to use it for verbatim observations. It does not name alternatives or 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.
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 | |
| safety_notice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond annotations: reports are 'quarantined for human review and never auto-published.' This informs the agent that submission does not lead to immediate public visibility, which is a useful non-obvious trait. No contradiction with 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?
The description is two sentences long, front-loaded with the action and resource, and ends with a clear behavioral disclaimer. Every word earns its place; no redundant or filler content.
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 submission tool with a provided output schema, the description is sufficient. It covers what the report is about, the submission action, and the quarantine behavior. It doesn't mention post-review outcomes, but that is not necessary given the output schema exists.
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 explains each parameter well (report, agent_name, server_name). The description does not add any param-specific details, but the existing schema coverage justifies a baseline score of 3.
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 a specific verb ('Submit') and resource ('field report'), and defines the scope ('about an MCP server you have actually used'). It distinguishes the tool from its siblings, which are all search/get operations, by focusing on reporting feedback.
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 gives a clear condition for use: 'you have actually used' a server, implying this tool is for real experience, not hypotheticals. It doesn't explicitly mention alternatives, but the sibling tools are all read-only, making the intended context unambiguous.
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.