Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gatehouse-mcp Is postgres-mcp safe to install?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The Gatehouse registry, as an MCP server. Ask an agent, at the moment it's deciding what to install, "is this tool safe? what's out there? give me the audit" and get Gatehouse's hands-on verdict, live.
Gatehouse is a vetted, living registry of agent tooling (MCP servers, Claude Code skills, plugins, subagents, agent frameworks). Every listing is proven alive by a nightly liveness check, and vetted listings carry a first-hand audit of what the tool actually injects. This server puts that in an agent's tool list so it never has to guess.
Tool | Use it to… |
| Get the quick trust verdict for one tool: vetted / flagged / unvetted, the one-paragraph take, liveness, install line. The "is X safe to install?" call. |
| Get the full record: metadata, compat matrix, health, and the complete first-hand audit write-up. |
| Find tools in the registry, ranked vetted-first. |
tool accepts a slug (postgres-mcp) or a name (Playwright MCP).
Related MCP server: agentic-os-mcp
Claude Code:
claude mcp add gatehouse -- npx -y gatehouse-mcpAny MCP client (.mcp.json / claude_desktop_config.json):
{
"mcpServers": {
"gatehouse": {
"command": "npx",
"args": ["-y", "gatehouse-mcp"]
}
}
}On demand, it fetches https://agentgatehouse.com/registry.json (cached in-process for an hour),
so verdicts and liveness are always current, and the nightly liveness cron flows through
automatically, with no package update. If the network is unreachable it falls back to a snapshot
bundled in the package and says so in its answer. Point GATEHOUSE_REGISTRY_URL at a different
endpoint to override the source.
Gatehouse flags other tools for telemetry, broad scopes, and heavy context cost, so this server holds itself to the same bar:
Read-only. No tool writes, deletes, or mutates anything.
No telemetry. The only network request is the one disclosed fetch to agentgatehouse.com
for the registry itself. Nothing is sent about you, your agent, or your queries.
Minimal surface. Three tools, all read-only, about 525 always-on tokens per turn
(measured with Gatehouse's own audit script): the entire tool-definition footprint an agent
carries, versus roughly 16k for a 44-tool server. One runtime dependency
(@modelcontextprotocol/sdk, plus zod for schema validation).
No metered anything. Free to run; the registry endpoint is a static file.
npm audit reports 2 moderate advisories here, so here is the honest read rather than a silent
audit fix. Both trace to one transitive package: @hono/node-server below 2.0.5, pulled in by
@modelcontextprotocol/sdk, with a Windows-only path-traversal issue in its serve-static
helper (GHSA-frvp-7c67-39w9).
It is not reachable from this server. serve-static belongs to the SDK's HTTP and SSE
transports. gatehouse-mcp is stdio only (StdioServerTransport, one call site), never starts an
HTTP listener, and never serves a file. The package sits in the dependency tree without its
vulnerable path being callable.
It is also not currently fixable upward: @modelcontextprotocol/sdk@1.29.0 is the latest
release, and npm's suggested remediation is a downgrade to 1.24.3, which is both a breaking
change and older code. Declining that is the safer call. This note goes away when the SDK bumps
its own dependency.
If you would rather verify than take our word for it, that is the entire point:
npm ls @hono/node-server --all shows the path, and grep -rn "hono\|serveStatic" src/ returns
nothing.
MIT © Dave Maynard
The quick trust verdict for one agent tool: has Gatehouse hands-on vetted it, and what did it find? Call this at the moment of deciding whether to install/enable a tool. Returns the vetting status, the one-paragraph verdict, liveness, and the install line. For the full audit write-up use get_tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or name, e.g. "postgres-mcp" or "Playwright MCP" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses return fields (vetting status, verdict, liveness, install line) and aligns with annotations readOnlyHint=true, indicating safe read operation with 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?
Description is concise and front-loaded, using three sentences to convey purpose, usage, and output without extraneous detail.
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 simple tool with one parameter and no output schema, description adequately covers behavior and output; slight deduction for lacking example or return format details.
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 covers parameter with description ('Tool slug or name'), providing no additional meaning beyond schema; with 100% coverage, baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'quick trust verdict' on vetting status, using specific verbs 'check' and 'vetted', and distinguishes from sibling tool 'get_tool' which offers full audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this at the moment of deciding whether to install/enable a tool', and directs to 'get_tool' for full audit, though it doesn't explicitly forbid using it for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The complete Gatehouse record for one agent tool: metadata, compatibility, liveness/health, the vetting verdict, and — when it exists — the full first-hand audit write-up (how it was tested, what it injects, the caveats). Use check_tool instead if you only need the quick safe/not verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Tool slug or name, e.g. "postgres-mcp" or "Playwright MCP" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what data the tool returns, including conditional existence of an audit write-up. The readOnlyHint annotation aligns with the retrieval nature. No contradictions, though additional context like authentication or rate limits could further enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and usage guidance, with no superfluous words. The structure is front-loaded with the core function followed by the alternative.
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 single-parameter, read-only tool with no output schema, the description fully covers what the tool does and what data it provides. No missing context for agent decision-making.
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 parameter tool is documented in the schema with an example value. The description adds no further parameter semantics, but since schema coverage is 100%, a score of 3 is appropriate as the schema already handles the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as retrieving the complete Gatehouse record for one agent tool, listing the included components (metadata, compatibility, liveness, verdict, audit write-up). It distinguishes itself from the sibling check_tool by specifying that get_tool provides the full record, while check_tool gives only a quick verdict.
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 the agent when to use this tool versus the alternative: 'Use check_tool instead if you only need the quick safe/not verdict.' This provides clear context for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find agent tools (MCP servers, Claude Code skills, plugins, subagents, agent frameworks) in the Gatehouse registry. Filter by free-text query, category, kind, or vetting status. Returns a ranked list (vetted first) with each tool's status and health. Use get_tool for the full record or check_tool for a quick "is it safe" verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter to one kind of tool | |
| limit | No | Max results (default 25) | |
| query | No | Free text matched against name, summary, author, and categories | |
| status | No | Filter to a vetting status | |
| category | No | Filter to a category, e.g. "Databases" (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no contradiction. The description adds valuable behavioral context: returns a ranked list with vetted items first, includes status and health. It does not mention pagination behavior, but schema covers limit parameter.
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 zero fluff. Each sentence serves a purpose: first defines what the tool finds, second covers filtering, results, and sibling alternatives. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 5 parameters and no output schema, the description fully covers: tool scope, filter options, result format (ranked list, status, health), and when to use siblings. No gaps remain for an agent to understand its 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 description coverage is 100%, so baseline is 3. The description restates filter options (query, category, kind, status) and adds ranking behavior, but does not significantly elaborate on parameter syntax or constraints 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 finds agent tools (MCP servers, skills, plugins, subagents, frameworks) in the Gatehouse registry. It explicitly distinguishes from siblings by referencing get_tool for full records and check_tool for safety verdicts.
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 directly advises when to use this tool versus alternatives: 'Use get_tool for the full record or check_tool for a quick "is it safe" verdict.' This provides clear when-to-use and 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2check_toolget_toolsearch_toolsScored across 3 tools
Each tool has a distinct purpose: search_tools for discovery, check_tool for quick trust verdict, and get_tool for full audit details. No overlap in functionality.
Tools follow verb_noun pattern, but 'search_tools' uses plural while 'check_tool' and 'get_tool' are singular, introducing minor inconsistency.
Three tools are well-scoped for a read-only registry: search, quick check, and full retrieval. No unnecessary tools and no missing essentials.
Covers the complete lifecycle for a tool registry: discovery (search), quick assessment (check), and detailed record (get). No obvious gaps given the read-only domain.
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
Discover MCP servers, A2A agents, and shared agent knowledge through a read-only MCP gateway.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
