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?
The annotations already declare readOnlyHint=true and idempotentHint=true, establishing a safe, non-mutating profile. The description adds useful behavioral details about two states: all providers connected (authenticated:true, empty pending[]) and missing credentials (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-loaded with the main purpose, and each sentence provides distinct, useful information (general return type and conditional states). No 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, the description adequately covers the main return behaviors. There is no output schema, so the description must explain return values, which it does for the two key scenarios. However, it does not elaborate on possible intermediate states (e.g., partial connectivity), but this is a minor gap.
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 schema coverage is effectively complete. With no parameters to document, the description does not need to add parameter-level semantics, and the baseline of 4 applies.
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 that the tool returns connection status and URLs, which is a specific verb+resource pair. It implicitly distinguishes from the sibling 'authenticate' by focusing on status rather than the authentication action itself, but it does not explicitly contrast with siblings.
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 implies that this tool is for checking connection status, but it does not explicitly state when to use it versus alternatives like 'authenticate'. There is no direct guidance on when to invoke this tool or when to avoid it.
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 INPI-specific tools are clearly distinct: busca searches by term, processo gets full details, processo_resumido gets a summary, titular finds by holder, and patentes finds patents. The generic tools (authenticate, connect, marketplace, etc.) are also distinct from each other, though the mix of domain and platform tools creates some initial ambiguity about which to use for a given task.
INPI tools follow a consistent prefix pattern (inpi_marcas_*, inpi_patentes), but the generic tools use simple action_noun names without the prefix (authenticate, connect, marketplace). This mixed convention is readable but not fully consistent across the set.
With 11 tools, the count is within a typical range, but the scope is split between 5 INPI domain tools and 6 platform/utility tools that seem unrelated to the server's stated purpose. This dilutes the focus and makes the set feel over-inclusive for a dedicated INPI server.
The INPI tools cover trademark search, process details (full and summary), trademarks by holder, and patents by holder, but lack a patent search by term or other advanced INPI queries. The generic tools add no domain coverage, leaving notable gaps for a comprehensive IP tool suite.