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?
Beyond the annotations (idempotent, non-destructive, non-read-only), the description adds meaningful behavior: the permanent non-expiring connection, session-only scope of pasted tokens, and the conditional behavior of no-args returns the link. No contradictions.
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 efficiently structured with an introductory context sentence followed by practical instructions. The 'Best:' versus 'Or paste it here' framing makes the two main options easy to parse. It is slightly denser than strictly necessary but every sentence earns its place.
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 one-parameter, optional-token auth command, the description adequately covers the intents, the login flow, the permanent vs session distinction, and the no-args behavior. It does not specify the response format besides getting the link, but with no output schema, this is a minor gap.
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 only defines 'token' as a string with no description (0% coverage). The description compensates by explaining the exact usage: 'call with { token: "<jwt>" }' or call with no arguments, adding crucial meaning that the schema cannot provide.
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 the server to MCP.AI for IDE agents, with login in a browser and token-based connection. It uses a specific verb and resource, and while it doesn't explicitly contrast with sibling 'connect', its auth-only scope is unmistakable.
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 strong practical guidance: it recommends permanent config-based auth, explains session-only token paste for one-off login, and tells the agent to call with no args to obtain the login link. It lacks explicit 'when not to use' or references to sibling tools, but covers the main usage paths well.
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.
authenticate, connect, and toolkit_info all address authentication/connection state and could easily lead an agent to pick the wrong one. marketplace also contains sub-actions (invoke, report_bug, get_prompt, etc.) that overlap with the dedicated sintegra_ap_consultar and report_bug tools, so boundaries are unclear.
Names mix bare verbs (authenticate, connect), nouns (marketplace, toolkit_info), verb_noun pairs (report_bug, show_version), and a Portuguese reverse-order name (sintegra_ap_consultar), so there is no consistent action-object convention. Only the lowercase snake_case style is uniform.
Seven tools is a manageable number, and the platform utility tools have clear maintenance roles. The scope is slightly awkward though, because six generic meta-tools surround a single SINTEGRA lookup and marketplace bundles many capabilities into one tool.
For a single-source Brazilian official-data lookup, sintegra_ap_consultar may be enough, and marketplace covers install/billing/prompt workflows. However, there are notable gaps around wallet/credit visibility, logout/revocation, and query history, and the domain purpose is diluted by generic platform tooling.