Skip to main content
Glama
LicentiumIO

compass-mcp

by LicentiumIO
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

compass-mcp

An MCP server that grounds your LLM in EU financial, crypto and AI regulation via Compass. Add it to Claude Desktop, Cursor, or any MCP host, and the model can pull the governing EU provisions, verbatim and article-cited, before it answers.

It exposes two tools over Compass's public grounding API:

  • compass_retrieve: a question in, the top governing provisions out (verbatim text, article-level citations, cross-references) from the core EU acts (MiCA, DORA, MiFID II, the AML package, the AI Act, GDPR and more).

  • compass_verify: check that a quote is a verbatim span of a specific provision, so the model never misquotes the law.

1. Get an API key

Create a key at compass.licentium.ai/developers. It looks like ck_live_.... The first calls are free; after that, usage is metered against your Compass credits. Keep the key secret.

Related MCP server: Lextiva Compliance MCP Server

2. Install and build

git clone <this-repo> compass-mcp
cd compass-mcp
npm install
npm run build

This produces dist/index.js. (Once published to npm, hosts can run it with npx -y @licentium/compass-mcp and skip the clone/build.)

3. Configure your MCP host

Set COMPASS_API_KEY to your key in the server's environment.

Claude Desktop

Edit claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "compass": {
      "command": "node",
      "args": ["/absolute/path/to/compass-mcp/dist/index.js"],
      "env": { "COMPASS_API_KEY": "ck_live_your_key_here" }
    }
  }
}

Restart Claude Desktop. You should see compass_retrieve and compass_verify in the tools list.

Cursor

Add to ~/.cursor/mcp.json (or the project's .cursor/mcp.json):

{
  "mcpServers": {
    "compass": {
      "command": "node",
      "args": ["/absolute/path/to/compass-mcp/dist/index.js"],
      "env": { "COMPASS_API_KEY": "ck_live_your_key_here" }
    }
  }
}

Any other MCP host

Run the binary over stdio with COMPASS_API_KEY set:

COMPASS_API_KEY=ck_live_your_key_here node dist/index.js

Tools

compass_retrieve

Param

Type

Notes

query

string

A regulatory question in plain language.

top_k

number

Optional. Provisions to return, 1 to 20 (default 8).

Returns the governing provisions as verbatim text, each with its reference (e.g. MiCA, Article 59), a node_id, and any cross-references. Feed a node_id into compass_verify to confirm a quote.

compass_verify

Param

Type

Notes

node_id

string

The node_id of a provision from compass_retrieve.

quote

string

The exact text you intend to attribute to it.

Returns whether the quote is a verbatim span of that provision.

Configuration

Env var

Required

Default

Notes

COMPASS_API_KEY

yes

(none)

Your ck_live_ key.

COMPASS_API_URL

no

https://compass.licentium.ai

Override only for self-hosted endpoints.

Notes

Compass returns primary-law text only. It is a research and scoping tool, not legal advice. When the corpus does not govern a question, compass_retrieve returns nothing rather than guessing, so instruct your model not to assert an ungrounded answer.

Logs go to stderr so they never corrupt the stdio JSON-RPC stream.

Available Tools

2 tools
compass_retrieveA

Ground a claim in EU financial, crypto or AI regulation. Returns the top governing provisions from the core EU acts (MiCA, DORA, MiFID II, the AML package, the AI Act, GDPR and more) as VERBATIM text with article-level citations and cross-references. Call this BEFORE stating anything about EU financial/crypto/AI regulation, and cite the returned provisions by their reference. If nothing is returned, do not assert an answer.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesA natural-language regulatory question, e.g. 'Does a custodial wallet need a CASP licence under MiCA?'
top_kNoHow many provisions to return (default 8).

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; the description discloses that the tool returns verbatim text with article-level citations and cross-references, which is sufficient for a retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with the purpose front-loaded and no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 explains what the tool returns (verbatim text, citations) and its context of use, making it complete for a retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes both parameters. The description adds minimal extra meaning (e.g., default for top_k), meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool grounds claims in EU regulation, returns top governing provisions with verbatim text and citations, distinguishing it from sibling compass_verify by focusing on retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call the tool ('BEFORE stating anything about EU...regulation') and provides a rule for handling no results ('do not assert an answer'), giving clear usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compass_verifyA

Check that a quote is a VERBATIM span of a specific EU provision (identified by the node_id returned by compass_retrieve). Use this before presenting a quotation as the words of the law, to guarantee you are not misquoting.

ParametersJSON Schema
NameRequiredDescriptionDefault
quoteYesThe exact text you intend to attribute to that provision.
node_idYesThe node_id of the provision, from a compass_retrieve result.

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It indicates the tool performs a verification check, but does not specify side effects, success/failure behavior, or authorization needs. A 3 is appropriate as it is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff. The critical information is front-loaded. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two simple string params and no output schema, the description covers the purpose and usage well. It is missing specifics about the output format (e.g., boolean or error), so it is not fully complete, but close.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces the usage context but adds no new semantic information beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if a quote is a verbatim span of an EU provision, using node_id from compass_retrieve. It distinguishes from the sibling compass_retrieve by focusing on verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this before presenting a quotation...' which provides clear guidance on when to invoke the tool. It also implies a prerequisite (retrieve node_id first).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.1
    • First observedcompass_retrieve
    • First observedcompass_verify
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one retrieves provisions, the other verifies quotes against a specific provision. There is no overlap in functionality.

Naming Consistency5/5

Both tools follow a consistent 'compass_verb' naming pattern using snake_case, providing clear and predictable tool names.

Tool Count3/5

With only 2 tools, the server feels thin for the broad domain of EU financial, crypto, and AI regulation. While focused, it may be insufficient for complex tasks.

Completeness3/5

The tools cover retrieving and verifying provisions, but lack search or listing capabilities, which are essential for navigating a large regulatory corpus. This is a notable gap.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • eu-regulations

    Ansvar-Systems
    A
    license
    A
    quality
    F
    maintenance
    Query 37 EU regulations — from GDPR and AI Act to DORA, MiFID II, eIDAS, Medical Device Regulation, and more — directly from Claude, Cursor, or any MCP-compatible client.
    14
    173
    25
    Apache 2.0
  • LexAPI MCP by Lex-API

    LexAPI MCPofficial

    Lex-API
    A
    license
    A
    quality
    B
    maintenance
    Enables querying EU legal documents, case law, and citation graphs through natural language using the LexAPI.
    10
    86
    3
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LicentiumIO/compass-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server