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?
The description explains the two behavioral modes (returning a link vs. authenticating with a token) and the permanent vs. session distinction. Annotations already indicate idempotency and non-destructiveness; the description aligns with and adds context to these traits.
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 fairly concise, fitting two sentences, but the second sentence is long and packs multiple use cases. It front-loads the purpose but could be broken into bullet points for clarity without adding length.
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 no output schema, the description should ideally state what the tool returns (e.g., success message, token, error). It describes the two invocation modes but omits the return value, which is a notable gap for an authentication tool.
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 input schema provides only a bare 'token' parameter with no description. The description compensates fully by explaining that the token is a JWT access token, that omitting it returns a login link, and how to obtain it. This adds significant semantic value.
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 the user for MCP.AI IDE agents, providing instructions for both permanent and session-based login. It distinguishes itself from sibling tools by being the dedicated authentication mechanism.
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 guidelines on when to use each authentication method (config vs. session) and how to invoke the tool (with or without token). However, it does not explicitly compare to sibling tools like 'connect' or other authentication-related tools, missing an opportunity to clarify when to choose this tool over alternatives.
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 have distinct purposes, especially with the openfinance_ prefix grouping banking operations. However, pairs like openfinance_list_accounts vs openfinance_get_accounts_detail and openfinance_get_credit_card_bill vs openfinance_list_credit_card_bills could cause minor confusion, though descriptions help.
Tools consistently use snake_case with a clear verb_noun pattern. Open finance tools all start with openfinance_, and utility tools use simple verbs like authenticate, connect, report_bug. No mixing of conventions.
At 24 tools, the count is on the higher side of the borderline range. The server combines platform management (6 tools) and banking operations (18 tools), which justifies the number, but it feels slightly heavy for a single server.
The tool surface covers all major banking operations (accounts, transactions, credit cards, investments, loans) and includes essential maintenance tools (sync, status, disconnect, search connectors). Platform management is also comprehensive with authentication, marketplace operations, and diagnostics.