mcpproxy-go

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.64.0
Disambiguation5/5
Each tool has a clearly distinct purpose: three call variants for execution, registry listing, security management, cache reading, tool discovery, server search, and server management. No overlap or ambiguity between tools.
Naming Consistency4/5
Most tools follow a consistent verb_noun snake_case pattern (e.g., list_registries, read_cache). The three call_tool_* variants have a slightly different structure but are internally consistent. Minor deviation prevents a perfect score.
Tool Count5/5
9 tools is well-scoped for an MCP proxy server. The set covers discovery, execution, management, security, and pagination without being overwhelming or sparse.
Completeness5/5
The tool surface fully covers the domain: tool discovery, execution (read/write/destructive), server management, server search, security quarantine, and truncated response handling. No obvious gaps for the stated purpose.
Average 4.1/5 across 9 of 9 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 105 of 109 community issues answered or closed in the last 6 months
- 411 commits in the last 12 weeks
- Last stable release on September 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and description mentions quarantining/approving as destructive actions. The NOTE adds transparency about unquarantining limitations. However, details on side effects of each operation are missing.
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?
Very concise: two sentences plus a note, front-loaded with purpose. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers overall purpose but lacks per-operation details (e.g., return values, what each operation does). With no output schema, more specific descriptions for each operation would improve completeness.
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 baseline 3. Description enumerates operations but adds no additional semantic depth beyond the schema's parameter descriptions.
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?
Description clearly states the tool manages quarantine of MCP servers and tools to prevent TPAs, with specific operations listed. It distinguishes from siblings like call_tool_*, but does not explicitly contrast with all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like call_tool_read or retrieve_tools. The NOTE on unquarantining is a constraint but does not help choose among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool is read-only ('READ-ONLY tool'), but the annotations set destructiveHint=true, indicating potential destructive behavior. This is a clear contradiction. The description does not address or reconcile this inconsistency, nor does it disclose other behavioral traits like authorization needs or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear workflow and decision rule, front-loading the purpose. However, it is somewhat lengthy due to the list of keywords and examples. It could be slightly more concise, but the structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema, contradictory annotations), the description covers usage context well but fails to address the annotation contradiction or describe return values. It provides examples and decision rules but is incomplete in behavioral transparency.
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%, so the baseline is 3. The description does not add any additional meaning beyond what the schema provides. The parameters are fully described in the input schema itself, so the description adds no extra value for parameter semantics.
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 clearly states 'Execute a READ-ONLY tool' and provides a specific verb ('execute') and resource ('tool'). It distinguishes from siblings by specifying it's for tools whose names match read-related patterns like search, get, list, etc. The default choice statement further clarifies its role.
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 provides explicit usage guidelines: a workflow (call retrieve_tools first, use exact name), a decision rule with a comprehensive list of name patterns, examples, and a default choice instruction. It implicitly excludes destructive/write tools without naming them directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes a read-only retrieval operation, but annotations declare destructiveHint=true, creating a contradiction. Beyond this, the description does not add detail about pagination behavior or side effects.
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, front-loaded with purpose and usage, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic trigger and parameter source, but lacks information about return format (no output schema) and does not resolve the contradiction between read-only description and destructive annotation.
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 description adds only marginal context (e.g., where to find the key). The description does not explain limit/offset beyond their defaults and max.
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 clearly states the tool retrieves paginated data when a response is truncated, using a cache key. It distinguishes from unrelated siblings by specifying a unique trigger condition.
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 explicitly tells when to use the tool (after truncation) and how to obtain the cache key, but does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool is for searching and discovering, implying read-only behavior. However, annotations include both readOnlyHint=true and destructiveHint=true, which contradict each other and the description. This contradiction severely undermines behavioral transparency, as it's unclear whether the tool is safe or destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with a clear structure: a purpose statement followed by a workflow. It could be more concise (e.g., removing the emoji or slightly redundant phrasing), but overall it is focused and well-organized.
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 no output schema, the description explains that results include server URLs and repository information ready for use with upstream_servers. This is sufficient for the agent to understand the return value. However, it lacks details on pagination or limits, which are partially covered by the limit parameter description.
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%, so the schema already documents all four parameters. The description adds context about workflow but does not provide additional meaning for the parameters beyond what the schema offers. Baseline score of 3 applies.
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 clearly states the tool's purpose: to discover and search for MCP servers from known registries. It specifies the verb ('discover', 'search'), resource ('MCP servers'), and the outcome (finding servers to add as upstreams). It also distinguishes itself from sibling tools like list_registries and upstream_servers by describing the workflow.
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 provides explicit workflow guidance: '1) Call 'list_registries' first to see available registries, 2) Use this tool with a registry ID to search servers.' This tells the agent when and how to use the tool, including prerequisites and follow-up actions with upstream_servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds that it lists registries. However, the destructiveHint=true in annotations contradicts the non-destructive nature of listing, which is not addressed in the description.
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 concise sentences with an emoji, front-loaded with purpose, no superfluous text.
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 zero-parameter read tool with no output schema, the description fully explains its purpose and usage context relative to other tools.
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?
No parameters exist, and schema coverage is 100%. The description does not need to add parameter info; baseline 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?
Describes a specific verb ('list') and resource ('available MCP registries'), and distinguishes itself from sibling 'search_servers' by recommending its prior use.
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?
Explicitly states 'Use this FIRST' and explains its relationship with 'search_servers', but does not provide when-not-to-use guidance for other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true; description adds context that operations are irreversible/high-impact and emphasizes using exact names from retrieve_tools. No contradiction, but doesn't detail further behavioral traits like auth needs.
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 brief (3 sentences), front-loaded, and uses clear structure with numbered steps and a keyword list. No redundancy.
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?
The description covers workflow, decision rule, and required parameter. Missing some context like conflict resolution between args and args_json, but schema handles that. Adequate for a meta-tool.
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 has 100% coverage with detailed descriptions for all 5 parameters. The description adds no additional parameter information beyond what the schema provides.
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 clearly states it executes a destructive tool and provides a decision rule listing keywords for when to use, with examples. It distinguishes from siblings like call_tool_read and call_tool_write.
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 gives a workflow (call retrieve_tools first) and a decision rule based on tool name keywords, explicitly guiding when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds that this is a state-modifying caller. It explains the meta-calling nature but does not detail error handling or failure modes, which would 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a workflow, decision rule, and examples. It is slightly verbose but efficient in conveying necessary information. Could be slightly tighter.
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 tool's complexity as a meta-caller, the description covers workflow, parameter usage, and decision logic. However, it omits what the tool returns (varies by upstream tool) and potential error scenarios, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds extra guidance: preferring 'args' over 'args_json', the 'server:tool' format for 'name', and rationale for intent parameters. This goes beyond the schema's baseline.
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 clearly states 'Execute a STATE-MODIFYING tool', specifies a decision rule based on tool name verbs, and uses examples. This differentiates it from sibling tools like call_tool_destructive and call_tool_read.
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?
Explicitly provides a workflow (retrieve_tools first, use exact name), a decision rule listing verb triggers, and cautions against guessing server names. This fully guides the agent on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations provide readOnlyHint=true (read-only) and destructiveHint=true (contradictory internally), the description explains the tool's behavior well: it performs BM25 search, excludes quarantined servers, and returns results with annotations and call_with recommendations. It does not contradict annotations but adds context beyond them. The internal annotation contradiction is not reflected in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured and front-loaded with the most critical instruction. Each sentence provides useful information (usage guidance, search algorithm, result contents, exclusions, server addition). While it could be slightly more concise, the structured information justifies the length for an important tool discovery mechanism.
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 tool's complexity (5 parameters, no output schema, annotations present), the description covers purpose, usage guidelines, behavioral details, parameter usage, and related tools. It partially covers output by mentioning 'annotations' and 'call_with' recommendations. It could mention pagination or error handling, but the existing information is largely sufficient for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context for parameters: it explains that 'query' should be a natural language description with examples, that 'debug' enables ranking explanations, and how 'explain_tool' works in debug mode. This adds value beyond what the schema provides, justifying a 4.
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 clearly states the tool's purpose: 'CALL THIS FIRST to discover relevant tools!' It specifically identifies the action (retrieve tools), the resource (tools across all MCP servers), and the method (BM25 full-text search). It distinguishes itself from sibling tools by being the primary discovery mechanism and explicitly advises using it before calling any specific tools. The verb 'retrieve' combined with the explanatory text provides excellent clarity.
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 provides explicit guidance: 'Always use this before attempting to call any specific tools' and 'Use natural language to describe what you want to accomplish.' It also tells when not to use this tool (quarantined servers) and directs to alternatives: 'Use 'quarantine_security' tool to examine and manage quarantined servers' and 'Use 'list_registries' then 'search_servers' to find and add new MCP servers.' This clearly differentiates when to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: automatic quarantine for security, Docker isolation, smart merging for updates, and that unquarantining requires manual config. Annotations partially cover safety, but description adds critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, security note, Docker isolation, and smart patching examples. Slightly lengthy but each section adds value. Front-loaded with most important information.
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?
Fully covers tool complexity: all 12 parameters, 6 operations, security interactions, merging rules, and integration with quarantine tool. No output schema, so not required. Very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value with detailed operation-specific behavior, merging rules, and examples (e.g., env_json merge, args_json replace). Not perfect but exceeds baseline.
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 clearly states the tool manages upstream MCP servers with specific operations (add, remove, update, list). It distinguishes from siblings like quarantine_security 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives (e.g., quarantine operations go to quarantine_security). Explains each operation's use and provides examples for smart patching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcpproxy-go MCP server](https://glama.ai/mcp/servers/smart-mcp-proxy/mcpproxy-go/badges/card.svg)](https://glama.ai/mcp/servers/smart-mcp-proxy/mcpproxy-go)

Score Badge

Copy to your README.md:

[![mcpproxy-go MCP server](https://glama.ai/mcp/servers/smart-mcp-proxy/mcpproxy-go/badges/score.svg)](https://glama.ai/mcp/servers/smart-mcp-proxy/mcpproxy-go)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smart-mcp-proxy/mcpproxy-go'

If you have feedback or need assistance with the MCP directory API, please join our Discord server