list_mcp_connections
View all connected MCP servers and their usage statistics to monitor integration health and activity.
Instructions
List your connected MCP servers with usage stats.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
View all connected MCP servers and their usage statistics to monitor integration health and activity.
List your connected MCP servers with usage stats.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List' strongly implies a read-only operation, and the addition of 'usage stats' gives insight into the response payload. While it doesn't explicitly declare side-effect safety, the non-mutating nature is evident and the description is sufficiently transparent for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise, front-loaded sentence with no superfluous words. It immediately states the action and the object, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the essentials: it lists connected MCP servers and includes usage stats. It doesn't elaborate on what 'usage stats' includes, but given the low complexity, it is adequate 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds meaning beyond the empty schema by specifying what is being listed (connected MCP servers) and that the output includes usage stats, which helps the agent understand the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clarifies the resource as 'your connected MCP servers' with the added detail 'with usage stats', which conveys scope and outcome. This clearly distinguishes it from the sibling 'mcp_list_servers' which likely lists available servers rather than connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it differs from alternatives like 'mcp_list_servers' or 'ghl_mcp_status'. The description simply states what it does, leaving the agent to infer use cases without explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Crypto-Goatz/rocket-plus-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server