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 discloses significant behavioral details beyond the annotations: it explains the permanent vs. session-only nature, the option to store the token in the server config, and the no-args behavior (returns a link). Annotations only indicate idempotentHint and non-destructive, so the description adds relevant side-effect context without contradiction.
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 front-loads the primary purpose and then provides essential usage details in three sentences. It is slightly verbose but every sentence contributes necessary information (two modes and the no-args alternative). No unnecessary fluff, but could be tightened slightly.
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?
The description covers the main flows: how to get the link, how to use a pasted token, and the optional permanent config approach. It does not mention the return value of the tool (e.g., success message or token validation), but given the minimal schema and lack of output schema, the description is reasonably complete for a simple authentication 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?
The schema has no description for the token parameter (0% coverage), but the description compensates by explaining its purpose: 'call with { token: "<jwt>" } after the user pastes', and the optional no-args case. This adds meaning beyond the bare schema, making the parameter's semantics clear.
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's purpose: logging in the browser and obtaining an access token for MCP.AI. It explicitly mentions IDE agents like Cursor and differentiates from generic connection tools (e.g., connect) by focusing on the token-based authentication flow and the two usage modes.
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?
Provides clear context on using the tool for login, including two invocation patterns: passing a token for session-only login or calling without args to get a link. It recommends the config header approach for permanent connections. However, it does not explicitly exclude alternative tools or state when not to use this tool, so it misses the 'when-not/alternatives' criterion for a 5.
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 Tribunal TRF1 query tool is clearly distinct, but there is some ambiguity among the platform utilities: authenticate and connect both relate to connection/auth flow, and marketplace duplicates report-like and toolkit-inspection concepts. An agent can usually select the right tool, but only because the descriptions are long and corrective.
Naming is inconsistent: bare verbs (authenticate, connect), a noun (marketplace), and snake_case verb/noun forms (report_bug, show_version, toolkit_info) are mixed with a very long Portuguese domain name. This does not follow a predictable verb_noun pattern and mixes English and Portuguese conventions.
Seven tools is not excessive, but only one tool actually belongs to the Tribunal TRF1 domain while the other six are generic marketplace/configuration utilities. The set feels top-heavy and under-focused for a server whose main purpose appears to be consulting TRF1 court processes.
For a read-only public consultation service, a single consultar tool may be acceptable, especially since the description implies it returns information from official sources. However, there are no search, listing, or multi-query options, and the generic platform tools do not add meaningful domain coverage.