Pod

by io.github.Marvy101

Server Details

Search and share firsthand reviews of products, APIs, services, places, and organizations.

Ownership verified

Status: Unhealthy
OAuth: Works in Glama
Last Tested: 2026-09-06 08:34
Transport: Streamable HTTP
URL

Available Tools

5 tools

feedbackGive Pod feedbackAInspect

Record private product feedback inside Pod about whether results helped or what capability was missing. This does not send a message or publish content. Available without sign-in.

ParametersJSON Schema

Name	Required	Description
`kind`	Yes	Use helpful when Pod aided the task, or improvement when Pod lacked a needed capability.
`score`	No	Optional usefulness score from 1 (not useful) to 5 (extremely useful).
`message`	Yes	Concise explanation of what helped or what Pod should improve.
`resultIds`	No	Subject or Observation IDs that directly influenced this feedback.
`perspective`	No	Whose experience the feedback describes: the acting Agent or the Human it serves.
`interactionId`	Yes	Interaction ID returned by the Pod search, fetch, or write being evaluated.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Stable Pod Feedback ID.
`ok`	Yes	Confirms that Pod recorded the feedback.
`kind`	Yes	Kind of feedback that Pod recorded.
`groupId`	No	Stable group for similar improvement requests when applicable.
`message`	Yes	Concise confirmation of what Pod recorded.
`supportCount`	No	Distinct actors supporting this improvement request when applicable.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful behavioral context beyond the annotations: it clarifies the feedback is private, records rather than publishes, has no messaging side effect, and works without sign-in. This usefully scopes the tool's behavior without contradicting 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each earning its place: what the tool does, what it does not do, and an availability caveat. The primary purpose is front-loaded and there is no wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with a fully described schema, an output schema, and clear annotations, the description covers the non-obvious context: privacy, lack of publishing side effects, and no sign-in requirement. An agent has what it needs 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage with descriptions for all six parameters, so the description need not repeat them. The reminder about 'results helped' and 'capability missing' loosely maps to the kind enum, but adds minimal value over the schema's own parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Record'), a specific resource ('private product feedback inside Pod'), and a clear scope ('whether results helped or what capability was missing'). It is immediately distinguishable from sibling tools like search and fetch, which retrieve information rather than record feedback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly positions the tool as the feedback-recording action and states what it does not do ('does not send a message or publish content'), providing a useful when-not boundary. It does not explicitly name an alternative tool for sending/publishing, but the context is sufficiently clear for an agent to know when feedback is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetchRead the full reviewA

Read-onlyIdempotent

Inspect

Open the complete review or subject page from a Pod search result when the preview is not enough.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Exact Subject or Observation ID returned by a Pod search result.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes	Complete public Subject or Observation returned by Pod.
`interactionId`	Yes	Stable ID for this fetch, used when sending Pod feedback.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the tool as read-only, idempotent, and non-destructive, lowering the burden on the description. The description adds useful behavioral context: this opens a fuller page than a preview and is tied to Pod search result IDs. No contradiction with annotations is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence conveys the action, resource, origin, and condition without redundancy. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one well-documented required parameter, an output schema, and annotations covering safety and idempotence, the description provides sufficient context for an agent to decide when and how to use this tool. No critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the id parameter already described as the exact Subject or Observation ID from a Pod search result. The description reinforces this source but does not add meaning beyond the schema, 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Open'), a specific resource ('complete review or subject page'), and a clear source ('from a Pod search result'). It also distinguishes itself from preview-style siblings by emphasizing completeness, making the tool's role easy to identify.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'when the preview is not enough' provides a clear trigger condition for using this tool. It does not explicitly name alternatives or exclusions, but the context of a Pod search result strongly implies this is the follow-up to a search/preview workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_mcpFind MCP serversA

Read-onlyIdempotent

Inspect

Find canonical MCP servers by task, claimed or observed capability, name, source directory, client compatibility, transport, authentication posture, or deployment kind. Results stay compact, directory provenance remains separate from compatibility, and observed capabilities remain separate from upstream claims; use inspect_mcp for full evidence.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum canonical MCPs to return, from 1 to 10.
`query`	Yes	Task, capability, MCP name, description text, claimed tool, or Pod-observed tool to search for.
`client`	No	Require an upstream works-with claim, such as claude, claude-code, claude-desktop, or claude-api.
`directory`	No	Require a current listing sourced directly from Claude's MCP directory. This is provenance, not a client compatibility claim.
`transport`	No	Require this claimed remote transport.
`authPosture`	No	Require this claimed authentication posture.
`deploymentKind`	No	Require this claimed deployment kind.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of canonical MCPs returned.
`results`	Yes	Ranked compact canonical MCP matches.
`guidance`	No	Present when no indexed MCP matches the query and filters.
`interactionId`	Yes	Stable ID for this directory search, used when sending Pod feedback.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond those: results stay compact, directory provenance is separate from compatibility, and observed capabilities are separate from upstream claims. This tells the user that results may filter by provenance and that observed capabilities are distinguished from claimed ones—valuable semantic detail not in the annotations. It doesn't describe pagination or error behavior, but given the safety annotations and output schema, a 4 is reasonable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states scope and search dimensions; the second layers in the key caveats and routes to inspect_mcp. Every clause earns its place, no repetition of schema details, and the important routing instruction is placed at the end where it completes the behavioral contract. It is concise without being underspecified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, idempotent search tool with a 100%-documented schema and a JSON output schema, the description is complete. It states what can be searched, the key semantic distinctions (provenance vs. compatibility, observed vs. claimed), and when to escalate to inspect_mcp. An agent has everything needed to decide whether to call this tool and how to use its constraints appropriately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each of the seven parameters having a clear description including enum values and special semantics (e.g., directory being 'provenance, not a client compatibility claim'). The tool description adds high-level context about separation of provenance from compatibility, but it does not add syntax-level detail per parameter beyond what the schema provides. Baseline 3 applies since the schema carries the full load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Find' with a clear resource ('canonical MCP servers') and enumerates the search dimensions: task, capability, name, source directory, client compatibility, transport, auth posture, and deployment kind. It distinguishes the tool from inspect_mcp by explicitly stating that use inspect_mcp for full evidence, and the sibling list confirms inspect_mcp exists as the evidence-deep counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool vs the alternative: 'use inspect_mcp for full evidence.' It also conveys that results stay compact and that provenance and observed capabilities are separated from upstream claims, implying this tool is for discovery and quick filtering while inspect_mcp is for deeper verification. This gives the agent clear selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_mcpInspect an MCP serverA

Read-onlyIdempotent

Inspect

Inspect one canonical MCP from find_mcp, including distinct upstream claims, deployments, Pod-observed tools, and selected decision-useful GitHub issues. GitHub reports remain separate from firsthand Pod observations.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Exact canonical MCP ID returned by find_mcp.
`query`	No	Optional problem or question used to rank and filter issue reports.
`issueLimit`	No	Maximum decision-useful GitHub issues to return, from 1 to 20.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	No	Canonical MCP record. Omitted when the ID is unknown or is not an MCP.
`interactionId`	Yes	Stable ID for this inspection, used when sending Pod feedback.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that the tool is read-only, idempotent, and non-destructive, so the description does not need to repeat those. It adds value by disclosing what the inspection includes and by clarifying a data-provenance nuance: GitHub reports are kept separate from firsthand Pod observations. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with no filler. The first sentence front-loads the action, input source, and output categories; the second sentence adds a useful caveat about data separation. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema, complete parameter schema, and safety annotations, this description is sufficient. It tells the agent what the tool does, what it returns, and the key provenance distinction, while leaving detailed field semantics to the schema where they already exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already has a clear description, especially the required id ('Exact canonical MCP ID returned by find_mcp'). The tool description does not add extra parameter-level meaning beyond that, 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Inspect'), a specific resource type ('one canonical MCP from find_mcp'), and enumerates the exact content categories returned: upstream claims, deployments, Pod-observed tools, and GitHub issues. This clearly differentiates inspect_mcp from the discovery-oriented find_mcp and other siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than explicit: the description says the server comes 'from find_mcp', suggesting the agent should call find_mcp first and then inspect one canonical result. However, it never explicitly states when to prefer this tool over search, fetch, or feedback, nor does it include 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.

searchSearch reviewsA

Read-onlyIdempotent

Inspect

Search what people and agents actually experienced with a product, API, service, place, organization, or anything else. Use this before choosing, buying, integrating, visiting, or recommending something. Anonymous searches return at most five results.

ParametersJSON Schema

Name	Required	Description
`type`	No	Restrict Subjects to one active PascalCase Subject Type, such as DeveloperTool.
`limit`	No	Maximum results to return, from 1 to 5.
`query`	No	Natural-language or keyword query matched against public Subject names and Observation text.
`subjectId`	No	Restrict results to one exact Subject ID returned by Pod.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of results returned in this response.
`results`	Yes	Ranked public Pod results.
`guidance`	No	Present only when nothing matched. Explains that an empty result is a gap in the shared corpus rather than a signal about the Subject, and invites the agent to contribute a firsthand observation.
`interactionId`	Yes	Stable ID for this search, used when sending Pod feedback.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds useful behavioral detail beyond the annotations, particularly that anonymous searches return at most five results. This supplements the read-only and idempotent hints without contradicting them, although it does not describe response structure or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded. Each sentence adds a distinct piece of information: what is searched, when to use it, and the anonymous result limit. No filler or redundant wording is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and the annotation set is comprehensive, the description covers the necessary context for using the tool. It lacks explicit guidance on when not to use it, but the simple parameter set and clear purpose make it sufficiently complete for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description does not add meaningful parameter-level details beyond what is in the schema, and the mention of an anonymous limit is more of a behavioral note than parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's function: searching what people and agents experienced with various subjects, which matches the title 'Search reviews'. It specifies a concrete verb and broad resource scope, but it does not explicitly differentiate itself from sibling tools like feedback or find_mcp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage context: 'Use this before choosing, buying, integrating, visiting, or recommending something.' This tells an agent when the tool is appropriate, though it does not specify when not to use it or name alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updateSep 5, 2026

Changedfind_mcp20 fields changed

addedInput schema / properties / directory

Added value: +{
+  "description": "Require a current listing sourced directly from Claude's MCP directory. This is provenance, not a client compatibility claim.",
+  "enum": [
+    "Claude"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / results / description

Previous value: -"Ranked canonical MCP matches."New value: +"Ranked compact canonical MCP matches."

addedOutput schema / properties / results / items / properties / availability

Added value: +{
+  "additionalProperties": false,
+  "description": "Latest measured availability. Omitted when Pod has not measured this MCP.",
+  "properties": {
+    "observedAt": {
+      "description": "ISO timestamp of the latest availability measurement.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Latest availability outcome measured directly by Pod.",
+      "enum": [
+        "ok",
+        "auth_required",
+        "configuration_required",
+        "empty_tools",
+        "protocol_error",
+        "startup_error",
+        "unreachable",
+        "timeout",
+        "rate_limited"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "observedAt"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / results / items / properties / categories

Removed value: -{
-  "description": "Deduplicated categories claimed by upstream directories.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedOutput schema / properties / results / items / properties / claimedTools

Removed value: -{
-  "description": "Tool names claimed by upstream directories; these are not live probe results.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

addedOutput schema / properties / results / items / properties / connection

Added value: +{
+  "additionalProperties": false,
+  "description": "Best current actionable remote, package, or extension connection claimed by an upstream directory.",
+  "properties": {
+    "authPosture": {
+      "description": "Claimed authentication posture, such as no_auth or auth_required.",
+      "type": "string"
+    },
+    "endpointUrl": {
+      "description": "Fixed remote MCP endpoint when the source publishes one.",
+      "format": "uri",
+      "type": "string"
+    },
+    "kind": {
+      "description": "How this upstream source says the MCP is deployed.",
+      "enum": [
+        "fixed_remote",
+        "dynamic_remote",
+        "source_scoped_remote",
+        "package",
+        "local_extension"
+      ],
+      "type": "string"
+    },
+    "packageIdentifier": {
+      "description": "Installable package identifier.",
+      "type": "string"
+    },
+    "packageRegistry": {
+      "description": "Package registry, such as npm or pypi.",
+      "type": "string"
+    },
+    "packageVersion": {
+      "description": "Package version claimed by the source.",
+      "type": "string"
+    },
+    "transport": {
+      "description": "Claimed MCP transport, such as streamable-http or sse.",
+      "type": "string"
+    },
+    "urlPattern": {
+      "description": "Tenant-specific endpoint pattern when no single URL exists.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "kind"
+  ],
+  "type": "object"
+}

removedOutput schema / properties / results / items / properties / deployments

Removed value: -{
-  "description": "Remote, package, or local deployment options claimed upstream.",
-  "items": {
-    "additionalProperties": false,
-    "properties": {
-      "authPosture": {
-        "description": "Claimed authentication posture, such as no_auth or auth_required.",
-        "type": "string"
-      },
-      "endpointUrl": {
-        "description": "Fixed remote MCP endpoint when the source publishes one.",
-        "format": "uri",
-        "type": "string"
-      },
-      "kind": {
-        "description": "How this upstream source says the MCP is deployed.",
-        "enum": [
-          "fixed_remote",
-          "dynamic_remote",
-          "source_scoped_remote",
-          "package",
-          "local_extension"
-        ],
-        "type": "string"
-      },
-      "packageIdentifier": {
-        "description": "Installable package identifier.",
-        "type": "string"
-      },
-      "packageRegistry": {
-        "description": "Package registry, such as npm or pypi.",
-        "type": "string"
-      },
-      "packageVersion": {
-        "description": "Package version claimed by the source.",
-        "type": "string"
-      },
-      "transport": {
-        "description": "Claimed MCP transport, such as streamable-http or sse.",
-        "type": "string"
-      },
-      "urlPattern": {
-        "description": "Tenant-specific endpoint pattern when no single URL exists.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "kind"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

changedOutput schema / properties / results / items / properties / description / description

Previous value: -"Best current description claimed by an upstream directory."New value: +"One-sentence description from a current upstream directory."

addedOutput schema / properties / results / items / properties / description / maxLength
```
Added value: +240
```

addedOutput schema / properties / results / items / properties / directories

Added value: +{
+  "description": "Compact names of current upstream directories listing this MCP.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / results / items / properties / matches

Added value: +{
+  "description": "Up to three capabilities explaining why this MCP matched.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "capability": {
+        "description": "Capability that matched the search task.",
+        "type": "string"
+      },
+      "evidence": {
+        "description": "Evidence boundary: Observed came from Pod's tools/list measurement; Claimed and Category came from an upstream directory.",
+        "enum": [
+          "Observed",
+          "Claimed",
+          "Category"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "capability",
+      "evidence"
+    ],
+    "type": "object"
+  },
+  "maxItems": 3,
+  "type": "array"
+}

removedOutput schema / properties / results / items / properties / measurements

Removed value: -{
-  "description": "Pod measurements kept separate from publisher claims, including exact observed tools.",
-  "items": {
-    "additionalProperties": false,
-    "properties": {
-      "authScheme": {
-        "description": "Authentication scheme advertised by a gated endpoint.",
-        "type": "string"
-      },
-      "checkedAt": {
-        "description": "ISO timestamp of the measurement.",
-        "type": "string"
-      },
-      "endpointUrl": {
-        "description": "Exact remote endpoint measured by Pod.",
-        "format": "uri",
-        "type": "string"
-      },
-      "latencyMs": {
-        "description": "End-to-end measurement latency in milliseconds.",
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "observedToolCount": {
-        "description": "Count returned by the complete tools/list walk.",
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "observedTools": {
-        "description": "Tool names returned directly by paginated tools/list.",
-        "items": {
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "outcome": {
-        "description": "Measured outcome. Gated/configuration-required is not an empty or broken server.",
-        "enum": [
-          "ok",
-          "auth_required",
-          "configuration_required",
-          "empty_tools",
-          "protocol_error",
-          "startup_error",
-          "unreachable",
-          "timeout",
-          "rate_limited"
-        ],
-        "type": "string"
-      },
-      "packageIdentifier": {
-        "description": "Exact package identifier measured by Pod.",
-        "type": "string"
-      },
-      "packageRegistry": {
-        "description": "Exact package registry measured by Pod.",
-        "type": "string"
-      },
-      "packageVersion": {
-        "description": "Pinned package version measured by Pod.",
-        "type": "string"
-      },
-      "protocolVersion": {
-        "description": "MCP protocol version negotiated during initialization.",
-        "type": "string"
-      },
-      "serverName": {
-        "description": "Name returned by the server's own initialize handshake.",
-        "type": "string"
-      },
-      "serverVersion": {
-        "description": "Version returned by the server's own initialize handshake.",
-        "type": "string"
-      },
-      "targetKind": {
-        "description": "What Pod connected to or executed.",
-        "enum": [
-          "remote",
-          "package"
-        ],
-        "type": "string"
-      },
-      "transport": {
-        "description": "Transport that successfully carried this measurement.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "targetKind",
-      "outcome",
-      "checkedAt",
-      "observedTools"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

removedOutput schema / properties / results / items / properties / reportSummary

Removed value: -{
-  "additionalProperties": false,
-  "description": "Counts of selected decision-useful GitHub issues. Internal engineering tickets are excluded.",
-  "properties": {
-    "decisionUseful": {
-      "description": "Current GitHub issues useful for choosing, installing, integrating, or troubleshooting this MCP.",
-      "maximum": 9007199254740991,
-      "minimum": 0,
-      "type": "integer"
-    },
-    "external": {
-      "description": "Decision-useful reports opened by external users or contributors.",
-      "maximum": 9007199254740991,
-      "minimum": 0,
-      "type": "integer"
-    },
-    "maintainer": {
-      "description": "Decision-useful user-visible bugs documented by maintainers.",
-      "maximum": 9007199254740991,
-      "minimum": 0,
-      "type": "integer"
-    }
-  },
-  "required": [
-    "decisionUseful",
-    "external",
-    "maintainer"
-  ],
-  "type": "object"
-}

removedOutput schema / properties / results / items / properties / sources

Removed value: -{
-  "description": "Current upstream listings kept separate by source.",
-  "items": {
-    "additionalProperties": false,
-    "properties": {
-      "documentationUrl": {
-        "description": "Documentation URL published upstream.",
-        "format": "uri",
-        "type": "string"
-      },
-      "key": {
-        "description": "Stable Pod key for the upstream directory.",
-        "type": "string"
-      },
-      "listingName": {
-        "description": "Name used by this upstream listing.",
-        "type": "string"
-      },
-      "name": {
-        "description": "Human-readable upstream directory name.",
-        "type": "string"
-      },
-      "repositoryUrl": {
-        "description": "Explicit source repository URL published upstream.",
-        "format": "uri",
-        "type": "string"
-      },
-      "verifiedTier": {
-        "description": "Verification tier claimed by this upstream source.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "key",
-      "name",
-      "listingName"
-    ],
-    "type": "object"
-  },
-  "type": "array"
-}

removedOutput schema / properties / results / items / properties / url

Removed value: -{
-  "description": "Public Pod directory page when available.",
-  "format": "uri",
-  "type": "string"
-}

removedOutput schema / properties / results / items / properties / verificationStatus

Removed value: -{
-  "description": "Whether Pod has verified the canonical MCP identity.",
-  "enum": [
-    "Unverified",
-    "Verified"
-  ],
-  "type": "string"
-}

removedOutput schema / properties / results / items / properties / website

Removed value: -{
-  "description": "Canonical website when known.",
-  "format": "uri",
-  "type": "string"
-}

removedOutput schema / properties / results / items / properties / worksWith

Removed value: -{
-  "description": "Clients claimed compatible by upstream directories.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

changedOutput schema / properties / results / items / required

Previous value: -[
-  "id",
-  "name",
-  "verificationStatus",
-  "sources",
-  "categories",
-  "worksWith",
-  "claimedTools",
-  "measurements",
-  "deployments",
-  "reportSummary"
-]New value: +[
+  "id",
+  "name",
+  "matches",
+  "directories"
+]

addedOutput schema / properties / results / maxItems
```
Added value: +10
```

5 tool updatesSep 5, 2026
- First observedfeedback
- First observedfetch
- First observedfind_mcp
- First observedinspect_mcp
- First observedsearch

Frequently Asked Questions

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, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- 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.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

review-intelligence-mcp-server A
com.thenextgennexus
G2, Trustpilot, Yelp reviews with sentiment and theme extraction across sources.
Research & Data AI & Machine Learning
32
monitoringOAuth
com.repuso
Google reviews API - fetch reviews from Google, Trustpilot, TripAdvisor, G2 + 50 platforms
Monitoring Web Scraping Product Management
1
value-us A
io.github.Densys
Verified deals, store policies & a trust score for thousands of online retailers. No auth.
E-commerce & Retail Search
32
acopioOAuth
dev.acopio
Search and get recommendations from your own saved catalog of developer tools and services.
Developer Tools Search Knowledge & Memory
2

Related MCP Servers

GYIBB
Search E-commerce & Retail
Patheras
F
license
Not graded
quality
C
maintenance
Provides cited product-review verdicts synthesised from real user voices across multiple platforms, enabling AI agents to query live opinions with ratings, pros/cons, and confidence tiers.
Updated 22 days ago (2026-08-14 21:58 UTC)
-
preflight-mcp
Monitoring API Testing Observability
gsmethells
A
license
A
quality
Not graded
maintenance
TrustPilot for APIs, built for AI agents. Independent reliability ratings for APIs and MCP servers — look up trust scores, compare providers side by side, and leave reviews from real agent traffic.
Updated 5 months ago (2026-03-22 07:37 UTC)
3
1
-
TrustRadius Reviews MCP Server
Web Scraping Research & Data
johnisanerd
F
license
Not graded
quality
B
maintenance
Enables querying TrustRadius B2B software reviews to extract alternatives considered, feature-level ratings, pros/cons, and business outcomes for competitive intelligence.
Updated a day ago (2026-09-05 05:10 UTC)
-
daxoom
Search E-commerce & Retail Location Services
CITROOT
F
license
Not graded
quality
D
maintenance
The owner-verified local business data + service & menu-price layer for AI agents. Owner-authored business profiles where every response carries provenance — verification level, completeness score, freshness timestamps, and upstream sources. * Search & profiles — find businesses by name, category, city, or geo-radius; full profiles with contacts, hours, media, ratings. * Price layer
Updated 3 months ago (2026-06-19 16:27 UTC)
-

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Most tools have clearly distinct purposes: search handles general experience queries, find_mcp/inspect_mcp are MCP-server-specific, fetch opens detail pages, and feedback records private input. The only mild overlap is between search and find_mcp, but their descriptions make the intended domain difference clear.

Naming Consistency4/5

All tool names are lowercase imperative verbs, which gives the set a recognizable command-like style. The two MCP-specific tools use the consistent verb_mcp suffix, while the others are single-word verbs, so the pattern is mostly consistent with minor structural variation.

Tool Count5/5

Five tools is a well-scoped number for a Pod discovery platform covering search, fetch, MCP directory lookup, inspection, and feedback. Each tool serves a distinct user need without unnecessary bloat or redundancy.

Completeness4/5

The set covers the core read/discovery workflow: search experiences, fetch full pages, find and inspect MCP servers, and provide feedback. Obvious gaps are limited—there is no explicit way to submit an experience or publish content, but feedback partially covers contribution.

Resources

Need Help?