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 only provide safety/idempotency flags; the description adds the actual behavior: browser login flow, token copy, and the permanent-vs-session distinction. It is consistent with idempotentHint=true and destructiveHint=false and gives a good sense of side effects, though it omits error cases or invalid-token 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 front-loads the core purpose before the usage alternatives. It contains informal asides like 'Best:' but every clause earns its place in explaining how the tool should be invoked.
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-optional-parameter tool this is nearly complete: it covers the token format, the no-args link mode, and the token lifetime trade-off. It does not describe the response shape or failure cases, and there is no output schema to fill that gap, so a small amount of uncertainty remains.
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 zero description coverage for the single optional token parameter. The description fully compensates by explaining the exact invocation contract: no args yields the login link, and passing { token: '<jwt>' } completes a session login. This is unambiguous enough to call correctly.
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 names the action (log in to MCP.AI), identifies the resource, and lays out concrete modes: browser login, copying an access token, configuring a permanent header, or pasting a token for a session. It is distinct from sibling tools like connect or the Protheus data 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?
It distinguishes permanent header configuration from session-only token pasting and explicitly states when to call with no args versus with { token: '<jwt>' }. It does not name an alternative sibling to prefer, but the two usage modes are sufficiently clear for an agent to choose correctly.
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.
Each protheus_* tool targets a distinct ERP entity or API, and descriptions explain the resource and key arguments, so an agent can usually pick the right one. The main ambiguities are the generic protheus_api, which overlaps with every dedicated reader, and the trio protheus_catalogo/protheus_diagnostico/protheus_modulos, all of which are about API/module availability.
The domain tools consistently use the protheus_ prefix in snake_case with a descriptive resource suffix, which is predictable once the pattern is recognized. There are minor deviations such as protheus_list_accounts using an English verb and the platform-level tools (authenticate, connect, marketplace, show_version, toolkit_info) not following the protheus_ prefix at all.
32 tools is above the threshold where a tool list becomes heavy for agents to scan, even though the ERP domain is broad. The set could be split into a focused Protheus reader plus a platform-management server, or several entities could be combined behind parameterized tools.
The read-only surface covers a wide range of common Protheus areas (customers, products, stock, sales, production, pricing, CRM) and protheus_api with catalogo/diagnostico allows access to additional official/custom read routes. However, there are no create/update/delete tools at all, and major ERP areas such as financial movements and HR are absent, so mutation workflows dead-end in this server.