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 include idempotentHint=true and readOnlyHint=false, but the description adds context: the tool initiates browser login, returns a link, and accepts a token for session or permanent access. It does not contradict annotations. It could mention that calling with no args may open a browser or return a link, but it already says 'get the link'. No annotation 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 is moderately sized, but it is slightly verbose with the IDE agent framing and multiple clauses. It front-loads the key action and provides necessary details. Could be tightened but is acceptable.
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?
Given the tool's simplicity (one optional param, no output schema, no nested objects), the description is complete enough. It explains both the no-arg and token modes, and the permanent vs. session option. It lacks details on what the response looks like, but output schema absence makes that less critical.
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 has one optional parameter 'token' with no description. The description explains its purpose: 'paste it here for a session-only login: call with { token: "<jwt>" } after the user pastes'. This adds meaning beyond the schema, providing type and usage context.
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 that this tool is for authentication: it provides a login link or accepts a token. It distinguishes itself from siblings (connect, marketplace, etc.) by focusing on the auth flow for IDE agents. However, it could be more explicit that this is the authentication entry point vs. other connection tools.
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 gives explicit usage scenarios: best practice is to add the token as a header in config for permanent access, or paste it here for session-only login. It also explains the two modes: call with token or no args to get a link. This provides clear when-to-use 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.
The discord_* tools are clearly separated by resource and action; get/list and channel/DM variants are unlikely to be confused. Slight ambiguity exists between authenticate/connect and the fact that marketplace bundles report-style actions alongside the standalone report_bug, but descriptions mostly resolve this.
The Discord-specific tools all follow a regular discord_verb_noun pattern, which is clean. The six non-Discord tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) break that pattern, creating a mixed convention that is still readable.
21 tools is on the heavy side; the 15 Discord operations are reasonable, but the six platform/meta tools and the sprawling marketplace tool broaden the set beyond a pure Discord server. It is not excessively bloated, but it feels like two tool surfaces in one.
The message lifecycle is well covered: send, edit, delete, list, get, reply, and reactions. Minor gaps include reaction removal and administrative actions like create/update/delete channels or guilds, but the core communication workflows an agent needs are present.