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, establishing a safe read operation. The description adds behavioral specifics beyond annotations: it details the exact return values in two scenarios (authenticated:true with empty pending[] when connected; connect_url and per-install URLs when credentials are missing). No contradiction with 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 two sentences, tightly written, and front-loaded with the core purpose. The first sentence conveys the main action, and the second clarifies conditional output without redundant verbosity.
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?
For a simple, parameterless status tool with no output schema, the description is quite complete. It covers the two primary states (all connected, missing credentials). However, it omits partial-connection scenarios, which might be realistic but are not critical for this tool's core function.
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 schema already covers everything (100% coverage). The description correctly omits parameter details and instead explains the output behavior based on connection state, which is appropriate for a parameterless tool.
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 primary function: 'Returns connection status and URLs.' It specifies conditions for different outputs (all providers connected vs. missing credentials), making it distinct from siblings like 'authenticate' which performs the connection action.
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 provides clear context for when this tool is appropriate: to check connection status and obtain URLs. It does not explicitly mention alternatives or exclusions, but the context is unambiguous for a status-checking tool.
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.
Several tools overlap: connect and toolkit_info both report connection status, and marketplace embeds sub-actions (report_bug, list_tools) that duplicate standalone tools. Agents may struggle to choose the right tool.
All names use snake_case, but the style is mixed: some are verbs (authenticate, connect, show_version), some are nouns (marketplace, toolkit_info), and the domain tool stm_certidao_consultar reverses the noun-verb order. This inconsistency makes the set less predictable.
Seven tools is a reasonable count, but six are generic platform utilities unrelated to the 'Certidão STM' purpose. The set feels bloated for a server whose name suggests a narrow domain, with only one tool actually serving that domain.
For the named domain, only a single consult operation exists—no history, reprint, or status features. The platform tools cover a different domain entirely, leaving the certidão functionality with significant gaps if that is the server's intended focus.