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?
Discloses key behavioral differences: permanent vs. session-based login, and that calling with no args returns a link. Annotations already indicate idempotency; description adds context about token storage and session persistence.
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?
Description is informative but could be slightly trimmed without losing value. Front-loaded with context, each sentence serves a purpose.
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?
Covers usage and parameter well but lacks details on return values (e.g., success confirmation) and error handling. Given no output schema, these omissions reduce completeness.
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%, but the description thoroughly explains the optional 'token' parameter (JWT from user paste) and the alternative no-arg call to get the link, adding essential meaning beyond the 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: authenticating users via browser login and token. It distinguishes from siblings like 'connect' by focusing on authentication flow and token management.
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 explicit guidance on two usage modes (permanent config vs. session-only token paste) and recommends the config approach. Does not compare with siblings but sufficiently directs the agent on when to call with/without arguments.
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.
Tools have distinct primary purposes, but marketplace and search_tools overlap heavily: both cover search/describe/invoke for the MCP catalog. An agent may be uncertain which to call for a simple catalog lookup, though marketplace's broader scope (install, prompts, billing) helps differentiate.
Most tools use verb_noun style (report_bug, search_tools, show_version) or bare verbs (authenticate, connect), but 'marketplace' and 'toolkit_info' are noun-based. The mixed conventions are still readable and predictable enough.
Seven tools is well-scoped for a platform management server. Each tool covers a distinct area: auth, connection status, catalog access, feedback, version, and toolkit state, with no bloat.
The surface covers core platform operations: authentication, connection checks, catalog search/invoke (via marketplace and search_tools), bug reporting, version info, and toolkit state. Minor gaps like explicit uninstall or user management are handled indirectly through marketplace's install/subscribe actions.