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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by detailing the return behavior (authenticated:true with empty pending[], or connect_url/per-install URLs), but it does not specify partial connectivity scenarios, leaving a minor transparency gap.
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 just two sentences, front-loaded with the primary purpose. Every clause adds specific information about condition-based outputs, with no filler or repetition.
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 simple nature of the tool (no params, no output schema), the description covers the main outcomes well. However, it omits the case of partial connectivity where some providers are connected and others are not, which could be a realistic scenario for a connection 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, so the baseline is 4. The description doesn't need to add parameter information, and it correctly focuses on the return value logic.
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 'Returns connection status and URLs', using a specific verb and resource. It distinguishes from sibling 'authenticate' by focusing on status rather than performing authentication, and the contextual details about authenticated:true and connect_url reinforce its role.
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 gives clear context by explaining what happens in two scenarios: when all providers are connected and when credentials are missing. However, it does not explicitly mention alternatives or when not to use this tool, though the sibling context implies 'authenticate' is for initiating auth.
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.
The credit analysis tool is clearly distinct, but several platform tools overlap: authenticate, connect, and toolkit_info all deal with connection/auth status, and marketplace is a mega-tool covering many actions. This overlap could cause an agent to select the wrong utility.
Names mix English verbs (authenticate, connect), English verb_noun (report_bug, show_version), nouns (marketplace, toolkit_info), and a Portuguese compound (credito_pf_completo_consultar). There is no consistent naming pattern across the set.
Seven tools is within a typical range, but only one tool serves the credit analysis domain; the other six are generic platform utilities. The set feels padded relative to the server's stated purpose.
The single credit tool covers the full consultation: cadastral data, score, pending issues, and history. Minor gaps exist (e.g., no direct balance or query history), but the marketplace can handle payment top-ups indirectly.