Allows performing Commodity Contract Compliance (CCC) compliance reviews, including audit, redlining, and risk assessment for commodity contracts.
MCP server for the Nexus Finance API v1 — connect Claude Desktop, Claude Code, Cursor or any MCP-compatible client to financial contract analysis, risk analytics, market quotes and compliance case management.
What is this? Connect your Claude to Nexus Finance in 30 seconds. From that point, Claude can invoke contract audits, VaR/CVaR calculations, Basel III RWA, live market quotes, OFAC screening and compliance case management without leaving the conversation.
Log in at app.nexusquantum.finance → Settings → API Keys → create a key. Copy the nf_... key — shown only once.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"nexus-finance": {
"command": "npx",
"args": ["-y", "@nexus-finance/mcp"],
"env": {
"NEXUS_FINANCE_API_KEY": "nf_YOUR_KEY_HERE"
}
}
}
}Restart Claude Desktop. You'll see a 🔌 icon in the chat with the 8 Nexus Finance tools available.
claude mcp add nexus-finance -- npx -y @nexus-finance/mcp
# Then set your key:
export NEXUS_FINANCE_API_KEY=nf_YOUR_KEY_HEREEdit ~/.cursor/mcp.json:
{
"mcpServers": {
"nexus-finance": {
"command": "npx",
"args": ["-y", "@nexus-finance/mcp"],
"env": {
"NEXUS_FINANCE_API_KEY": "nf_YOUR_KEY_HERE"
}
}
}
}In Claude Desktop, type:
Audit this contract with Nexus Finance and flag any high-risk clauses: «[paste contract text here]»
Claude will automatically call nexus_analyze and return a full risk assessment with severity-rated findings.
Related MCP server: bidda-mcp
Tool | Description | Typical cost |
| Contract audit, commodity briefing, playbook or CCC compliance review. Zero Retention. | 1–3 credits |
| Parametric VaR / CVaR at 90/95/99% confidence + 5-scenario stress test + VaR matrix | 1 credit |
| Basel III Standardized Approach RWA across all asset classes + capital adequacy check | 1 credit |
| Real-time equity, FX or commodity quote (Alpha Vantage, 15-min cache) | Free |
| Up to 10 quotes in one call | Free |
| List compliance cases (paginated, filterable by status) | Free |
| Full case detail with findings and counterparties | Free |
| Create a new compliance case | Free |
Variable | Required | Description |
| ✅ Yes | API key starting with |
| ❌ No | Override API base URL (default: |
Contract Intelligence — audit, redlining, AI drafting, obligation extraction, clause benchmark, RAG chat
Regulatory Compliance — EMIR/REMIT XML, CBAM, EUDR, CSDDD, MiFID II alerts, CCC v4.2
Risk Analytics — VaR/CVaR, RWA Basel III, stress tests, TBML watchdog, dynamic risk matrix
Counterparty Due Diligence — KYB/UBO graph (GLEIF + OpenCorporates), OFAC screening, vessel IMO screening
Case Management — 4-eyes workflow, multi-tenancy, audit export, rules engine
All analysis is Zero Retention — document text is never stored, logged or persisted.
🌐 Platform: nexusquantum.finance
📦 npm: @nexus-finance/mcp
🐍 Python SDK: nexus-finance-sdk
📚 TypeScript SDK: @nexus-finance/sdk
Run a financial analysis (audit, briefing, playbook, or commodity CCC). Returns full LLM output. Not persisted on server (Zero Retention).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Analysis type | |
| tier | Yes | Model tier | |
| params | Yes | Type-specific parameters. audit: {docText, profile, outputLang}. briefing: {commodity, region, timeWindow}. playbook: {counterpartyType, objective, constraints}. commodity: {role, commodity, instrumentType, amount} | |
| caseId | No | Optional case ID to link this analysis to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses critical behavioral traits: it returns full LLM output and is not persisted (Zero Retention). This is transparent, though additional details about auth or cost could enhance it.
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?
Two sentences, each adding value. The first sentence states the purpose, the second adds behavioral context. No wasted words.
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 and complex nested parameters, the description covers essential aspects: purpose, types, and ephemeral nature. It is sufficient for basic usage but could clarify output structure.
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 100%, so baseline is 3. The tool description mentions the analysis types which match the type enum, but does not add new meaning beyond the schema's parameter descriptions.
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 'Run a financial analysis' with a clear verb and resource. It lists four specific types (audit, briefing, playbook, commodity), distinguishing it from sibling tools that perform discrete tasks like market quotes or calculators.
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 implies usage for generating LLM-driven financial reports and notes zero retention, but does not explicitly state when to prefer this over siblings or provide exclusion criteria. It is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get up to 10 market quotes in a single request (equity, FX, commodity). Results cached 15 min.
| Name | Required | Description | Default |
|---|---|---|---|
| requests | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses important behavioral traits: result caching duration (15 min) and resource scope (equity, FX, commodity). It does not mention idempotency or rate limits, but for a read-only operation, the provided info is sufficient.
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?
Single sentence, front-loaded with the goal, no unnecessary words. Every phrase adds value.
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 agent lacks information about the response format. However, for a simple quote retrieval tool with caching info and clear input, the description is mostly complete. Minor gap: output format.
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 has no descriptions (0% coverage), but the description explains the 'requests' parameter as a means to get up to 10 quotes, clarifying the array's purpose. It does not detail symbol format or exact enum semantics, but the core meaning is conveyed.
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?
Description clearly states verb (Get), resource (market quotes), limits (up to 10), and types (equity, FX, commodity), distinguishing it from sibling 'nexus_market_quote' which likely provides single quotes.
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 implies batching via 'in a single request' but does not explicitly state when to use this tool versus calling the singular sibling tool repeatedly. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new compliance case.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Case title (max 200 chars) | |
| description | No | Optional description (max 2000 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks any behavioral details such as side effects, required permissions, idempotency, or what constitutes a valid case. With no annotations, the description carries full burden but only states the basic action.
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?
Single sentence with no superfluous information, but brevity sacrifices necessary context for a create tool. Efficient, but arguably under-specified.
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?
Does not explain what a compliance case is, post-creation behavior, uniqueness constraints, or any related context. For a creation tool with no output schema, more details are needed.
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 coverage is 100%, and the description adds no new meaning beyond the schema. Baseline 3 is appropriate, as the description does not enhance understanding of parameters.
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?
Specifies the action (create) and resource (compliance case), clearly distinguishing from retrieval tools like nexus_get_case and nexus_list_cases. However, it does not explicitly differentiate from sibling creation tools (none present), so it's clear but not exceptional.
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?
No guidance on when to use this tool versus alternatives, no prerequisites, constraints, or recommended usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full case detail including findings and counterparties (no LLM output — Zero Retention).
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | Case UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must provide behavioral transparency. It discloses that there is no LLM output and zero retention, which is relevant for data privacy. However, it does not discuss other behavioral aspects such as idempotency, authentication requirements, or error handling. This partial disclosure earns a 3.
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 extremely concise, using a single sentence with a clear verb and object, followed by a parenthetical behavioral note. Every part adds value.
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?
The tool has a single parameter and no output schema. The description clearly states the scope of returned data and a behavioral constraint (zero retention). For this level of complexity, the description is sufficiently complete. A minor gap is the lack of explicit idempotency guarantee, but that is implied.
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 input schema already describes the required parameter with a clear description. The tool description does not provide additional parameter semantics beyond what the schema offers. With 100% schema coverage, the baseline of 3 is appropriate.
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 uses the verb 'Get' and specifies the resource as 'full case detail including findings and counterparties'. This clearly distinguishes it from sibling tools like nexus_list_cases (list) and nexus_create_case (create). The additional note about zero retention adds clarity about data handling.
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 does not provide explicit usage guidelines or mention when to prefer this tool over siblings like nexus_list_cases or nexus_analyze. The purpose is clear but the context of use is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List compliance cases for the authenticated user. Supports pagination and status filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 20, max: 100) | |
| offset | No | Pagination offset (default: 0) | |
| status | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover safety and behavior. It mentions authentication and filtering but omits requirements (e.g., permissions), whether it returns only user's cases, or rate limits. The behavioral disclosure is insufficient.
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 single sentence that conveys key information without waste. It is appropriately sized and front-loaded with purpose.
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 and no annotations, the description lacks context about return format, ordering, error handling, or pagination details. For a list operation, more completeness is needed.
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 coverage is 100%, so baseline is 3. The description's 'Supports pagination and status filter' paraphrases schema descriptions without adding new meaning. No additional semantic value beyond schema.
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 verb 'List', the resource 'compliance cases', and the user scope 'for the authenticated user'. It also mentions key features like pagination and status filter, distinguishing it from sibling tools like nexus_get_case.
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 implies usage for listing cases but does not explicitly state when to use this tool versus alternatives like nexus_get_case for single case retrieval or nexus_create_case for creation. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a real-time market quote for an equity, FX pair, or commodity (powered by Alpha Vantage). Results cached 15 min.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker or symbol. Equity: 'AAPL'. FX: 'EUR/USD'. Commodity: 'WTI', 'BRENT', 'GOLD', 'NATGAS' | |
| type | No | Quote type (default: equity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses caching behavior (15 min) and data source (Alpha Vantage), which provides useful context. However, without annotations, it lacks details on authentication, rate limits, or side effects for a read-only operation.
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?
Extremely concise with two sentences. The first sentence clearly states the action, and the second adds relevant behavioral info. No unnecessary words.
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?
Missing output details. The description says 'market quote' but does not specify return fields (price, volume, time, etc.). With no output schema, the description should provide at least an overview of results, which it does not.
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 coverage is 100% with descriptions for both parameters. The description's mention of asset types adds context but does not significantly augment the schema. Baseline score of 3 is appropriate.
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?
Description clearly states the tool retrieves a real-time market quote for equities, FX pairs, or commodities, which is specific and aligns with the tool name. It does not explicitly differentiate from sibling 'nexus_bulk_quotes', but the scope is clear.
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?
No guidance on when to use this tool versus alternatives like nexus_bulk_quotes or nexus_analyze. The description does not mention prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute portfolio Risk-Weighted Assets (RWA) using Basel III Standardized Approach. Returns total RWA and capital requirement (8% + buffers = 10.5%).
| Name | Required | Description | Default |
|---|---|---|---|
| assets | Yes | Array of assets with exposure and Basel III asset class | |
| availableCapital | No | Available capital to check adequacy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Clearly states it computes and returns RWA and capital requirement with specific percentages. No mention of side effects or permissions, but as a stateless calculator, behavioral expectations are adequately set.
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?
Two sentences, 15 words, no fluff. Front-loaded with purpose and output. Every phrase adds value.
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 nested input and no output schema, description provides useful context on what is returned (total RWA and capital requirement) and the regulatory framework (Basel III, 10.5%). Slightly lacking in output structure detail, but adequate for a calculator.
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 coverage is 100% with field descriptions. Description does not add extra meaning beyond the schema. Baseline score of 3 appropriate as description relies on schema for parameter details.
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?
Description clearly states it computes portfolio RWA using Basel III Standardized Approach and specifies output (total RWA and capital requirement). Distinct from sibling tools which cover analysis, market data, cases, and VaR.
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?
No explicit when-to-use or alternatives guidance. Implicitly clear for RWA tasks given sibling tool names, but lacks explicit instruction on when not to use or which sibling handles related computations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute parametric Value-at-Risk (VaR), Conditional VaR (CVaR), and optional stress test scenarios for a portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolioValue | Yes | Total portfolio value in the given currency | |
| annualVolatility | Yes | Annual volatility as decimal (e.g. 0.18 for 18%) | |
| holdingPeriodDays | No | Holding period in days (default: 10) | |
| confidenceLevel | No | Confidence level (default: 0.95) | |
| currency | No | Currency code (default: USD) | |
| includeStress | No | Include 5-scenario stress test (default: true) | |
| includeMatrix | No | Include VaR sensitivity matrix (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must reveal behavioral details. It mentions 'parametric' (implying normal distribution) and 'optional stress test scenarios' but does not specify assumptions, limitations (e.g., linear portfolio), or whether the tool is read-only. No contradictions with annotations (none exist).
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 single sentence, concise and front-loaded with key outputs (VaR, CVaR, stress tests). No waste, but minimal structure; it could benefit from breaking out optional features.
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 7 parameters and no output schema, the description explains the core computation but lacks details on return format, units, or handling of edge cases. It adequately covers purpose but leaves gaps for an agent to infer behavior.
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 coverage is 100%, so each parameter has a description. The tool description adds no extra meaning beyond the schema, e.g., it does not explain how 'confidenceLevel' relates to VaR quantiles. Baseline 3 is appropriate given the schema's completeness.
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 computes parametric Value-at-Risk (VaR), Conditional VaR (CVaR), and optional stress test scenarios, using a specific verb ('Compute') and resource identification. It distinguishes from sibling tools like nexus_rwa_calculator (credit risk) and nexus_analyze (generic analysis) by specifying financial risk metrics.
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 no guidance on when to use this tool versus alternatives, such as prerequisites (e.g., need normal distribution assumption) or contrasting with nexus_rwa_calculator for credit risk. It does not mention required input formats or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1nexus_analyzenexus_bulk_quotesnexus_create_casenexus_get_casenexus_list_casesnexus_market_quotenexus_rwa_calculatornexus_var_calculatorScored across 8 tools
Each tool has a clearly distinct purpose: market quotes (individual vs bulk), compliance case management (CRUD but missing update/delete), financial analysis, and risk calculators. No overlap in functionality.
Tool names follow 'nexus_' prefix but mix patterns: verbs (analyze), adjective_noun (bulk_quotes, market_quote), noun_noun (rwa_calculator, var_calculator), and verb_noun (create_case, get_case, list_cases). Inconsistent structure makes prediction harder.
8 tools is appropriate for a finance server covering market data, compliance, analysis, and risk calculation. Not too few or too many for the domain.
Core areas are covered (quotes, compliance, risk, analysis) but compliance lacks update and delete operations, and there is no historical data or portfolio aggregation tools. Minor gaps exist.
AI legal compliance: contract review, risk scoring, EU/CN AI act, watermark check. 8 MCP tools.
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
10,065 source-verified compliance nodes, 39 pillars, 25 MCP tools (EU AI Act, GDPR, NIST, MITRE).
RiskOracle - 13-tool enterprise risk MCP: heatmaps, KRIs, scenario sims, Basel/ICAAP outputs.