PMCP

Server Quality Checklist

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

Latest release: v2.7.3
Disambiguation5/5
Every tool has a clearly distinct purpose with descriptive names and detailed descriptions. Ambiguities like gateway.cancel vs gateway.tasks_cancel are explicitly resolved in the descriptions, so agents can reliably differentiate them.
Naming Consistency5/5
All tools follow a consistent `gateway.` prefix with lowercase snake_case verbs and nouns (e.g., list_pending, config_status, search_registry). The naming pattern is uniform and predictable across the entire set.
Tool Count2/5
With 26 tools, the count exceeds the recommended upper bound of 25 for a cohesive toolset. While the gateway domain is broad, several tools could be consolidated (e.g., merging status/check tools) to reduce cognitive overhead.
Completeness4/5
The tool surface covers core lifecycle operations: discovery, provisioning, invocation, task management, config, health, and feedback. Minor gaps exist (no explicit uninstall/remove server tool), but the common workflows are well-supported.
Average 4/5 across 26 of 26 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 150 commits in the last 12 weeks
- Last stable release on August 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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 provided, the description carries full responsibility for behavioral traits. It does not disclose idempotency, error handling, or any side effects. The minimal statement 'get current status' lacks depth on what constitutes 'status' or expected outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 9 words, achieving brevity. However, it is too sparse to be fully useful; it sacrifices necessary detail for conciseness. Front-loaded with the verb, but lacks structure for additional context.
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?
Given the tool's simplicity (2 params, no output schema) and lack of annotations, the description should provide more detail. It does not explain what 'current status' means, output format, or how to use the parameters effectively, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters (task_id, server_name). It does not explain their purpose, format, or constraints, forcing the agent to rely solely on the parameter names and types.
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 verb 'get' and the resource 'current status for one downstream MCP task', differentiating it from siblings like tasks_list (list) and tasks_cancel (cancel). However, it does not elaborate on what 'downstream' means, slightly reducing clarity.
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when not to use. The description simply states the function without context for selection.
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 mentions 'preview or explicitly apply' but does not disclose side effects, reversibility, or required permissions. With no annotations, the agent lacks key behavioral 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?
Single sentence with no wasted words, though it sacrifices clarity for brevity. Could be better structured to separate preview vs apply modes.
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?
Missing output schema and no return value description. Does not explain what happens after applying the policy or how to interpret preview results. Insufficient for a tool with 6 parameters.
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 explain parameters. It covers 'operation' (add/remove/set) and implies 'dry_run' via 'preview', but leaves 'path', 'apply', 'names', and 'source' undefined or ambiguous.
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 performs preview or explicit application of an autoStart add/remove/set operation on a config source or path. It distinguishes from the sibling 'get_startup_policy' which reads the policy.
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 'get_startup_policy'. No mention of prerequisites or scenarios where preview/apply is appropriate.
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?
With no annotations, the description carries the full burden. It discloses validation before execution and automatic output truncation, but lacks details on error handling, idempotency, or authentication requirements.
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, no redundant information, purpose is front-loaded. Every sentence provides essential behavioral insight.
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?
Despite describing core behaviors, the description omits return value format, error handling, and how to structure the nested 'options' object. For a complex gateway proxy tool, more detail is needed.
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 83%, so the schema already describes most parameters. The description adds context about validation and truncation but does not elaborate on parameter usage beyond the schema.
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 invokes a tool on a downstream MCP server, with specific actions like validation and truncation. It distinguishes from sibling tools as no other gateway tool serves a similar proxy invocation purpose.
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 guidance is provided on when to use this tool versus alternatives, nor any conditions or exclusions. The agent has no help in deciding context.
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 provided, so description must disclose behavior. It only says 'Cancel' but does not mention side effects (e.g., whether task termination is immediate or graceful), auth requirements, or success/failure conditions. The 'force' parameter is not explained.
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?
Two sentences, no redundancy. However, efficiency is slightly compromised by not integrating parameter details, though the structure remains clean.
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?
Without output schema or annotations, the description fails to explain return values, error states, or parameter semantics. The tool is a cancellation operation, but the user is left unsure of behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds no extra meaning for any of the three parameters. 'force' is a boolean with default false, but its effect is not specified. 'server_name' and 'task_id' lack format or value constraints.
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 the verb 'Cancel' and resource 'downstream MCP task', and specifies the identifier type 'opaque task ID'. It distinguishes from sibling 'gateway.cancel' by noting it is for PMCP request IDs.
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 states when to use this tool vs 'gateway.cancel', providing a clear boundary: 'Use gateway.cancel only for PMCP request IDs from gateway.list_pending.'
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?
With no annotations provided, the description carries the full burden. It adds value by disclosing that output redaction and truncation options are applied, but it omits important behavioral details such as whether the call waits for task completion, error handling for missing/pending tasks, or permission requirements.
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 a single sentence with a front-loaded verb, no redundant words, and all information is directly relevant to the tool's purpose.
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?
There is no output schema or annotations, and the description does not explain return values, error conditions, or the relationship to the asynchronous invoke flow. Given the existence of siblings like tasks_get and tasks_list, the description does not provide enough context for an agent to reliably choose and use this tool.
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% and the description does not explain the parameters server_name, task_id, or the options object beyond referencing gateway.invoke for redaction/truncation. While the parameter names are self-explanatory, the description adds minimal semantic value and does not compensate for the lack of schema 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 the specific verb 'Fetch' and clearly identifies the resource as a 'downstream MCP task result', which distinguishes it from siblings like tasks_list or tasks_get. It also references gateway.invoke to clarify the output processing scope.
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 for retrieving results from a downstream MCP task and mentions the same redaction/truncation options as gateway.invoke, but it does not explicitly state when to use this tool versus alternatives like tasks_get, nor does it mention prerequisites or exclusions.
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 the full burden. It only states the action ('connect or start') without disclosing side effects, required permissions, rate limits, or safety considerations. For a tool that may alter server state, more transparency is needed.
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 sentences, concise and to the point. Every word adds value, with no filler or repetition. The structure is well-suited for quick understanding.
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 simplicity (one parameter, no output schema, no annotations), the description adequately covers its purpose and scope. However, for a gateway tool in a diverse set, slightly more context on when to use this over sibling tools 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?
With 100% schema description coverage, the schema already defines the parameter. The description adds no extra meaning beyond 'by name', which is redundant. No additional context on parameter format, source, or constraints is given, so it meets the baseline but adds minimal value.
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 action ('connect or start'), the resource ('downstream MCP server'), and the method ('by name'). It also distinguishes from siblings by specifying it resolves configured, provisioned manifest, and registered discovered servers, making the purpose specific and distinct.
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 when to use (to connect servers that are configured, provisioned, or discovered), but does not explicitly state when not to use it or provide alternatives. Sibling tools like 'provision' or 'register_discovered_server' are not contrasted, leaving some ambiguity.
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 of behavioral disclosure. It only says 'store credentials' without addressing persistence, security, overwrite behavior, or the implications of the two auth modes (api_key vs url_elicitation). This is a significant gap for a credential-management tool.
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 for purpose and the second for usage context. No wasted words; it is highly efficient and front-loaded.
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 schema is rich with descriptions and enums, but the description does not explain the relationship between auth modes and parameters like elicitation_id and consent_acknowledged. It also doesn't tell the agent what to expect after invoking (no output schema). It is adequate but not comprehensive for a tool with this complexity.
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 100% parameter coverage with individual descriptions, so the baseline of 3 applies. The description itself adds no parameter-specific meaning, but the schema already handles that sufficiently.
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 function: storing credentials for a server and making them available to provisioning. It distinguishes itself from siblings by explicitly referencing the gateway.provision missing-authentication scenario, which differentiates it from other connection/server management tools.
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?
It provides a specific, actionable when-to-use condition: 'Use this when gateway.provision reports missing authentication.' This gives clear context but does not mention alternatives or when not to use it, so it stops short of the most complete guidance.
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?
With no annotations, the description carries the full burden. It clearly discloses the read-only nature and adds useful context like 'non-secret diagnostics' and 'source attribution.' It doesn't mention authentication or rate limits, but for a status tool this is adequate.
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 a single, concise sentence that front-loads the read-only nature and scope. Every word earns its place with no filler or repetition.
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 no-parameter status tool with no output schema, the description sufficiently covers the tool's purpose and output nature. It could elaborate on what 'effective configuration' includes, but overall it is complete for a tool of this complexity.
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?
The tool has zero parameters, so the input schema is empty (100% coverage). The description adds meaning by explaining what the tool reports (effective configuration, startup policy status, source attribution, non-secret diagnostics), going beyond the schema.
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 uses the specific verb 'Show' and identifies the resource as 'effective configuration and startup policy status,' clearly stating the tool's purpose. However, it doesn't explicitly differentiate itself from sibling gateway.get_startup_policy, which also deals with startup policy.
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 guidance is provided on when to use this tool versus alternatives like gateway.get_startup_policy or gateway.health. The description only states what it does, not when to prefer it or what scenarios it is designed for.
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?
With no annotations, the description carries the full burden. It discloses an important semantic distinction about task IDs being opaque downstream identifiers, which is useful context. However, it does not mention read-only behavior, return structure, or pagination; the schema covers the cursor parameter, but the description adds only this one behavioral nuance.
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 a single sentence of 12 words, front-loaded with the verb and resource. The additional clarification about opaque identifiers is concise and earns its place without wasted words.
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 list tool with two optional parameters and no output schema, the description covers the core function and adds a key clarification about ID semantics. The cursor parameter's schema description already provides pagination context, making the description largely complete. A brief mention of the return format would be helpful but is not essential for correct invocation.
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 descriptions for both parameters (cursor and server_name) with 100% coverage. The description does not add any parameter-specific information beyond the schema, so the baseline 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 uses a specific verb ('List') and identifies the resource ('brokered downstream MCP tasks'). The added clarification that task IDs are opaque downstream identifiers, not PMCP request IDs, further distinguishes this tool from related request-id tools.
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 for downstream tasks rather than PMCP request IDs, but it does not explicitly state when to use this tool versus alternatives like gateway.list_pending or gateway.tasks_get. No exclusions or alternative names are provided.
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?
With no annotations provided, the description carries the full burden. It discloses the two-phase behavior: by default returns a preview, and submission only occurs when confirm_submission is true. This is clear and transparent, though no further details like rate limits or auth needs are given.
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 extremely concise: two sentences, no wasted words. It front-loads the main purpose and then clarifies the key behavior (default vs. submission). This is an efficient and well-structured description.
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 six parameters and no output schema, the description covers the main behavioral distinction (preview vs. submit) but omits details such as the preview payload format, error handling, or expected output. This leaves the agent with some gaps about how to interpret the result.
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 83% (5 of 6 parameters described), so the baseline is 3. The description adds value only for confirm_submission (explaining its role in submission) but does not elaborate on other parameters like title, description, or issue_type. Thus, it provides marginal additional meaning.
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 prepares and optionally submits a PMCP feedback issue to GitHub. It specifies the default behavior (preview) and the action to submit (confirm_submission=true). The tool is distinct from siblings, which are all about gateway operations, not feedback submission.
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 for feedback preparation or submission but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or alternative tools are mentioned, so the guidance is minimal.
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 full burden. It indicates a read-only operation by describing it as 'get detailed information', but does not explicitly state it is non-destructive or disclose any other behavioral traits like auth needs or rate limits.
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, both essential and front-loaded. No redundant or vague language. Every word contributes value.
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 describe tool with one parameter, the description adequately explains what the output contains (arguments and constraints). However, without an output schema, slightly more detail on the output structure 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?
The schema already covers the single parameter 'tool_id' with format guidance. The description does not add additional meaning beyond the schema, so with 100% coverage, 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 explicitly states the verb 'Get detailed information' and the resource 'a specific tool', making the purpose clear. It distinguishes itself from siblings like invoke or search_registry by focusing on tool metadata.
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?
Provides a clear usage context: 'Use this before invoking a tool to understand its requirements.' This guides the agent on when to use it, though it does not explicitly mention when not to use or alternatives.
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?
With no annotations, the description carries the full burden. It indicates a read operation ('Return') but does not explicitly confirm no side effects, permissions required, or other behaviors like rate limits. Adequate but not explicit.
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 a single sentence that efficiently conveys the tool's exact purpose with no extraneous words.
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 or annotations, the description provides enough context for the tool's core function. It identifies what is returned and grouping, though details on 'config source' or output format are missing. Adequate for a simple retrieval.
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?
The input schema has no parameters (0 params, 100% coverage). The description adds no param info, but none is needed. Baseline 4 is appropriate for a parameterless tool.
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 returns persisted autoStart and disableAutoStart entries grouped by config source, using a specific verb ('Return') and resource. It implicitly distinguishes from the sibling 'set_startup_policy'.
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?
No explicit usage guidance is provided, but the purpose is clear as a retrieval operation. The description implies when to use (when you need startup policy data), but does not mention exclusions or when-not-to-use.
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 must carry the burden of behavioral disclosure. It describes the output fields but does not explicitly state that the operation is read-only or that it does not modify state. However, the action 'list' generally implies safety, and the use case suggests monitoring rather than mutation.
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 sentences: the first explains what the tool does, the second provides usage guidance. It is concise with no wasted words.
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 includes what information the output contains, which is helpful given the lack of an output schema. The parameter is well-documented in the schema, and the overall context is sufficient for correct invocation.
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 has 100% coverage for the single parameter 'server', which already includes a description. The tool description adds no additional meaning beyond the schema, so the baseline score 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 explicitly states the verb (List), resource (pending tool invocations), and the specific data shown (health status, elapsed time, heartbeat age, current state). This clearly distinguishes it from sibling tools like gateway.tasks_list.
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 a clear use case: 'Use this to monitor long-running operations before deciding to cancel.' It implies when to use but does not explicitly contrast with alternatives, though the context of canceling hints at the sibling cancel tool.
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 exist, so the description carries full burden. It hints at the registration action but does not disclose idempotency, overwrite behavior, auth requirements, or failure modes. Adequate but incomplete.
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 efficiently convey purpose and usage sequence. 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?
Given no output schema and no annotations, the description explains the tool's role in a pipeline but omits return value, error conditions, or confirmation details. Adequate but not fully complete.
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 descriptions for all four parameters. The description does not add extra meaning beyond what the schema already provides, thus baseline score 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 action 'Register an externally-discovered MCP server package' and distinguishes the tool from siblings by placing it in a pipeline: after gateway.search_registry and before gateway.provision.
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 tells when to use this tool: 'Call this after gateway.search_registry to register the chosen package, then call gateway.provision to install and start it.' This provides clear context and ordering.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context beyond the schema by mentioning the return format ('compact capability cards without full schemas') and the behavior of include_offline for discovering 'provisionable servers not yet running.' It does not describe pagination or error behavior, but the key behavioral traits are disclosed.
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 three concise sentences, front-loaded with the primary purpose and followed by relevant filter/offline usage and a positioning statement. Every sentence earns its place with no repetition or fluff.
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 search tool with no output schema, the description covers the core behavior, return type, filtering options, offline discovery, and its role in the wider system. It lacks explicit return field details, but the schema's limit parameter and the mention of 'compact capability cards' provide sufficient context for an agent to 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?
Schema description coverage is 75%, and the schema already documents each parameter, including query matching behavior and filter meanings. The description adds limited new parameter semantics, only elaborating that include_offline discovers provisionable servers. Since the schema covers most parameter meaning, the description provides marginal added value beyond 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's function: 'Search for available tools across all connected MCP servers.' It also differentiates this tool from siblings by noting it returns 'compact capability cards without full schemas' and positioning it as 'the primary tool discovery entry point,' which distinguishes it from more specific tools like gateway.describe or gateway.search_registry.
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 by identifying this as the primary discovery entry point and explaining how filters and include_offline refine results. However, it does not explicitly mention when not to use this tool or name alternative tools for full schema details, so it falls short of fully explicit guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals an important behavioral trait: 'Refuses by default while downstream requests are pending; set force=true to cancel them.' This adds meaningful context beyond a simple reload/reconnect statement, though it could mention additional side effects (e.g., impact on active connections).
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 sentences, front-loaded with the primary action, and every word earns its place. There is no redundant or filler content.
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 and no annotations, the description adequately covers purpose, usage context, and a key behavioral nuance (refusal/force). It lacks return-value or error details, but those are not strictly required for a tool of this simplicity and are sufficiently implied.
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 reinforces the 'force' parameter ('set force=true to cancel them') but adds no new semantic meaning beyond what the schema already provides for reason and source.
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 opens with 'Reload backend MCP server configurations and reconnect,' a specific verb+resource pair that clearly states what the tool does. It also distinguishes from siblings by explicitly mentioning the use cases: 'when new MCP servers have been configured or to recover from connection errors.'
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 ('Use this when new MCP servers have been configured or to recover from connection errors'). However, it does not mention when not to use it or suggest alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It indicates the tool is a search operation returning package names and metadata, but does not disclose potential side effects, authentication requirements, rate limits, or error handling. The description is adequate but lacks detailed behavioral context beyond the basic read-only nature implied by 'search'.
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 sentences, front-loading the purpose and usage condition, then providing the expected output and follow-up steps. Every sentence adds value, and there is no redundancy or wasted words.
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 search tool with two well-documented parameters and no output schema, the description provides essential context: trigger condition, output type, and next steps. It does not cover edge cases or output formatting, but the schema compensates. Given the tool's simplicity, this is sufficiently complete.
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 clear descriptions for both 'query' and 'limit'. The description adds context by stating the query is a 'natural language description of the capability needed', which aligns with the schema. However, it does not elaborate on the 'limit' parameter, so it adds no meaning beyond the schema's own description.
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 verb ('Search'), resource ('public MCP Registry'), and scope ('external servers not in the local manifest'). It explicitly distinguishes this tool from siblings like gateway.catalog_search and gateway.request_capability by specifying the registry target and the condition for use.
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 an explicit when-to-use condition ('Use this when gateway.request_capability returns not_available') and outlines the subsequent workflow ('call gateway.register_discovered_server then gateway.provision to install'). This gives clear guidance 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?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool returns health status, server status, tool counts, and last refresh time, implying a read-only, non-destructive operation. However, it does not explicitly state that it is non-destructive or mention any auth requirements.
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 a single, front-loaded sentence that efficiently communicates the tool's purpose and output without any unnecessary words.
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 no parameters and no output schema, the description is complete. It specifies the key outputs (server status, tool counts, last refresh time) that an agent would need to understand what the tool does.
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?
The tool has zero parameters, and the schema description coverage is 100%. The description adds value by explaining what the tool returns, which goes beyond the empty schema.
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 'Get' and clearly identifies the resource as 'health status of the gateway and all connected MCP servers'. It distinguishes from sibling tools by focusing on health, tool counts, and refresh time, which no other sibling explicitly covers.
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 does not explicitly state when to use this tool versus alternatives or when not to use it. While the purpose is clear, there is no guidance on proper usage context or exclusions.
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 provided, so the description carries the full burden. It discloses a critical behavioral trait: the tool refuses to disconnect if there are pending requests unless force=true is set, which cancels them. This goes beyond a simple statement of action and informs the agent of side effects. It omits other details like reversibility, but the disclosed behavior is significant.
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 sentences, front-loaded with the action, and every phrase earns its place. No filler or repetition of schema details.
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 tool with no output schema and no annotations, the description covers the core behavior, the default refusal condition, and the force override. It does not explain what happens after disconnect (e.g., how to reconnect) but that may be implied by sibling tools. Overall, it provides sufficient context for correct invocation.
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 description coverage is 100% and both parameters have descriptions. The tool description adds meaningful context for the force parameter by explaining the default refusal behavior and that setting force=true cancels pending requests. This enriches the schema's default value without redundancy.
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 opens with 'Disconnect a running downstream MCP server' – a specific verb and resource. It further clarifies 'without changing persistent config', which distinguishes it from configuration-changing tools and gives a precise scope of action.
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 operational context: it refuses by default when pending requests exist and explains when to use force=true. It does not explicitly name alternatives or exclusion criteria, but the persistent-config qualification helps differentiate from sibling tools like update_server or connect_server.
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?
With no annotations, the description fully explains that the tool returns ranked candidates by matching against CLIs and MCP servers. It explicitly states it does NOT start anything, making the non-destructive, advisory nature clear. Absent are details about return structure or limitations like rate limits, but these are minor for a recommendation tool.
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 extremely concise with three sentences: one explaining the tool's purpose with examples, one clarifying it doesn't execute, and one giving usage guidance. Every sentence adds value with 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?
For a simple recommendation tool with two parameters and no output schema, the description covers essential aspects: purpose, examples, non-execution behavior, and sibling differentiation. It mentions matching against 90+ provisional MCP servers, providing helpful context. Minor omissions like exact return format are acceptable given the tool's simplicity.
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?
The schema covers 100% of parameters, establishing a baseline of 3. The description adds value by providing contextual examples for the query parameter (e.g., 'scrape a website') and explaining the available_clis parameter's purpose. It also mentions that results are ranked candidates, going beyond schema.
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 this tool recommends the right tool for a task based on natural language description. It uses specific verbs ('Recommend', 'describe what you need') and distinguishes itself from sibling tool gateway.provision by clarifying it does not start anything.
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 advises preferring this tool over gateway.provision when the exact server name is unknown, providing clear when-to-use guidance. It also offers examples of queries, though it lacks explicit when-not-to-use scenarios beyond the contrast with provision.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool refuses by default if pending requests exist and that force=true cancels them. This adds meaningful behavioral context beyond just saying 'restarts a server'. It could mention that the restart is not persistent and that the server must be known, but overall it's good.
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 sentences, front-loaded with the main action. Every sentence adds value without redundancy. It is efficient and well-structured.
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 simplicity of the tool (2 parameters, no output schema, no nested objects), the description is sufficiently complete. It covers the default behavior and the force option. It could mention what happens after restart (e.g., server comes back online), but the core functionality is clear.
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 description coverage is 100%, so baseline is 3. The description adds value by explaining the default refusal behavior for the force parameter and how it relates to pending requests. This is extra context beyond the schema's 'Cancel this server's pending requests before restarting', 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 restarts a known downstream MCP server without changing persistent config. It uses a specific verb (restart) and resource (downstream MCP server), avoiding tautology. It also implicitly distinguishes from sibling tools like connect_server or update_server.
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 explicit guidance on when to use the force parameter: when there are pending requests, the tool refuses by default, so force=true is needed to cancel them. It does not mention alternatives or explicitly state when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully explains the tool's behavior: it syncs environment info by detecting platform and CLIs, and the info is used for capability matching. It does not mention side effects like updates to internal state, but for a sync operation this is reasonable transparency.
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 sentences with no redundancy. Every clause carries useful information: what it does, how it works, and why it's used. Ideal conciseness.
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 tool has no required parameters, no output schema, and simple behavior. The description covers the core purpose and parameters well. Minor omission: it doesn't state what the sync returns (if anything), but for a sync operation this is a minor gap.
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 context by explaining that parameters override detected values, which is meaningful beyond the schema's 'override' phrase. This elevates the score slightly.
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 specifies the verb 'sync' and the resource 'environment information', and elaborates that it detects platform and CLIs. This clearly distinguishes it from all sibling tools, none of which mention environment syncing.
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 explains that synced info is used to prefer CLIs over MCP servers for capability matching, giving clear context for use. It does not explicitly state when not to use, but no sibling tools serve a similar purpose, so alternatives are not needed.
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?
With no annotations, the description carries full burden. It discloses the key behavioral trait: default refusal of healthy requests and the force flag to override. It also notes the request ID format. It could mention idempotency or error states, but the core behavior is well-transparent for a cancel operation.
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 concise sentences: purpose, default behavior with force alternative, and prerequisite advice. No wasted words, front-loaded with the core action. Ideal structure for quick agent comprehension.
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 no output schema and simple tool, the description covers all needed context: prerequisite list_pending, default safety behavior, force option, ID format. For the complexity level, it is fully 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?
The description adds context to schema-defined parameters: it explains the request ID format (already in schema) and the force parameter's effect. With 100% schema coverage, baseline is 3, but the description adds extra usage context, raising it to 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 cancels a pending tool invocation, specifies the verb and resource, and distinguishes from siblings by referencing gateway.list_pending and explaining default refusal of healthy requests. It leaves no ambiguity about the tool's purpose.
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 advises to use gateway.list_pending first to get request IDs and health status, and explains the default behavior and force flag. This provides clear when-to-use and when-not-to-use guidance, effectively integrating with the sibling 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?
With no annotations provided, the description carries the full burden for behavioral transparency. It discloses that the tool returns immediately with a job_id and directs the agent to poll gateway.provision_status for progress, covering the asynchronous execution model. It does not mention potential side effects beyond install/start (which is the intended function), but overall it provides meaningful behavioral context.
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 a compact set of three sentences, each earning its place: purpose, usage context, and asynchronous behavior. No fluff, key information is front-loaded, and the structure is easy to scan.
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 simple one-parameter tool with no output schema, this description is complete. It explains what it does, when to use it, what to expect (job_id), how to track progress (poll provision_status), and when to use an alternative (request_capability). No critical missing context for an agent 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers server_name with a description ('Name of the server to provision (from manifest)'), and schema coverage is 100%. The description adds workflow context by emphasizing the need for the 'exact server name' and connecting it to the request_capability discovery process, which enriches the parameter's meaning beyond the schema.
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 action ('Provision (install and start)') and the specific resource ('a specific MCP server from the manifest'). It distinguishes itself from siblings like gateway.request_capability (discovery) and gateway.provision_status (tracking) by focusing on the installation/start action.
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?
Explicit usage guidance is provided: 'Use this after reviewing candidates from gateway.request_capability' and 'Use gateway.request_capability instead if you don't know the exact server name.' This clearly tells when to use this tool versus the alternative, with a concrete workflow.
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?
The description discloses what the tool returns: 'progress percentage, output log, and final tools when complete.' Since no annotations are provided, the description carries the full burden and does so excellently, indicating a read-only operation without 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, no redundant words. Key information is front-loaded: purpose, usage context, and return values. 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?
For a single-parameter tool with no output schema, the description fully covers what the tool does, when to use it, and what to expect in return. The agent can use it without additional guesswork.
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?
The schema defines job_id with a description, but the tool description adds context ('Use after gateway.provision returns a job_id'), clarifying the parameter's origin and purpose, going beyond the schema's minimal description.
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 checks the status of a server installation, specifying the verb 'check' and the resource 'status of a running server installation'. It distinguishes itself from siblings like 'config_status' or 'health' by focusing on the provisioning lifecycle.
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 states when to use the tool: 'Use after gateway.provision returns a job_id.' This provides clear context, though it does not mention when not to use or list alternatives, which would further differentiate it from 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?
Despite no annotations, the description transparently discloses that the tool mutates the server by updating and restarting it. It also details the conditional refusal to restart when pending requests exist and the effect of force=true. While it does not mention potential side effects like version compatibility or downtime, the core behaviors are clearly described. The lack of annotations is compensated by the explicit statements 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?
The description is concise yet informative, comprising three sentences that cover purpose, when to call, and behavioral nuance. It is well-structured, starting with the primary action, then usage context, and finally a caveat about pending requests. No unnecessary words or repetition; every sentence adds value.
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 that there is no output schema, the description adequately covers all necessary context: the action (update and restart), the trigger (check for updates), and the behavioral condition (force). It provides enough information for an agent to invoke the tool correctly without needing additional details. The description is self-sufficient.
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?
The schema provides descriptions for both parameters: 'Name of server to update' and 'Cancel this server's pending requests before restarting'. These descriptions are clear and adequate, and the tool description adds further context about force, explaining its purpose. The semantics are unambiguous, though the parameter descriptions are minimal. Overall, the meaning is well conveyed.
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 explicitly states the tool's purpose: 'Update a subordinate MCP server package to latest version and restart it.' It uses a specific verb ('update') and a clear resource ('subordinate MCP server package'). It distinguishes itself from sibling tools like 'restart_server' by emphasizing the update aspect, making it easy for an agent to select this tool for update operations.
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 clear guidance on when to call: 'Call this to check for and apply an update' and explains that the gateway does not volunteer update notices, so proactive checking is needed. It also mentions the conditional behavior with pending requests and force, giving explicit instructions on how to override the default behavior. This is sufficient for an agent to know 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.

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:

[![pmcp MCP server](https://glama.ai/mcp/servers/Consiliency/pmcp/badges/card.svg)](https://glama.ai/mcp/servers/Consiliency/pmcp)

Score Badge

Copy to your README.md:

[![pmcp MCP server](https://glama.ai/mcp/servers/Consiliency/pmcp/badges/score.svg)](https://glama.ai/mcp/servers/Consiliency/pmcp)

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/Consiliency/pmcp'

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