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 adds useful behavioral context beyond the annotations: a token call creates a session-only login, no-args returns a link, and config-based header auth gives a non-expiring connection. It does not describe error cases or response details, but the annotations already cover the basic safety profile.
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 a dense single passage mixing user instructions, config advice, and tool-call syntax. It is informative but not tightly structured; the 'Best:' configuration guidance could be separated or trimmed to make the actual tool invocation pattern stand out more clearly.
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 one-parameter auth tool with no output schema, the description covers both invocation modes and the recommended permanent alternative. It does not explicitly state what the tool returns, but that is acceptable given the absence of an output schema and the simplicity of the tool.
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?
Schema coverage is 0%, and the description fully compensates by explaining that the optional token is a JWT/access token obtained via browser login. It also clarifies the no-args mode, which is essential for the agent to use the tool correctly.
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 an authentication flow for MCP.AI: browser login, token exchange, and login-link generation. It specifies the resource (MCP.AI) and the action (log in/authenticate), and it is distinguishable from sibling tools like connect or marketplace.
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?
It explicitly contrasts permanent config-based auth ('Best: add it to this server's config as a header') with session-only token calls, and instructs calling with no args to obtain the login link. It does not explicitly reference sibling tools, but the guidance is clear enough for choosing between no-arg and token-arg invocation.
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 actual tribunal consultation tool is clearly distinct, but authenticate, connect, and toolkit_info all overlap around session, connection status, and credentials, and marketplace also covers listing and running tools. An agent can easily misselect among these platform/management tools.
Names are all lowercase and readable, but the pattern is mixed: some are simple verbs like connect and report_bug, others are noun-style like marketplace and toolkit_info, and the domain tool is a long Portuguese snake_case phrase. There is no consistent verb_noun convention across the toolset.
Seven tools is a reasonable number, so the count itself is fine. However, most of the tools are platform-management plumbing for authentication, connection status, marketplace navigation, and version reporting, rather than legal-domain capabilities.
Authentication, consultation, and feedback workflows exist, so the core path is usable. Still, the legal domain is represented by only one dedicated process-consultation tool, with no additional related operations or follow-up actions for real case-consultation workflows.