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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, and the description aligns by noting call without args returns a link. No contradictions. It adds context about token behavior and session vs permanent setup, beyond what annotations provide.
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 informative but somewhat verbose and run-on in the first sentence. It could be more concise while retaining the same information. Still, it front-loads key actions.
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 adequately covers the tool's purpose and usage. It mentions the link and access token but does not detail the return format. Sufficient for a simple 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?
With 0% schema coverage, the description fully compensates by explaining the 'token' parameter as optional for session login and detailing both invocation methods (with or without token). This adds essential meaning beyond the schema's simple type definition.
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 and login, providing context for IDE agents. It distinguishes from siblings like 'connect' or 'marketplace' by focusing on token generation. However, it lacks a single concise verb+resource phrase.
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 gives explicit guidance on two usage modes: permanent config via header or session-based login with token parameter. It does not explicitly state when not to use, but the context is clear.
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.
marketplace and search_tools have significant overlap, with both covering search, describe, and invoke actions for the MCP catalog. connect and toolkit_info also both provide connection/status information, creating ambiguity about which to use for state checks.
Tool names mix verb-only (authenticate, connect), noun-only (marketplace), and verb_noun patterns (report_bug, search_tools, show_version, toolkit_info). There is no consistent convention, making the naming feel chaotic.
Seven tools is a reasonable count for a management/marketplace utility. However, the broad marketplace tool bundles many sub-operations that could arguably be split, and the server name 'Olist Tiny ERP' suggests a completely different domain, making the count feel misaligned with expectations.
Within the MCP management domain, the tools cover authentication, connection status, catalog search/execution, version info, and bug reporting. Gaps include no dedicated tool for managing installed MCP configurations or direct access controls beyond what's bundled in marketplace. The server name implies ERP functionality entirely absent, making the surface incomplete for the stated name.