mcporter-bridge

by Citrus086

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool maps to a distinct phase of the MCP lifecycle: listing, exploring, calling, status checking, and activation/deactivation. There is no functional overlap between them, making selection unambiguous.
Naming Consistency4/5
All tools share the mcporter_ prefix and most follow a verb_noun pattern (list_servers, call_tool, activate_mcp, deactivate_mcp). However, 'help' and 'status' are single verbs/nouns that deviate slightly from the pattern.
Tool Count5/5
Six tools is an ideal number for a bridge server, covering the full management lifecycle without unnecessary bloat. Each tool has a clear and necessary role.
Completeness5/5
The tool set provides a complete workflow: discover available MCPs, activate large ones on demand, inspect tool schemas, call tools, and deactivate to free context. Status diagnostics round out the surface, so no critical operations are missing.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions 'frees context' as a high-level effect, but does not explain side effects such as impact on active sessions, permissions required, or the role of the timeout_ms parameter. This is insufficient for a mutation-like tool.
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 short and front-loaded with the primary purpose, includes a parameter explanation, and provides a concrete example. It earns high marks for brevity, though it could be slightly more structured by separating the effect from parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema, return values need not be described. However, the description lacks key context such as the timeout parameter's function, prerequisites, or consequences of deactivation. The inclusion of sibling tools suggests a management workflow, but this description does not fully position the tool within that workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'name' parameter and gives an example, but it completely omits the 'timeout_ms' parameter, leaving its purpose and behavior undocumented. This is a significant gap.
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 states the action ('deactivate MCP') and the resource, and it distinguishes from sibling tools like activate_mcp by the verb 'deactivate'. However, it adds the qualifier 'large' which is somewhat ambiguous but does not obscure the core purpose.
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?
The description implies usage ('to free context') and provides an example, but it does not explicitly state when to use this tool versus alternatives like activate_mcp or list_servers. No exclusion criteria or alternative references are given.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It clarifies that arguments must be a JSON object and directs to help, but does not disclose side effects, permissions, error behavior, or whether the call is read-only or mutating.
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, with a compact parameter list, an example, and a critical warning. Every sentence adds value and there is no redundant information.
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 generic nature of a remote tool-call function, the description provides the essential information: server and tool names, arguments formatting, and a pointer to details via mcporter_help. The output schema exists for return values, so lack of return details is acceptable. It does not mention timeout or output format, but these are covered by schema defaults.
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 0%, so the description must compensate. It adds meaning for server_name, tool_name, and arguments, including an example and the JSON-object requirement. However, it omits timeout_ms and output_format, which are only documented via schema defaults.
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 states the tool calls a tool on a specified server, using a specific verb and resource. It is distinct from sibling tools like listing servers or managing activation, but does not explicitly differentiate itself by naming an alternative.
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?
The description gives a clear prerequisite: use mcporter_help to query parameter format. It also provides an example, but lacks explicit when-not-to-use instructions or mention of alternative tools.
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?
With no annotations, the description carries the full burden. It states 'activate' (a mutation) and mentions a confirmation step, but it does not disclose side effects, reversibility, permissions, or what the activation actually changes. This is minimal behavioral disclosure.
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 and front-loaded: purpose, a post-requisite, parameter explanation, and an example—all in three concise sentences with no filler. Every sentence earns its place.
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 tool is simple and there is an output schema (so return values need not be described). The description covers purpose and the name parameter, but leaves timeout_ms unexplained and lacks details on activation behavior. It is adequate but has clear gaps.
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 0%. The description explains that 'name' is taken from mcporter_list_servers().available, which adds meaning. However, the timeout_ms parameter is not addressed at all, leaving one of two parameters undocumented. Partial compensation only.
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: '激活一个大型 MCP' (activate an MCP), which is a specific verb+resource. It distinguishes from siblings like mcporter_deactivate_mcp and mcporter_list_servers. The example also reinforces the intended 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?
The description provides clear usage context: the name parameter must be obtained from mcporter_list_servers().available, and after activation, one should re-call mcporter_list_servers to confirm. It does not explicitly exclude alternatives, but the post-activation step gives actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what each action does but does not state whether the tool makes any changes, requires specific permissions, or has side effects. The name and actions imply read-only status checks, but this is not explicitly asserted.
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 well-structured: a one-sentence purpose, a clear action list, and two usage examples. Every sentence adds value without redundancy, and the front-loaded summary ensures quick comprehension.
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?
For a simple status tool with two parameters and an output schema, the description covers the primary behavior and the main action parameter adequately. The missing timeout_ms explanation is a minor gap, but overall the agent has enough context to use the tool correctly, especially since the output schema likely covers return values.
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 provides no descriptions (0% coverage), so the description must compensate. It thoroughly explains the 'action' parameter's two enum values and the default, but completely omits any explanation of the 'timeout_ms' parameter, leaving its purpose and usage undocumented.
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?
Description clearly states 'check mcporter status and configuration' with a specific verb and resource. It further enumerates two distinct actions (doctor and version) with examples, making its purpose unambiguous and differentiating it from sibling tools like list_servers or call_tool.
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 provides clear context for when to use the tool: to verify the configuration file (doctor, default) or show the version. It doesn't explicitly name alternatives, but the action list and examples imply the appropriate scenarios. The absence of exclusions is acceptable for a status-checking 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?
No annotations are present, so the description carries the full burden. It discloses what each parameter combination returns (usage guide, tool list, parameter format, raw definitions with health status), giving a good sense of the tool's read-only, exploratory nature. It does not mention error handling or timeouts, but the core behavior is well covered.
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 bullet points and a clear progression from simple to advanced usage, and every section adds value. It is somewhat longer than a minimal description, but the examples and mode breakdown justify the length. No filler or redundant content 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 tool's multiple query modes and the presence of an output schema, the description is largely complete: it covers all main invocation patterns and provides illustrative examples. It does not mention timeout_ms or potential error scenarios, but overall an agent can confidently decide when and how to invoke this 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?
The schema has 0% description coverage, so the description must compensate. It explains the server, tool, and raw parameters with examples, but it completely omits the timeout_ms parameter, leaving that parameter's purpose and impact undocumented. This is a notable gap for a tool that may need to handle large MCP definitions.
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 clearly that the tool explores MCP server tools and parameters, and it distinguishes itself from siblings by describing specific output modes (usage guide vs. tool list vs. parameter format vs. raw JSON). This is a specific verb+resource with clear differentiation from mcporter_list_servers and mcporter_call_tool.
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?
It provides explicit progressive query patterns (no args, server, server+tool, raw=true) and gives concrete examples, such as mcporter_help(server="xiaohongshu"). This tells the agent exactly when to use each level of detail and implies when not to use it (e.g., when only a server list is needed, use mcporter_list_servers).
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?
Despite having no annotations, the description discloses that the list is only an example, warns about large MCPs consuming context, and explains the active vs available distinction. This goes well beyond the schema and covers behavioral traits that an agent 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 long but very well-structured with headers and bullet points. Every section (purpose, partitions, categories, usage flow) adds value, and the main purpose is front-loaded in the first sentence.
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?
The tool is a list operation, and the description explains the return partitions, provides usage workflow with sibling tools, and includes contextual caveats. Given that an output schema exists, no return format explanation is necessary, so the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the two parameters (timeout_ms, include_available) at all, and the input schema provides no descriptions (0% coverage). The param names are only weakly self-explanatory, so the description fails to compensate for the low schema coverage.
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 '列出所有已加载和可激活的 MCP 服务器' (list all loaded and activatable MCP servers), which is a specific verb+resource. It distinguishes itself from sibling tools like mcporter_activate_mcp and mcporter_call_tool by focusing on listing.
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?
It provides an explicit usage flow: call this to view active.servers, activate large MCPs first, use mcporter_call_tool, then deactivate. This tells the agent exactly when to use this tool vs the alternatives, plus context warnings.
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:

[![mcporter-bridge MCP server](https://glama.ai/mcp/servers/Citrus086/mcporter-bridge/badges/card.svg)](https://glama.ai/mcp/servers/Citrus086/mcporter-bridge)

Score Badge

Copy to your README.md:

[![mcporter-bridge MCP server](https://glama.ai/mcp/servers/Citrus086/mcporter-bridge/badges/score.svg)](https://glama.ai/mcp/servers/Citrus086/mcporter-bridge)

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/Citrus086/mcporter-bridge'

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