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 include idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds that the token can be non-expiring when added to config, and explains the session vs permanent distinction. It does not contradict annotations, and adds useful behavioral context beyond annotations, though it does not discuss potential side effects (like creating a session) explicitly, but the idempotency hint covers that.
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 a bit long (two sentences with parentheticals) but every clause adds necessary info: audience, method, permanent vs session, and argument usage. It is structured logically, though it could be tightened without losing value. It is front-loaded with the main action.
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 has 1 optional param, no output schema, and annotations, the description covers the essential context: how to authenticate, the two modes (config vs session), and what the agent should do (call with token or no args). It doesn't specify the return value (e.g., link), but that is implicit. It is complete enough for a simple auth tool, though a note on error cases could be added.
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 description coverage is 0%, but the description explains the only parameter 'token' as a JWT to be pasted. It gives clear usage context: with token for session login, without token to get link. This adds semantic meaning beyond the bare schema, which only says 'type: string'. Since there is only 1 param and it's fully described, this is strong.
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 states the purpose: authenticate by logging in via browser and copying an access token, with options for permanent config or session-only paste. It clearly identifies the resource (authentication) and the action (authenticate), though it could be more concise. It does not explicitly differentiate from sibling tools, but the purpose is clear enough.
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 when-to-use guidance: for IDE agents like Cursor, log in via browser, copy token, and either add to config for permanent connection or paste for session-only login. It also explains the argument variations (with token, with no args) and the context (after user pastes). This is comprehensive and actionable.
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 (authenticate, connect, marketplace, report_bug, show_version, toolkit_info), but 'connect' and 'authenticate' overlap in handling connection/auth state, and 'toolkit_info' overlaps partially with 'connect' in reporting connection status. The main domain tool mpt_se_cnf_consultar is clear, but the platform-management tools create some boundary ambiguity.
Naming is inconsistent: snake_case for the main tool (mpt_se_cnf_consultar) but lowercase single-word names for others (connect, marketplace), and underscore-free names like 'report_bug' and 'show_version' mix styles. No clear verb-noun pattern; some are nouns, some verbs, and the domain tool is an opaque identifier.
Seven tools is within a reasonable range, but the server bundles many platform-management utilities (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) around a single domain operation (mpt_se_cnf_consultar). The count feels inflated for the server's apparent purpose of querying negative certificates, though it is not extreme.
For the domain of consuting negative certificates, there is only one operation (mpt_se_cnf_consultar) with no supporting tools like list of available certificate types, history, export, or cancellation. The other tools are about platform management rather than the domain, leaving the core workflow thin and incomplete.