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 declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety traits. It adds value by detailing conditional return behavior: authenticated:true with empty pending[] when all providers are connected, and connect_url plus per-install URLs when credentials are missing. This provides context beyond the annotations, though it does not cover partial connection states or error conditions.
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 two sentences long, front-loaded with the core purpose in the first sentence, then conditional details in the second. Every sentence provides useful information, with no wasted words or redundancy. The structure is clear and efficient.
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?
Given the tool's simplicity (no parameters, no output schema), the description adequately covers the key return values and conditions. It explains what happens when all providers are connected and when credentials are missing. However, it does not mention behavior for partial connection states or potential errors, which would make it fully complete.
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 zero parameters, and the schema coverage is 100% (empty properties). Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter-specific info, but none is needed since there are no parameters to document.
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 clearly states the tool's function: 'Returns connection status and URLs.' This specific verb+resource phrasing distinguishes it from siblings like authenticate (which initiates authentication) and show_version (which displays version info), making the purpose immediately apparent.
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?
The description does not explicitly state when to use this tool versus alternatives. It describes the tool's behavior under different conditions but provides no guidance on when a user should prefer connect over authenticate or other sibling tools. There are no explicit alternatives or exclusions mentioned.
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.
Most tools have distinct purposes: authentication, connection status, marketplace operations, bug reporting, version info, toolkit info, and the sanctions lookup. Minor overlap exists between connect and toolkit_info, both providing connection/status information, which could cause confusion.
Naming is inconsistent: single-word verbs (authenticate, connect, marketplace) mix with underscore-separated phrases (report_bug, show_version, toolkit_info, sancoes_ue_consultar). There is no uniform verb_noun pattern, and the domain-specific tool uses a noun-first structure differing from the others.
Seven tools is a reasonable count, but the server is named for EU sanctions while six of the seven tools are generic MCP platform utilities. This makes the count feel bloated relative to the apparent domain focus, though not excessive in absolute terms.
For an EU sanctions server, only one tool (sancoes_ue_consultar) addresses the domain. There are no additional query methods, list endpoints, or update capabilities, leaving the domain coverage very thin. The other tools are unrelated to sanctions and do not fill this gap.