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, idempotentHint, and destructiveHint, and the description adds meaningful state-specific context: it reveals that the response shape varies based on connection state, including authenticated, pending, and connect_url fields. This goes beyond the basic safety profile provided by 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?
The description is compact and front-loaded, with two sentences that each carry useful information. It avoids repetition and clearly explains the primary purpose and conditional outcomes without wasted words.
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) and the strong annotations, the description covers all necessary context: what the tool returns, when each return variant applies, and what the key fields mean. It is complete for an AI agent to invoke and interpret results correctly.
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 schema coverage is 100%, so there is no parameter information missing. The description focuses on the return behavior, which is the only meaningful semantic content for a no-parameter tool, matching the baseline for 0 params.
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.' It specifies the two possible outcomes (fully connected vs. missing credentials), which distinguishes it from siblings like authenticate by focusing on status reporting rather than performing authentication.
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 conditional behavior ('When all providers are connected... When credentials are missing...') which implies when to inspect this tool's results, but it does not explicitly state when to use connect versus alternatives like authenticate. Usage context is implied rather than explicit.
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.
Each tool has a clearly distinct purpose: authenticate for login, connect for status, marketplace for finding/running MCPs, report_bug for feedback, show_version for version info, toolkit_info for installed tools, and the single domain tool for TRT9 queries. No overlap exists between them.
Names are inconsistent: first six are single words or short verbs/nouns (authenticate, connect, marketplace) with occasional underscores (report_bug, show_version), while the domain tool uses a long snake_case with a domain prefix (tribunal_trt9_processo_consultar). No consistent verb_noun pattern or style unifies the set.
Seven tools is a reasonable count, but six are generic platform utilities while only one addresses the server's stated purpose (Consulta Processual). This feels like a platform server with one domain tool bolted on, slightly mismatched with the server name but still within an acceptable range.
For the domain, only one query tool exists, which may suffice for a simple lookup but lacks any additional operations (e.g., filtering, batch queries, or status checks). The platform utilities are comprehensive, but the core domain surface is minimal and might leave agents without sufficient coverage for varied consultation needs.