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 indicate idempotentHint=true and destructiveHint=false, which align with the description's non-destructive nature. The description adds context about token expiration (permanent vs session-only) and the browser login flow, which is valuable beyond annotations.
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?
Two sentences, front-loaded with the tool's purpose, and every clause adds value. No fluff or repetition.
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?
Given the tool's simplicity (1 optional param, no output schema), the description covers the essential flow: browser login, token acquisition, and two usage modes. It could mention what the response looks like, but the lack of output schema reduces the burden.
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 has 0% description coverage, but the description explains the token parameter's purpose and format (JWT) and how to use it. It also clarifies that the parameter is optional (no args to get link). This compensates well for the schema's lack of detail.
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 to MCP.AI for IDE agents by logging in via browser and obtaining an access token. It distinguishes itself from siblings by being the only authentication tool among data/query 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?
Provides explicit usage guidance: recommends adding token to server config for permanent connection, or pasting token as argument for session-only login, or calling with no args to get the link. Clearly explains when to use each approach.
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 cigam_* tools target a distinct ERP area (AP, AR, sales, purchases, inventory, cash), and descriptions clarify their boundaries. However, the sales-reporting cluster (vendas, vendas_por_dia, vendas_resumo, resultado, ranking_clientes) has overlapping period-summary purposes, and cigam_estoque overlaps with REL_610 in cigam_relatorio, creating a few plausible misselections.
The 21 domain tools mostly follow a cigam_<snake_case noun> pattern, giving a recognizable prefix, but they mix Portuguese and English for the same operation (cigam_listar_lojas vs cigam_list_accounts) and mix noun-tools with verb-tools (consulta/relatorio/job vs listar). The 7 infrastructure tools (authenticate, connect, marketplace, etc.) use a completely different unprefixed English style, so there are effectively three naming conventions.
At 28 tools the server exceeds the heavy threshold, and the count is padded by a fragmented sales-reporting family (four-plus tools all summarizing sales) plus a monolithic marketplace tool that bundles search, describe, invoke, install, subscription, and prompt-library operations. The broad ERP domain justifies many tools, but this set would benefit from consolidation.
As a read-only reporting/advisory adapter, the surface covers the main ERP workflows: sales, purchases, returns, invoices, AP/AR, delinquency, cash flow, payment mix, stock, financial entries, results, and custom reports. Notable gaps are a customer master list, product names in stock data, and per-document detail lookups, but the generic cigam_consulta and cigam_relatorio provide workarounds.