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?
Annotations already indicate idempotent, non-destructive, non-read-only behavior. The description adds useful context: no args returns a login link, passing a token establishes a session, and configuring a header gives a permanent connection. It does not fully describe response details or side effects, but the added behavioral context is meaningful.
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 compact and front-loaded with the core purpose, followed by actionable usage details. It is slightly dense with multiple clauses, but every sentence adds useful information and there is no redundancy.
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-optional-parameter authentication tool with no output schema, the description covers the main flows, the recommended configuration, and session-only login. It could mention what the tool returns or error scenarios, but overall it is sufficiently complete for an agent to invoke it correctly.
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 input schema only defines 'token' as a string with no description. The tool description fully explains the token's meaning (JWT pasted by the user) and the behavior when omitted (returns the login link), compensating entirely for the 0% 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 states the tool's purpose: authenticating MCP.AI for IDE agents via browser login and access token. It distinguishes itself from siblings by specifying the exact auth flow and the two invocation modes (with or without token).
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 explains when to use the token-paste session-only mode versus the recommended permanent config-header approach. It does not explicitly compare against sibling tools like 'connect', but it provides clear usage context and 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.
The three DJEN-specific tools are fairly distinct, but djen_search_comunicacoes and djen_processos_por_parte both find legal matters by party/name and could be confused despite their different coverage. The generic platform tools like authenticate, connect, and toolkit_info also overlap somewhat around connection state and access.
Naming is inconsistent: djen_* tools use snake_case with a domain prefix, while platform tools use bare imperative verbs like authenticate, connect, report_bug, and show_version, and marketplace is a single noun. There is no unified convention across the set.
Nine tools is a reasonable count, but six of them are generic platform utilities unrelated to DJEN, leaving only three legal-domain tools. The server feels diluted rather than well-scoped, though it is not extreme.
The domain surface covers DJEN publication search, party-name discovery, and PDF retrieval, but the descriptions reference missing capabilities such as CPF/CNPJ lookup, datajud process confirmation, and historical process coverage. Agents cannot complete important legal workflows using only the tools actually provided.