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 indicate idempotent and non-destructive behavior. The description adds meaningful behavioral context: calling with no args returns a login link, passing a token establishes a session-only login, and configuring the header gives a permanent connection. It also clarifies the JWT nature of the token, which goes beyond the annotations.
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 concise and front-loaded, explaining the purpose in the first phrase. It packs essential details into two sentences, covering both usage modes and the session/permanent distinction without unnecessary filler. Slightly long for a tool description, but every clause adds value.
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?
There is no output schema, but the description implicitly covers return behavior ('get the link') and the interaction flow (user pastes token). It addresses the main scenarios—permanent config, session token, and link retrieval—but does not detail error handling or post-auth state, which is acceptable for an auth helper.
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%, so the description fully compensates by explaining the 'token' parameter as a JWT from the browser, noting it is optional, and describing the no-arg behavior (returns a link). This gives complete semantic meaning to the parameter despite the bare schema.
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: authenticate with MCP.AI for IDE agents. It specifies the exact flow (log in, copy token, provide it) and distinguishes between two authentication modes (config header vs session token), making it distinct from sibling tools like 'connect'.
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 provides explicit usage guidance: it recommends the permanent config header approach, explains the session-only token option, and clarifies when to call with no arguments (to get a link). It does not explicitly mention alternatives or when not to use, but the guidance is clear and contextually sufficient.
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.
Each tool has a clear primary purpose: authenticate, query CNEP, connect, marketplace, report bug, show version, and toolkit info. The only overlap is between connect and toolkit_info, both of which report connection status, but their roles are otherwise distinct.
Tool names mix bare verbs (authenticate, connect), a noun (marketplace), noun_verb (cnep_consultar), and verb_noun (report_bug, show_version), with inconsistent use of underscores. There is no uniform pattern, which makes the set feel haphazard.
Seven tools is within the acceptable range, but the balance is skewed: only one tool (cnep_consultar) addresses the server's apparent domain, while the other six are generic platform utilities. This makes the count feel inflated for a CNEP-focused server, though each tool does have a role.
For the CNEP domain, the set provides only a single lookup operation, with no options for broader searches, history, or data export. The platform utilities are comprehensive for their meta-purpose, but they do not fill the domain coverage gap.