This server connects Claude and other MCP clients to the Nexus Legal API, exposing 27 legal AI tools for analysis, drafting, verification, simulation, and research.
Analyze contracts/legal documents (nexus_analyze) with ISO 31000 risk assessment, certainty locks, blocking signals, and audit trails.
Ask open legal questions (nexus_consulta) with or without a document.
Draft pleadings, appeals, claims, and clauses (nexus_draft).
Cross-audit prior analyses (nexus_audit, nexus_opinion, nexus_adversarial, nexus_redteam) for adversarial validation and second opinions.
Run Monte Carlo litigation/contract stress simulations (nexus_monte_carlo).
Search case law and legislation semantically (nexus_jurisprudencia_search, nexus_normativa_search, nexus_doctrina).
Verify citations and check every citation in a document (verify_cita, nexus_verificacion).
Compute procedural time limits (plazos_calcular) for ES and GB-EAW forums.
Explore statute↔case-law citation graphs (cruce_normativa_jurisprudencia).
Compare legal treatment across 2–15 jurisdictions (nexus_cross_border_compare).
Analyze Box files by file ID (box_analyze).
Check conflicts of interest, compare document versions, and inspect attention inbox (nexus_conflict_check, nexus_compare_versions, nexus_inbox).
Check corpus coverage and availability (nexus_corpus_coverage, nexus_normativa_coverage).
MCP (Model Context Protocol) server for Nexus Legal — exposes 27 specialised legal capabilities to Claude Desktop, Claude Code, Cursor and any other MCP-compatible client.
What is this? Connect your Claude to Nexus in 30 seconds. From then on Claude can run ISO 31000 legal analysis, Monte Carlo litigation simulation, case-law search, legal drafting, administrative doctrine, adversarial red teaming, multi-jurisdiction comparison (cross-border), citation verification, procedural time-limit computation, the statute↔case-law citation graph, and analysis of Box files by
file_id(box_analyze) — without leaving the conversation.
Go to legal.nexusquantum.legal/developers, choose "MCP server", give it a name (e.g. "personal MacBook") and press + Create MCP key. Copy the nlk_... key — it is shown only once.
Edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"nexus-legal": {
"command": "npx",
"args": ["-y", "@nexus-legal/mcp"],
"env": {
"NEXUS_API_KEY": "nlk_YOUR_KEY_HERE"
}
}
}
}Restart Claude Desktop. You will see a 🔌 icon in the chat with the 27 Nexus tools available.
Edit %APPDATA%\Claude\claude_desktop_config.json with the same contents.
claude mcp add nexus-legal -- npx -y @nexus-legal/mcp
# Then set your key:
export NEXUS_API_KEY=nlk_YOUR_KEY_HEREEdit ~/.cursor/mcp.json:
{
"mcpServers": {
"nexus-legal": {
"command": "npx",
"args": ["-y", "@nexus-legal/mcp"],
"env": { "NEXUS_API_KEY": "nlk_YOUR_KEY_HERE" }
}
}
}In Claude Desktop, type:
Analyse this contract with Nexus in jurisdiction GB, commercial branch, conservative profile: «[paste the contract text here]»
Claude will call the nexus_analyze tool and return the report with certainty locks [L1]/[L2-J]/[L3-NV]/[L4], blocking signals [L5-C]/[L5-P], and a NEXUS-AUDIT-TRAIL block.
Related MCP server: jurisprudenciaia-mcp
Tool | Capability | Typical cost |
| Full legal analysis (Node A — ISO 31000) | 1-3 credits |
| Open legal question, with or without a document | 1 credit |
| Legal drafting (appeal, claim, defence, clause…) | 2-4 credits |
| Cross-audit of a Node A analysis (Node B) | 1-2 credits |
| Multi-agent consensus Node A ↔ Node B (analysis + adversarial audit in a loop until consensus; | 3-7 credits |
| Monte Carlo scenario simulation (ISO 31000 §6) | 4 credits |
| Administrative doctrine search, by jurisdiction | 1 credit |
| Multi-LLM second opinion on a previous analysis | 2 credits |
| Adversarial red team (vulnerabilities as structured JSON) | 5 credits |
| Adversarial argument in prose over a previous analysis | 2-3 credits |
| Multi-jurisdiction comparison (2-15 jurisdictions) | 2-4 credits |
| Semantic search over the multi-jurisdiction case-law corpus | requires balance + the case-law add-on for that jurisdiction |
| Deterministic verification of one citation (judgment or provision) against the official corpus | requires balance (+ case-law add-on if the citation is case law) |
| Procedural time limits by forum. | requires balance |
| Citation graph: provisions ↔ judgments | requires balance + case-law add-on |
| Analysis of a Box file by | 1-2 credits |
| Verification Centre: checks EVERY citation in a document against the official corpus (deterministic, no LLM cost) | requires balance |
| Strategic negotiation playbook over a previous analysis | 2-3 credits |
| Comparison of two versions of a document (V1 ↔ V2) | 2 credits |
| Conflict check (conflicts of interest) over the parties to a case file | 1 credit |
| Firm-wide attention inbox (what needs action) | requires balance |
| Legal chat with the case context | 1 credit |
| Semantic search over legislation in force | requires balance + the legislation add-on for that jurisdiction |
| Literal text of a provision at a date (lex temporis) | requires balance + legislation add-on |
| Legislative hierarchy: coverage by level | requires balance |
| Inventory of the case-law corpus | read-only |
| Legislation corpus coverage (jurisdictions + freshness) | read-only |
Billing: the MCP server is not free. Every call requires an account with a credit balance > 0 (paid from minute one). Premium content is per jurisdiction add-on: case law and extra legislation are add-ons (Layer 3) — the subscription includes the legislation of one jurisdiction. Without the matching add-on, searches and lookups for that jurisdiction return
403 CONTENT_NOT_ENTITLED.
On jurisdictions and coverage. 63 jurisdiction codes are selectable (GB, ES, CO, SG, US with the US-CA/US-NY/US-DE/US-TX state overlays, MULTI for cross-border, and others). Selectable is not the same as grounded: what corpus actually backs a given jurisdiction — how many provisions, when our copy was last written, whether search is enabled for it — varies, and it is not something to infer from this list. Call nexus_normativa_coverage with your key: it answers for the jurisdictions your account has active, with the figures of each. A jurisdiction with no grounding corpus still analyses, but without literal citation against an official source.
Some accounts are provisioned so that legal generation runs only on the firm's own LLM engine, with no fallback chain. That is not a limitation: it is the guarantee that documents never reach a Nexus engine.
While no provider is registered and enabled, every generative tool
(nexus_analyze, nexus_consulta, nexus_chat, nexus_draft, nexus_audit,
nexus_adversarial, nexus_redteam, nexus_doctrina, nexus_consensus,
nexus_monte_carlo, nexus_opinion, nexus_playbook, nexus_compare_versions,
nexus_cross_border_compare, box_analyze) returns:
Error running nexus_analyze: BYO_PROVIDER_REQUIRED: This account requires its own
BYO LLM engine for AI-generative endpoints … This is a configuration state, not a
transient failure — retrying returns the same 409. Register and enable a provider
via POST /api/v1/llm-providers, then retry.Retrying does not fix it, and no credits are charged for a run that stops there.
Register the engine once (POST /api/v1/llm-providers, or header → AI models in
the application) and run it again.
If your engine is a reasoning model (DeepSeek V-pro, o1-style, Claude 5 with thinking), a heavy analysis can take longer than a synchronous HTTP request is allowed to last. The gateway closes the connection at 300 s — that ceiling is ours to live with, not to raise.
MEASURED on 2026-08-18: nexus_analyze in mode: "auditoria" over a ~5 KB contract, on a BYO
DeepSeek engine, went past it and returned 502. The reason is not a fault in your engine: a
reasoning model spends a large part of its completion budget thinking before it writes, and when
it runs out mid-thought Nexus automatically re-issues the call with a wider budget — which costs
more wall clock again.
Two ways round it, in order of preference:
Use the asynchronous path for that combination: POST /api/v1/jobs with
kind: "analyze" returns 202 and a jobId you poll (or a signed webhook). No wall clock.
This is the right door for reasoning engines and for auditoria on large documents.
Use mode: "standard" through the MCP tool, which is materially shorter.
Platform engines and mode: "standard" are unaffected: the synchronous tool is the right one
there and stays the default.
Read-only tools work without an engine, because they generate nothing:
nexus_jurisprudencia_search, verify_cita, nexus_verificacion,
nexus_normativa_search / _articulo / _pyramid, nexus_corpus_coverage,
nexus_normativa_coverage, cruce_normativa_jurisprudencia, plazos_calcular,
nexus_conflict_check (deterministic name matching, no LLM) and nexus_inbox.
Variable | Default | Description |
| — | Required. An |
|
| For test or self-hosted environments. |
|
| Timeout for long analyses. |
Language. This package sends the same tool descriptions to every client — MCP
publishes them once, in tools/list, and no tool here takes a language argument —
so descriptions and rendered output are in English. Where a tool produces a legal
deliverable, the language of that deliverable follows the jurisdiction and the account,
not this README.
You can name the role and the party in your own terms. professionalRole takes
lawyer, solicitor, barrister, prosecutor, notary, registrar, judge,
in-house and individual. proceduralSide takes the term your forum actually uses:
claimant (England and Wales, CPR r 2.3), pursuer (Scotland), plaintiff (Northern
Ireland, which did not adopt the CPR), defendant, defender. The original Spanish wire
values — abogado, demandante, auditoria — are unchanged and will keep working: this
adds spellings, it does not retire any. Everything resolves to the same protocol value
before it reaches the analysis, so the two are interchangeable in every call.
API version: this server speaks to the Nexus v1 API, the same one used by the
TypeScript and
Python SDKs. Read-only and verification tools
call /api/v1/* routes; generative ones enter through the backend node routes with the
same nlk_ key (mcp scope), the same billing and the same BYO enforcement.
This stdio package exposes 27 of the catalogue's capabilities. The remote
connector (https://legal.nexusquantum.legal/api/mcp, nothing to install) also
exposes the case-file, firm-memory, firm-governance, legal-analytics, account and billing
capabilities. If you need any of those, use the remote connector or the v1 API directly.
Zero Retention on EU infrastructure. Documents you send via MCP are processed in RAM on Railway europe-west4-drams3a (Netherlands) and are NOT persisted to a database by default. The Nexus Zero Retention policy applies to 100% of MCP traffic exactly as it does to web traffic.
PII Gatekeeper. Before anything reaches the LLM, the backend anonymises national ID numbers, IBANs, phone numbers, emails and account numbers with reversible tokens ([DNI_1], [ACCOUNT_3]…). The MCP client only ever sees output already re-identified by our pipeline.
Audit. Every tool call is recorded in analysis_costs and api_usage_stats (with via_api_key_id) for billing and traceability.
Email: support@nexusquantum.legal
Documentation: https://legal.nexusquantum.legal/developers
Issues: https://github.com/djtellado/nexus-legal-prod/issues
Apache-2.0 — see LICENSE and NOTICE.
Copyright 2026 Nexus Legal · Quantum Nexus Ventures.
ARGUMENTACIÓN ADVERSARIAL (Nodo C — modo contraparte). Para cada conclusión del análisis Nodo A, construye el argumento más fuerte que esgrimiría la contraparte. Útil para preparar litigio o anticipar objeciones en negociación. Distinto de nexus_redteam: adversarial DEBATE las conclusiones (texto en prosa), redteam DESTRUYE cláusulas (JSON estructurado). USAR CUANDO: el cliente necesita anticipar objeciones de la otra parte. Coste: 2-3 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texto del documento original. | |
| analysis | No | Análisis Nodo A previo sobre el mismo documento. Si se aporta, el adversarial argumenta CONTRA cada conclusión. | |
| jurisdiction | No | ES | |
| legalBranch | No | civil | |
| professionalRole | No | abogado | |
| language | No | es |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions a credit cost (2-3 credits) which hints at resource usage but does not disclose whether the tool is read-only, whether it modifies any state, or what authentication is required. The generative nature suggests no side effects, but this is not made explicit.
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 concise (3-4 sentences) with no redundancy. It front-loads the core purpose, provides a sibling distinction, a usage guideline, and ends with cost. Every sentence 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 description covers purpose, usage, sibling distinction, and cost. However, it lacks details about the output format (prose text is implied but not explicit). Since there is no output schema, the description should more clearly describe what the agent can expect as a result.
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 33% (only `text` and `analysis` have descriptions). The description adds context for `analysis` (causes argumentation against each conclusion). For other parameters (`jurisdiction`, `legalBranch`, `professionalRole`, `language`), no additional meaning beyond enum/defaults is provided. The description does not fully compensate for the low schema 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 identifies the tool's purpose: adversarial argumentation (Nodo C — modo contraparte). It specifies it constructs the strongest counter-arguments against conclusions from Nodo A. It also distinguishes from sibling `nexus_redteam` by contrasting their outputs (prose vs. structured JSON).
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 explicitly states when to use the tool: prepare litigation or anticipate objections in negotiations. It provides a direct WHEN-TO-USE clause: 'USAR CUANDO: el cliente necesita anticipar objeciones de la otra parte.' It also differentiates from `nexus_redteam` clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ANÁLISIS PRIMARIO JURÍDICO (Nodo A — ISO 31000). Examina un documento íntegramente: extrae partes, riesgos, cláusulas, plazos, normas aplicables y jurisprudencia relevante. Aplica la jurisdicción (ES/CO/MX/etc.) y rama del derecho correspondiente. Devuelve informe estructurado con candados de certeza [L1]/[L2-J]/[L3-NV]/[L4] y señales bloqueantes [L5-C]/[L5-P]. Termina con bloque NEXUS-AUDIT-TRAIL para auditoría posterior. Coste: ~1-3 créditos según tamaño + tier de modelo. USAR CUANDO: el usuario aporta un documento jurídico y pide análisis de riesgos, viabilidad, cláusulas críticas, o defensa en juicio.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texto íntegro del documento jurídico a analizar (contrato, demanda, sentencia, providencia administrativa, etc.). Mínimo 20 caracteres. | |
| jurisdiction | No | Código ISO de la jurisdicción primaria. Soporta US-CA/US-NY/... para state overlay y MULTI para análisis multi-país. Default: ES. | ES |
| jurisdictionB | No | Segunda jurisdicción para análisis cross-border / bilateral. Activa MODULE-BILATERAL + framework de tratados aplicables. | |
| legalBranch | No | Rama jurídica predominante del documento. | civil |
| mode | No | standard: análisis equilibrado · auditoria: máxima exhaustividad, crítica adversarial · agil: respuesta breve enfocada en lo crítico. | standard |
| professionalRole | No | Rol profesional desde el que se mira el documento. Cambia la perspectiva del informe. | abogado |
| proceduralSide | No | Posición procesal del cliente. demandante (acreedor/actor) o demandado (defensor/deudor). | |
| negotiationProfile | No | conservador: maximiza alertas y protección · equilibrado: balance · agresivo: filtra alertas no bloqueantes. | equilibrado |
| language | No | Idioma del informe de salida. | es |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It details the analysis process (extraction, jurisdiction application, certainty locks, blocking signals), mentions cost (~1-3 credits), and describes output structure. Lacks explicit statement about non-destructive nature, but overall provides substantial behavioral context.
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?
Description is well-structured: title, summary, output specifics, cost, and usage guidance. Front-loaded with purpose. Some verbosity in Spanish, but every sentence serves a purpose. Could be slightly more concise.
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 complexity (9 params, 1 required, no output schema), description covers purpose, usage, behavioral details, and output format. Includes cost and audit trail. Does not detail error handling or limitations, but is sufficient for an AI agent to select and invoke correctly.
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 all 9 parameters. Description adds context beyond schema, e.g., that 'jurisdictionB' activates MODULE-BILATERAL, and explains how 'mode' and 'professionalRole' affect analysis. This adds meaning for effective parameter use.
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 starts with 'ANÁLISIS PRIMARIO JURÍDICO (Nodo A — ISO 31000)' and explicitly states it examines documents to extract parts, risks, clauses, deadlines, applicable norms, and relevant jurisprudence. It provides a clear verb and resource, and distinguishes from siblings by positioning itself as the primary legal analysis tool ('Nodo A').
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?
Includes explicit usage guidance: 'USAR CUANDO: el usuario aporta un documento jurídico y pide análisis de riesgos, viabilidad, cláusulas críticas, o defensa en juicio.' While it does not specify when not to use or list alternatives, the context from sibling tool names (e.g., nexus_adversarial, nexus_audit) implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AUDITORÍA CRUZADA DEL ANÁLISIS NODO A (Nodo B — control adversarial). Verifica el análisis previo contra el documento original: detecta afirmaciones no soportadas, candados mal asignados, omisiones, contradicciones internas, y genera el bloque de verificaciones V-XX. Devuelve confidence score 0-100. USAR CUANDO: el usuario quiere una segunda capa de validación antes de presentar el análisis a un cliente o tribunal. Requiere haber ejecutado nexus_analyze primero. Coste: 1-2 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | Yes | Análisis Nodo A íntegro a auditar (texto completo del informe Nodo A, incluyendo NEXUS-AUDIT-TRAIL si lo lleva). | |
| text | Yes | Documento original del análisis (Capa A). Necesario para que el auditor pueda contrastar afirmaciones contra el corpus. | |
| jurisdiction | No | ES | |
| jurisdictionB | No | ||
| language | No | es | |
| articleContext | No | Contexto de artículos relevantes inyectados por el operador (opcional). | |
| jurisprudenciaContext | No | Contexto de jurisprudencia relevante (opcional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the tool performs an audit that generates a verification block and confidence score, mentions cost (1-2 credits), and describes the adversarial nature (Nodo B). However, it does not clarify if the tool is read-only or modifies any data, nor does it detail authentication or rate limits. The basic behavioral context is present but incomplete.
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 dense paragraph that front-loads the main purpose and then provides usage conditions and output details. It is efficient with no wasted words, though structuring with bullet points could improve scanability. For the amount of information conveyed, it is appropriately concise.
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 (2 required), no output schema, and no annotations, the description covers the tool's purpose, prerequisite, output (confidence score and V-XX block), and cost. It lacks details on the exact format of the verification block output, which would help the agent process results. While adequate for basic decision-making, it leaves some gaps in expected 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 57% (4 of 7 parameters have descriptions). The tool description adds context that the 'analysis' parameter should come from `nexus_analyze`, which is valuable beyond the schema. However, parameters like 'jurisdiction' and 'jurisdictionB' lack descriptions in both schema and description, leaving their purpose ambiguous. The description does not fully compensate for the missing schema 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 clearly states the tool performs a cross-audit of a previous analysis (Nodo A) using adversarial control (Nodo B), specifying it detects unsupported claims, misassigned locks, omissions, and contradictions, and generates a verification block with a confidence score. This distinguishes it from siblings like nexus_analyze (initial analysis) and nexus_adversarial (likely separate adversarial function).
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 explicit usage guidance: 'USE WHEN: user wants a second validation layer before presenting to client or court' and states the prerequisite of having run `nexus_analyze` first. It implies when not to use (if previous analysis not performed) but does not explicitly compare against sibling alternatives like nexus_adversarial or nexus_redteam, which could also be used for validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CONSULTA JURÍDICA LIBRE (Nodo A — modo Q&A). Pregunta jurídica en lenguaje natural, con o sin documento de referencia. Devuelve respuesta con candados de certeza y referencias normativas/jurisprudenciales cuando aplican. Soporta hilos conversacionales mediante el parámetro history. Coste: 1 crédito. USAR CUANDO: el usuario hace una pregunta jurídica concreta (¿cuál es el plazo de prescripción?, ¿es válida esta cláusula?, ¿qué dice el TS sobre X?) y NO necesita análisis íntegro de un documento.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Pregunta jurídica concreta del operador. Puede ir respaldada por un documento de contexto (`documentText`) o por un análisis previo (`analysisContext`). | |
| jurisdiction | No | Código ISO de la jurisdicción que rige la consulta. Soporta US-CA/US-NY etc. y MULTI. | ES |
| documentText | No | Texto del documento de referencia (opcional). Si se aporta, el modelo lo trata como Capa A y cita literalmente. | |
| analysisContext | No | Análisis Nodo A previo sobre el documento (opcional). Si se aporta, sirve como contexto para razonar sobre el caso. | |
| language | No | es | |
| history | No | Historial conversacional opcional. Permite múltiples turnos sobre el mismo caso. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions returning certainty locks and references, supporting conversational history, and cost. But lacks details on rate limits, auth, or edge cases. Decent but not comprehensive.
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?
Description is a single paragraph that front-loads purpose but includes some redundancy (e.g., 'con o sin documento de referencia' and subsequent param mentions). Could be more concise.
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 6 parameters, no output schema, and no annotations, description covers usage context and basic behavior but omits return format, error handling, and limitations. Adequate but incomplete.
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 83%, so baseline is 3. Description adds minor context for the history parameter but otherwise doesn't extend 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 defines the tool as a free legal Q&A (Nodo A) answering concrete legal questions in natural language, with examples. It distinguishes from siblings by specifying when NOT to use (full document analysis).
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 condition (concrete legal question, no full document analysis) and mentions cost (1 crédito). However, it doesn't explicitly name sibling tools that should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
COMPARATIVA MULTI-JURISDICCIONAL. Para los hechos/contrato aportados, compara cómo lo trata el ordenamiento jurídico de cada jurisdicción listada (2-15 países). Identifica: ley aplicable más favorable, foro competente óptimo, riesgos fiscales por país (CDI), reconocimiento de sentencias entre jurisdicciones, conflictos de leyes. Devuelve JSON con tabla comparativa estructurada. USAR CUANDO: el cliente opera en varios países y necesita decidir dónde litigar/contratar/establecerse. Coste: 2-4 créditos según número de jurisdicciones.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texto del documento (contrato, situación jurídica, hechos). | |
| jurisdictions | Yes | Códigos ISO de 2 a 15 jurisdicciones a comparar (ej. ['ES','CO','MX','AR']). | |
| legalBranch | No | civil | |
| language | No | es |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output format (JSON with structured table), key identified elements, and cost (2-4 credits). It does not mention side effects or auth needs, but as an analysis tool this 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?
The description is a single paragraph with all key information front-loaded. Each sentence adds value: purpose, items identified, output format, usage scenario, cost. No redundant or filler content.
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 4 parameters, no output schema, and no annotations, the description covers the tool's purpose, input, output format, and usage context well. It could explicitly mention the default legalBranch and language values, but the schema covers those. The description is largely complete for an agent to understand invocation.
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 50% (text and jurisdictions have descriptions). The description adds context for text ('hechos/contrato') and jurisdictions ('2-15 países'), but does not mention legalBranch or language, leaving their purpose inferred from the schema. Baseline 3 is appropriate as the schema already covers half the 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?
The description clearly states it performs a multi-jurisdictional comparison of legal treatment, listing specific aspects (applicable law, forum, tax risks, etc.). It differentiates itself from siblings like nexus_analyze (single-jurisdiction) by explicitly focusing on cross-border scenarios.
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 includes 'USAR CUANDO' with a clear scenario (client operates in multiple countries). It implies when not to use (single jurisdiction) but does not explicitly name alternative tools. The guidance is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BÚSQUEDA DE DOCTRINA ADMINISTRATIVA (Nodo Doctrina — RAG + LLM). Consulta el corpus de doctrina admin/tributaria (DGT consultas vinculantes V-XXXX-YY, TEAC RG XXXX/XXXX, Consejo de Estado dictámenes). Distingue 'Doctrina consolidada' (≥2 fuentes ORIGEN-A/B) vs 'Criterio orientativo' ([L3-NV]). Indica vinculatoriedad y conflictos con jurisprudencia TS. USAR CUANDO: el usuario pregunta por el criterio administrativo en un tema fiscal/regulatorio concreto. Coste: 1 crédito.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Consulta doctrinal en lenguaje natural. Ej: '¿La DGT considera deducibles los gastos de representación de un administrador único?' | |
| jurisdiction | No | Jurisdicción para acotar el corpus doctrinal (DGT/TEAC español, Consejo de Estado, etc.). | ES |
| language | No | es | |
| history | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: it differentiates between 'Doctrina consolidada' (≥2 sources) and 'Criterio orientativo', indicates binding nature and conflicts with Supreme Court jurisprudence, and mentions cost. It does not cover rate limits or authentication, but for a search tool these are less critical.
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 dense paragraph but front-loads the core purpose. Every sentence provides useful information (corpus, distinctions, usage, cost). It is concise with no redundancy, though it could benefit from bullet points for readability.
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?
With 4 parameters (1 required) and no output schema, the description adequately explains the search scope and output features (distinguishes doctrinal types, indicates binding). It does not specify the return format (text, citations, etc.), which might leave an agent guessing. Given the complexity of doctrinal search, a bit more detail on output structure would improve completeness.
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 50%, and the description adds some value for the query parameter (example in natural language) but does not elaborate on jurisdiction, language, or history beyond what the schema already provides. The description's example helps clarify usage, but it does not compensate fully for the missing schema 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 clearly states the tool's purpose: 'BÚSQUEDA DE DOCTRINA ADMINISTRATIVA' (search of administrative doctrine). It specifies the resource (corpus de doctrina admin/tributaria including DGT, TEAC, Consejo de Estado) and distinguishes it from sibling tools like nexus_jurisprudencia_search which focuses on court rulings. The use of 'RAG + LLM' and examples of queries further clarifies its scope.
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 explicitly says 'USAR CUANDO: el usuario pregunta por el criterio administrativo en un tema fiscal/regulatorio concreto', providing clear context for when to use. It also mentions cost (1 crédito) and distinguishes between doctrinal types. However, it does not explicitly state when not to use or name alternative tools, though sibling tool names imply alternatives for legal search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
REDACCIÓN DE ESCRITO JURÍDICO (Nodo A — Modo Redactor). Genera el primer borrador de un escrito (recurso, demanda, contestación, cláusula contractual, dictamen) siguiendo el formato y candados obligatorios de MODULE-DRAFT. Si la fecha de notificación es incierta, se degrada a [L3-NV] y se pide verificación en el brief. USAR CUANDO: el usuario pide redactar un escrito concreto, normalmente tras un análisis Nodo A previo o sobre un documento aportado. Coste: 2-4 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| instructions | Yes | Instrucción al redactor sobre qué escrito generar (ej. 'Redacta recurso de reposición contra providencia de apremio AEAT clave A28...'). Puede ser un solo turno o un hilo si usas `messages`. | |
| jurisdiction | No | Jurisdicción aplicable al escrito. | ES |
| legalBranch | No | civil | |
| documentContext | No | Texto del documento de partida (ej. el contrato que se va a impugnar, la providencia recurrida). Capa A. | |
| language | No | es | |
| professionalRole | No | abogado | |
| negotiationProfile | No | equilibrado | |
| messages | No | Hilo conversacional previo. Si no se aporta, se construye con `instructions` como único turno user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the transparency burden. It discloses that output follows 'formato y candados obligatorios de MODULE-DRAFT' and degrades to L3-NV if notification date is uncertain. This is good but could specify more about side effects or authentication needs.
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 focused paragraph in Spanish, conveying purpose, behavior, and usage context without redundancy. It could be more structured (e.g., bullet points) but is efficient.
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?
With 8 parameters, no output schema, and no annotations, the description should cover return format and error handling. It mentions cost and degradation but not what the tool returns (presumably generated text). This gap reduces completeness.
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 50%, meaning half of parameters lack descriptions. The description does not elaborate on parameter meanings beyond what the schema provides. It briefly mentions 'instructions' but doesn't compensate for under-documented 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?
The description clearly states it generates a first draft of a legal document (recurso, demanda, etc.) following mandatory format. It specifies the resource (legal brief) and action (drafting), and distinguishes from sibling tools that are analytical or search-based.
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 explicitly says 'USAR CUANDO: el usuario pide redactar un escrito concreto' (use when user requests a specific document). It also notes typical context (after analysis) and degradation behavior. However, it lacks explicit contraindications or when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BÚSQUEDA SEMÁNTICA DE JURISPRUDENCIA. Consulta vectorial (voyage-law-2) sobre el corpus curado de Nexus: ES ~141k sentencias (CENDOJ — TS/AN/TSJ/AP) · CO ~106k (CC/CSJ/CE) · más países en expansión. Devuelve top-K resultados con título, fuente, extracto (2 000 chars) y URL permanente al texto íntegro. USAR CUANDO: el usuario pide localizar sentencias sobre un tema concreto, contrastar un argumento, o construir un dossier de citas. Coste: gratis (solo búsqueda).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Consulta en lenguaje natural sobre jurisprudencia. Ej: 'cláusula suelo abusiva entidad bancaria devolución intereses' o 'recurso de amparo contra providencia administrativa apremio'. | |
| jurisdiction | No | Jurisdicción del corpus. ES = CENDOJ (TS/AN/TSJ/AP ~141k docs). CO = CC/CSJ/CE (~106k). Otros países según disponibilidad. | ES |
| top_k | No | Número máximo de sentencias a devolver. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses use of vector model (voyage-law-2), character limit for excerpt (2000 chars), and that it returns permanent URLs. No annotations provided, so description carries full burden; for a read-only search, this is adequate. No contradictions.
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?
Description is information-dense but could be slightly more concise. However, every sentence adds value: purpose, technology, jurisdictions, return format, usage guidance, cost. Front-loaded with purpose in Spanish, making it scannable.
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?
Despite no output schema, the description explains return fields (title, source, excerpt, URL). It covers corpus sizes (ES ~141k, CO ~106k), expansion plans, and cost. For a search tool with three parameters, this is comprehensive.
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?
Input schema has 100% coverage with detailed descriptions for all three parameters (query, jurisdiction, top_k). The description adds context on corpus sizes and example queries, adding value beyond the schema. Baseline 3 is exceeded due to helpful examples.
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 it is a semantic search for jurisprudence using vector query. It specifies the source (Nexus corpus, CENDOJ, TS/AN/TSJ/AP, etc.) and exactly what is returned (top-K results with title, source, excerpt, URL). This distinguishes it from sibling tools even without seeing their descriptions.
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?
Explicit 'USAR CUANDO' section provides clear use cases: locating sentences on a topic, contrasting an argument, or building a citation dossier. It also mentions the cost is free. No explicit when-not or alternatives, but the use cases are sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SIMULACIÓN MONTE CARLO DE ESCENARIOS (Nodo Monte Carlo — ISO 31000 §6). Estresa el perfil de riesgo de un contrato bajo variables definidas por el usuario. Por cada variable, simula tres intensidades (Moderada P25 / Base P50 / Severa P75), recalifica los riesgos del análisis Nodo A y calcula un Índice de Resiliencia Contractual (IRC 0-100). Devuelve tablas de impacto + recomendaciones de blindaje. USAR CUANDO: el cliente quiere saber cómo aguanta el contrato shocks externos (M&A, due diligence, ratings). Coste: 4 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texto del documento original (contrato) sobre el que se hace la simulación. | |
| analysis | No | Análisis Nodo A previo (opcional). Si se aporta, la simulación se ancla al perfil de riesgo ya calculado. | |
| stressVariables | Yes | Variables de estrés a simular, en lenguaje natural. Ej: 'Subida de tipos de interés +200bp; demanda judicial colateral; cambio normativo fiscal post-2026'. Una variable por línea o separadas por puntos. | |
| jurisdiction | No | ES | |
| language | No | es |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It explains the process (simulate variables, requalify risks, compute IRC) and outputs (impact tables, recommendations), but omits side effects, auth requirements, or rate limits. Without annotations, more detail on behavioral traits would be beneficial.
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 paragraph that efficiently conveys purpose, process, and usage cues. It front-loads the key information and avoids fluff, though slightly longer than necessary.
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 complexity (5 parameters, no output schema), the description covers inputs, process, outputs (tables and recommendations), and usage context. It lacks return format details, but the mention of output types is sufficient for most agents.
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 60%, yet the tool description adds minimal value beyond what the input schema already provides. Parameters like 'text' and 'analysis' are not elaborated beyond the schema descriptions. The description does not compensate for the missing schema coverage, leaving some parameters under-explained.
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's purpose: Monte Carlo simulation for stress-testing contract risk profiles under user-defined variables, with specific outputs like IRC and shielding recommendations. It distinguishes from sibling tools by explicitly naming the simulation and scenario analysis functionality.
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 includes explicit usage guidance: 'USAR CUANDO: el cliente quiere saber cómo aguanta el contrato shocks externos'. It also mentions cost (4 créditos). However, it does not specify when not to use or provide alternative tools, which slightly diminishes clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SEGUNDA OPINIÓN JURÍDICA (Nodo Opinion — control adversarial con LLM distinto al Nodo A). Toma una respuesta del Nodo A y la reexamina con un modelo diferente, buscando: omisiones, sesgos, errores de aplicación normativa, o jurisprudencia ignorada. Útil para casos de alto valor. USAR CUANDO: el cliente exige doble validación sobre una posición jurídica antes de actuar. Coste: 2 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Pregunta sobre la que se quiere segunda opinión jurídica. | |
| nodaAResponse | Yes | Respuesta del Nodo A (Qwen/DeepSeek) sobre la pregunta. | |
| analysisContext | No | Contexto adicional del expediente (opcional). | |
| jurisdiction | No | ES | |
| language | No | es |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry full weight. It discloses the use of a different model and the cost (2 credits), but lacks details on side effects, data handling, or limitations.
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 front-loaded with the core function, followed by specific criteria and usage recommendation. It is concise but thorough, wasting no 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 the lack of output schema and 5 parameters, the description covers the essential purpose, usage context, and cost. It does not explain return values, but that is acceptable without an output schema.
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 description only implicitly refers to 'nodaAResponse' and does not explain other parameters like jurisdiction, language, or analysisContext. With 60% schema coverage, the description adds minimal value beyond the 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 identifies the tool as providing a second legal opinion by reexamining a Node A response with a different LLM, specifying the search for omissions, biases, and errors. This distinguishes it from siblings like nexus_adversarial which likely focuses on adversarial testing.
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 states when to use: when the client demands double validation on a legal position. It does not cover when not to use or alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RED TEAM ADVERSARIAL (Nodo C — modo destructivo). Análisis hostil del documento como si fuera el abogado de la contraparte: vacíos legales, cláusulas trampa, asimetrías de poder, riesgos catastróficos. Devuelve JSON estructurado con vulnerabilidades (severidad Alta/Media) y un catastrophic_risk_score 1-100. USAR CUANDO: pre-firma de contrato estratégico, auditoría de M&A, due diligence agresivo. Coste: 5 créditos.
| Name | Required | Description | Default |
|---|---|---|---|
| documentText | Yes | Texto íntegro del documento a atacar adversarialmente (típicamente un contrato). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility. It discloses the destructive mode, adversarial nature, and output structure (vulnerabilities with severity, risk score 1-100). It also mentions cost (5 credits). It does not cover every edge case (e.g., document size limits) but provides substantial behavioral context.
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 highly concise: three sentences covering purpose, output, usage scenarios, and cost. Information is front-loaded and each sentence adds value without redundancy.
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 simple input (one string parameter) and no output schema, the description adequately explains the tool's function, output fields, and appropriate use cases. Minor omissions (e.g., error handling, limits) are not critical for this straightforward 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?
Schema coverage is 100% (one parameter with description). The tool description reinforces the parameter's purpose ('texto íntegro del documento a atacar adversarialmente') and adds context about typical use (contracts). This adds meaning beyond the schema alone.
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 performs adversarial analysis of documents, listing specific elements like legal loopholes, trap clauses, and catastrophic risks. It uses a strong verb ('análisis hostil') and identifies the resource (document), and distinguishes from sibling tools like 'nexus_adversarial' by specifying a destructive mode and unique output fields.
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 explicitly provides usage scenarios with 'USAR CUANDO:' including pre-signing strategic contracts, M&A audit, and aggressive due diligence. It does not explicitly state when not to use or name alternatives, but the positive guidance is clear and context-rich.
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.0nexus_adversarialnexus_analyzenexus_auditnexus_consultanexus_cross_border_comparenexus_doctrinanexus_draftnexus_jurisprudencia_searchnexus_monte_carlonexus_opinionnexus_redteamScored across 11 tools
Each tool has a clearly distinct purpose: analysis, audit, drafting, search, adversarial (two variants with explicit differences), Q&A, comparative, simulation, second opinion. Descriptions explicitly differentiate overlapping ones (e.g., nexus_adversarial vs nexus_redteam). No ambiguity.
All tools use the nexus_ prefix with descriptive names in snake_case. Most are verb-based (analyze, audit, draft, search) but a few are nouns (consulta, doctrina). The mix of English and Spanish is domain-appropriate but slight inconsistency in verb/noun pattern.
11 tools is well-scoped for a legal MCP server covering analysis, drafting, research, adversarial testing, consultation, simulation, and cross-border comparison. Each tool earns its place without redundancy.
The tool surface covers the full legal workflow: primary analysis (nexus_analyze), Q&A (nexus_consulta), drafting (nexus_draft), research (nexus_jurisprudencia_search, nexus_doctrina), adversarial review (nexus_adversarial, nexus_redteam), audit (nexus_audit), second opinion (nexus_opinion), comparative law (nexus_cross_border_compare), and risk simulation (nexus_monte_carlo). No obvious gaps.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
AI legal compliance: contract review, risk scoring, EU/CN AI act, watermark check. 8 MCP tools.
Connect AI to millions of laws and court cases with the Lawstronaut MCP.
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
