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 idempotentHint=true. The description adds behavioral context by detailing the two output scenarios (authenticated vs. missing credentials) and that it returns connect URLs. No contradictions, and it adds value beyond the 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 concise sentences, front-loaded with the core purpose. Every word earns its place—no fluff.
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 no parameters and no output schema, the description fully covers the tool's behavior: it states what it returns and the distinct cases (connected vs. missing credentials). It is complete for a simple read-only status tool.
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 ascending; the schema is empty (100% coverage). Per guidelines, baseline for 0 params is 4, and the description effectively explains the tool's behavior and output without needing to describe parameters.
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 purpose: 'Returns connection status and URLs.' It also distinguishes the two outcome scenarios (all connected vs. missing credentials), making it specific and distinct from siblings like 'authenticate' and 'marketplace'.
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 clearly implies this is a status-check tool, and the presence of 'authenticate' as a sibling suggests alternative usage. However, it doesn't explicitly state when to use this vs. other tools or any exclusions. It gives clear context about what it reports, but no direct 'use this when' guidance.
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 clearly distinct roles, but `marketplace` overlaps with `report_bug`, `toolkit_info`, and `connect` by exposing similar actions like report_bug, list_tools, and connect links. The detailed descriptions reduce but do not eliminate the ambiguity about which entry point an agent should call.
Naming mixes single-word verbs like `authenticate` and `connect` with snake_case compound names like `report_bug`, `show_version`, and `toolkit_info`, while the domain tool `der_ba_nada_consta_consultar` uses a unique, longer pattern. The names are readable and lowercased, but there is no consistent verb_noun convention across the set.
Seven tools is within a reasonable range and each utility has a plausible role in the platform workflow. However, `marketplace` is a multi-action monolith that could easily be split into several separate tools, and some utilities are partially redundant, so the count is only slightly less clean than ideal.
The core DER BA Nada Consta consultation is covered by `der_ba_nada_consta_consultar`, and the platform utilities provide authentication, connection status, toolkit info, and support. The main gap is that credit/balance visibility and top-up are only handled indirectly through `marketplace` returned links rather than dedicated tools, but the primary consult workflow is usable.