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 behavioral difference between calling with and without the token, and notes that config-based tokens are permanent while session tokens are not. Annotations indicate idempotent, which aligns. No contradictions, and the description adds context beyond the annotations about the two login modes.
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 three sentences, each presenting a distinct and necessary piece of information: the context, the best practice, and the alternative usage. No fluff, well-structured.
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 is simple (one optional parameter, no output schema), the description sufficiently covers the purpose and usage. It could mention error cases or the link format, but it is complete enough for an agent to decide whether and how to invoke it. Sibling tools do not overlap significantly.
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 has no description for the 'token' parameter (0% coverage). The description compensates fully by explaining that 'token' is a JWT access token and that omitting it returns a login link. This is clear and actionable.
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 is for authentication ('log in') for MCP.AI IDE agents. It specifies the exact usage: obtaining a token from the browser and either adding it to config for permanent access or passing it as a JWT for session-only login. This distinguishes it from siblings like 'connect' or 'marketplace'.
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 explicit guidance on when to use each mode (config vs. session token vs. no arguments to get link). It implies when to use by outlining the best practices, but does not explicitly exclude alternative tools or scenarios.
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 openfinance_* tools target distinct resource/action pairs, but openfinance_list_connections and openfinance_get_item_status overlap on connection status/reconnect URLs, and openfinance_list_transactions vs openfinance_list_transactions_by_item can be confused. The long descriptions reduce ambiguity, but selection risk remains.
The openfinance_* block is consistently verb_noun, but the platform tools mix bare verbs (authenticate, connect), nouns (marketplace), and noun_info (toolkit_info). No single naming convention spans the whole set, though each subgroup is internally readable.
At 25 tools, this sits at the top of the heavy borderline range. The broad scope—MCP.AI platform management, prompt library, and Open Finance data—justifies many tools, but the set feels like a bundled suite rather than a tightly scoped single-purpose server.
The Open Finance side is well covered: accounts, balances, transactions, credit card bills, loans, investments, connections, sync, status, provider health, and category updates. The platform side has auth, toolkit info, marketplace, and feedback. Minor gaps exist, such as no explicit identity fetch or payment initiation, but those seem outside the intended read/analysis domain.