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?
It discloses key behaviors: browser login, permanent non-expiring token via config, session-only token paste, and no-args behavior returning the link. This complements the annotations without contradicting them; the idempotentHint and destructiveHint are consistent with the described behavior.
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 compact and information-dense, covering context, two authentication modes, and call patterns in two sentences. It is slightly dense in the opening clause, but every sentence adds necessary 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?
For a simple authentication tool with one optional parameter and no output schema, the description covers the main workflow, configuration option, session login, and no-args link retrieval. It lacks failure/error handling details but is otherwise complete for practical use.
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?
Although the schema has no parameter descriptions and coverage is 0%, the description explains the only parameter 'token' as a JWT to paste for session-only login, and defines behavior when omitted. This compensates well for the missing schema-level semantic information.
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 explains that the tool handles authentication for MCP.AI with a browser login and access token flow. It is not explicitly differentiated from the 'connect' sibling, but the purpose is specific and actionable.
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 clear guidance on when to use the permanent config-header approach versus a session-only token login, and when to call with or without arguments. It does not explicitly compare against sibling tools like 'connect', but the usage paths are well defined.
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 `marketplace` tool bundles many operations (search, describe, invoke, install, list, subscribe, cancel, request_mcp, report_bug) that overlap with dedicated tools like `report_bug`, `connect`, and `toolkit_info`. This creates unclear boundaries between platform status, catalog discovery, and bug reporting.
Tool names mix bare verbs (`authenticate`, `connect`), single nouns (`marketplace`), noun phrases (`toolkit_info`), and verb_noun patterns (`show_version`, `report_bug`). The Portuguese `sintegra_am_consultar` also breaks the English verb-first convention.
Seven tools is a reasonable count and generally well-scoped, but the `marketplace` tool alone accounts for a very large amount of functionality that could be split into multiple tools. The number is not excessive, but the distribution is uneven.
Core platform flows are covered: authentication, connection status, marketplace discovery/execution/installation, toolkit info, version checking, and feedback. The SINTEGRA side is minimal, and there is no explicit disconnect/logout or consultation history, but the main intended workflows are present.