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?
Description details the side effects: token added to config gives a permanent non-expiring connection, while pasting here gives session-only. It also notes that calling with no args produces a login link. Annotations are simple (idempotent, non-destructive) and the description does not contradict them, adding meaningful behavior context beyond the schema.
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?
Three sentences that are informative and front-loaded, but the first sentence mixes tool purpose with user instructions (logging in in the browser), making it slightly longer than necessary. Still, each clause adds value and there is no fluff.
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 (one optional parameter, no output schema), the description covers the complete behavior: what the token is, how to provide it, and what happens in each scenario. It effectively compensates for the lack of schema parameter descriptions.
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 only defines 'token' as a generic string, but the description explains it as a JWT, distinguishes between providing it for session login vs. permanent config, and specifies calling with no arguments. This fully compensates for the 0% schema description coverage.
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 that the tool authenticates the MCP server for IDE agents, with a specific verb ('log in') and resource ('server'). It distinguishes itself from all sibling tools, which are compliance search tools, by focusing purely on authentication.
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?
Explicitly explains when and how to use: call with a token for a session-only login, call with no arguments to get a link, and recommends adding the token to config for a permanent connection. This provides clear context on when to invoke it and how the token should be supplied.
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 compliance tools are clearly distinct by their target registry (e.g., CEIS, CNEP, CEPIM), but some overlap exists between similar sanction lists (e.g., compliance_cgu vs compliance_ceis) and between PEP variants. The non-compliance tools (authenticate, marketplace, connect) are distinct but serve a different purpose, adding potential confusion.
The compliance tools follow a consistent 'compliance_<registry>' pattern, which is predictable. However, the non-compliance tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) break the pattern, and some compliance tools have longer names with underscores (e.g., compliance_mandados_prisao) but still follow the convention.
With 37 tools, the count is on the higher side but justified for a compliance server covering many distinct sanction lists and registries. However, the inclusion of non-compliance tools (marketplace, authenticate, etc.) inflates the count and blurs the server's focus, making it feel heavier than necessary.
The compliance domain is well covered with a wide range of national and international sanction lists, PEP checks, and professional registries. Minor gaps exist (e.g., no tool for some specific lists like OFAC's non-SDN list, or no batch query), but the core compliance workflows are well supported.