MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
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 description goes beyond annotations by explaining that a token in config gives a permanent, non-expiring connection, whereas pasting a token provides only session-scoped login. It also discloses that calling with no arguments yields a link. Given the annotations already convey safety and idempotency, this is meaningful added behavior.
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 reasonably concise and front-loaded with the tool's use context, then clearly enumerates the two options. Minor run-on structure and a slightly awkward first phrase keep it from being maximally polished.
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 single-parameter authentication tool with no output schema, the description provides enough context to invoke it correctly: the browser flow, token behavior, how to pass the token, and the no-args link path. It lacks explicit statements about what happens on success or error, but these are not essential for this tool's basic use.
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 schema provides only a bare 'token' string property, but the description explains that token is a JWT to be pasted after login, that it is optional, that calling without it generates a login link, and that passing it enables session-only login. This fully compensates for the zero schema coverage.
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 identifies the tool as authentication/login (`log in in the browser`, `session-only login`) and distinguishes it from sibling tools by its specific browser/token flow. It also states the two concrete invocation modes: providing a JWT or requesting a link.
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 explains when to use each form: permanent setup via config header, session-only via token argument, and link generation with no args. It does not explicitly contrast authentication with alternative tools like connect, so it stops slightly short of full when/not guidance.
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.
Every tool has a clearly distinct purpose. The consulta tools target specific databases (CND, FGTS, trademarks, sanctions) with descriptive names, and the administrative tools (authenticate, marketplace, etc.) are unrelated to the queries. No two tools appear to perform the same function.
The majority of tools follow a consistent 'consultas_' prefix with descriptive suffixes, but the administrative tools (authenticate, connect, marketplace, report_bug, etc.) break the pattern with plain verb/noun names. This creates two distinct naming conventions within the same server.
At 29 tools, the set is bloated. The inclusion of a full marketplace tool and generic admin/version/feedback utilities goes beyond the core 'consultas' purpose, making the count feel excessive. The query tools themselves are numerous but could be trimmed.
The set covers a wide range of Brazilian data consultations, from debts and tax status to trademarks, patents, and sanctions. Minor gaps exist (e.g., no general court case search beyond SEEU), but the core domain is well covered and agents can accomplish most common query tasks.