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, destructiveHint=false, so the agent knows it's a safe read operation. The description adds useful behavioral details about the conditional return values (authenticated:true when all connected, connect_url when missing credentials), which is beyond what annotations provide. Not contradicting 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 sentences, directly to the point, no filler. The description is front-loaded with the main action ('Returns connection status and URLs') and then provides conditional behavior details. Perfectly concise and well-structured.
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 has no parameters and annotations already convey safety and idempotency, the description is quite complete. It explains the return values in different scenarios (all connected vs. missing credentials). However, it doesn't mention the exact structure of connect_url or per-install URLs, which might be useful, but output schema is absent and the description covers key aspects.
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 no parameters, so the baseline is 4. The description doesn't need to elaborate on parameters. The schema coverage is 100% (empty). The description focuses on output semantics, which is appropriate.
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 what the tool does: returns connection status and URLs. It distinguishes itself from siblings by focusing on status/URLs rather than authentication actions (authenticate) or information lookup (toolkit_info). Slightly less explicit about the resource scope (connection status of what? providers).
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?
No explicit guidance on when to use this tool versus alternatives. It implies usage for checking connection status, but doesn't mention when not to use it or when to use authenticate or toolkit_info instead. The description is mostly descriptive, not prescriptive.
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 Tribunal TRF1 query tool is clearly distinct, but there is some ambiguity among the platform utilities: authenticate and connect both relate to connection/auth flow, and marketplace duplicates report-like and toolkit-inspection concepts. An agent can usually select the right tool, but only because the descriptions are long and corrective.
Naming is inconsistent: bare verbs (authenticate, connect), a noun (marketplace), and snake_case verb/noun forms (report_bug, show_version, toolkit_info) are mixed with a very long Portuguese domain name. This does not follow a predictable verb_noun pattern and mixes English and Portuguese conventions.
Seven tools is not excessive, but only one tool actually belongs to the Tribunal TRF1 domain while the other six are generic marketplace/configuration utilities. The set feels top-heavy and under-focused for a server whose main purpose appears to be consulting TRF1 court processes.
For a read-only public consultation service, a single consultar tool may be acceptable, especially since the description implies it returns information from official sources. However, there are no search, listing, or multi-query options, and the generic platform tools do not add meaningful domain coverage.