Returns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful response context: authenticated:true with empty pending[] when connected, and connect_url plus per-install URLs when credentials are missing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences deliver the core behavior and the two relevant conditional outcomes without waste. Every sentence earns its place.
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?
The tool is a zero-parameter read-only status check with no output schema, and the description adequately explains the return conditions and URLs. This is sufficient for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema covers 100% of properties (none exist), so the baseline 4 applies. The description adds no parameter semantics because none are needed.
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+resource ('Returns connection status and URLs') and details conditional results, making its purpose unambiguous. It clearly differentiates from siblings like authenticate by indicating this is a status read, not an auth action.
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?
It gives clear context: use this tool to check connection state and obtain connect URLs when credentials are missing. It does not explicitly name alternatives or exclusions, but the conditional behavior implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are mostly distinct, but authenticate and connect both deal with authentication/connection, which could cause slight confusion. The rest are clearly differentiated.
Naming is inconsistent: single-word verbs (authenticate, connect), nouns (marketplace), a long descriptive name (pref_ba_salvador_nada_consta_consultar), and compound verbs/nouns (report_bug, show_version, toolkit_info) break any clear pattern.
Seven tools is a reasonable size for a platform server that covers authentication, marketplace search, feedback, and info. Not too few or too many.
The set covers core actions but lacks explicit install/uninstall or management operations for MCPs, relying on marketplace to implicitly handle them. This leaves a notable gap for a full lifecycle.