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 behavioral details beyond annotations, such as the distinction between a permanent non-expiring connection (config header) and a session-only login (paste token). This adds context about state and longevity, which aligns with the idempotentHint annotation without contradicting it.
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 a single, run-on paragraph with parentheses and colon-heavy phrasing ('MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token.'), making it harder to parse quickly. It could be broken into clearer, front-loaded sentences without losing meaning.
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 tool with one optional parameter and no output schema, the description covers the core invocation modes (with/without token) and setup options. However, it leaves implicit the actual return value (e.g., what 'get the link' returns) and error handling, which might be expected given the tool's simplicity.
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 provides no description for the 'token' parameter (0% coverage), so the description takes on the burden and explains its purpose ('call with { token: "<jwt>" } after the user pastes') and the no-args behavior. It effectively compensates for the lack of schema documentation.
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: to authenticate IDE agents by logging in via browser and using an access token. It mentions the resource (access token) and provides a direct action verb ('log in'), making the purpose unambiguous. It doesn't explicitly contrast with siblings like 'connect' or 'marketplace,' but the function is self-evident from the context.
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 call patterns: 'call with { token: "<jwt>" } after the user pastes, or with no args to get the link,' and distinguishes permanent vs. session-based use cases. However, it doesn't reference alternative tools or explicitly state when not to use this tool, so it partially meets the criteria.
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.
Most tools are distinct (authenticate, show_version, report_bug), but there is overlap: connect and toolkit_info both report connection status, and marketplace's list_tools overlaps with toolkit_info. The marketplace tool is a broad catch-all covering search, invoke, install, and billing, which could cause misselection.
Naming is inconsistent: some tools are verbs (authenticate, connect, report_bug), some are nouns (marketplace, toolkit_info), and one is domain-specific (sintegra_se_consultar) with a different style. No clear verb_noun pattern across the set.
Seven tools is a reasonable count for a platform-level server, though the inclusion of a single domain-specific tool (sintegra_se_consultar) alongside generic platform tools feels disproportionate given the server's name.
The platform surface is fairly complete: authentication, connection status, marketplace with search/invoke/install, feedback, version, and toolkit info. Minor gaps exist (e.g., no explicit credential management beyond authenticate, but marketplace actions cover most needs). For the specific SINTEGRA domain, only one query tool exists, but that may be intentional as this is primarily a platform server.