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, so the safety profile is established. The description adds valuable behavioral context by explaining the conditional returns (authenticated:true with empty pending[] vs. connect_url and per-install URLs), which goes beyond what annotations provide.
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, front-loads the primary purpose, and clearly explains both outcome scenarios. Every sentence contributes value without redundancy or unnecessary detail.
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 zero-parameter tool with clear annotations and no output schema, the description fully covers the necessary information. It explains what the tool returns in both success and incomplete credential states, making the behavior clear enough for an agent to invoke correctly and interpret results.
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 trivially covers them (100% coverage). The description adds meaning by explaining the output behavior based on credential availability, which compensates for the lack of parameters and enriches understanding.
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 returns 'connection status and URLs', which is a specific verb+resource. It distinguishes from sibling tools like 'authenticate' by focusing on status rather than performing authentication, and explicitly describes the two possible outcomes.
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?
Usage is implied through the description of what the tool returns, but there is no explicit guidance on when to use this over alternatives like 'authenticate' or other informational tools. The context signals indicate sibling tools, but the description does not mention any exclusions or alternatives.
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 clear purposes, but 'connect' and 'toolkit_info' both report connection/state information, and 'authenticate' overlaps with 'connect' around authentication. The single domain-specific tool 'similaridade_mx_consultar' stands apart, but the platform tools could still confuse an agent.
Naming is mixed: bare verbs ('authenticate', 'connect'), nouns ('marketplace', 'toolkit_info'), verb_noun compounds ('report_bug', 'show_version'), and a Portuguese phrase ('similaridade_mx_consultar'). No consistent convention across the set.
Seven tools is a reasonable number, but the server's stated purpose (identity similarity in México) is served by only one tool; the rest are generic platform helpers. This makes the count feel mismatched to the domain, though not excessive.
The platform utilities cover authentication, state, marketplace, and feedback adequately. However, the domain-specific 'consultar' tool is a single query with no additional operations like history, batch, or validation, leaving gaps for a comprehensive identity-similarity service.