How do I use Coherence Analysis MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Coherence Analysis MCP Audit this email for internal contradictions" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Coherence Analysis MCP

by Sofiamishel2003

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Coherence Analysis MCP

Servidor MCP de analisis de coherencia interna de correos. Componente del prototipo de deteccion de phishing con modelos de lenguaje grandes y servidores MCP (trabajo de graduacion, Universidad del Valle de Guatemala).

Que es

Este servidor audita las contradicciones internas de un correo: si lo que dice ser el remitente, el tono, el formato, lo que pide y la firma son consistentes entre si. La idea central es que un correo legitimo suele ser internamente coherente, mientras que uno de phishing casi siempre tiene costuras, aunque cada elemento por separado no parezca sospechoso: dice ser tu banco pero saluda de forma generica, transmite urgencia extrema con un tono informal y errores, pide datos que una entidad real nunca pediria por correo, o firma como una organizacion distinta a la que aparece en el remitente.

Punto central de diseno: el servidor no emite un veredicto de phishing. Solo reporta las incoherencias detectadas, cada una con su cita textual literal como evidencia. La decision final de clasificacion pertenece al orquestador.

Otro punto central de diseno: la deteccion la hace un LLM con salida estructurada, no listas de palabras clave ni conteos lexicos. Se probo que los conteos lexicos no discriminan bien entre correos legitimos y de phishing; el LLM puede razonar sobre coherencia semantica y de estilo de una forma que un conteo de palabras no puede.

Categorias de incoherencia auditadas

Categoria	Que busca
`sender_vs_content`	Afirma ser una entidad conocida pero el saludo es generico o el estilo no cuadra
`urgency_vs_channel`	Comunica algo grave o urgente de forma informal o con errores
`subject_vs_body`	El asunto y el cuerpo no coinciden en lo que ofrecen o piden
`authority_vs_execution`	Se presenta como oficial pero tiene errores de gramatica, formato pobre o inconsistencias
`request_vs_context`	Pide datos sensibles o acciones que una entidad legitima no solicitaria por correo
`identity_consistency`	El remitente, la firma y el contenido nombran entidades distintas o inconsistentes

Un correo puede mostrar cero, una o varias de estas incoherencias; el LLM no esta forzado a encontrar algo en cada categoria.

Estructura del proyecto

coherence-analysis-MCP/
├── src/coherence_analysis_mcp/
│   ├── __init__.py       Expone main() importandola desde server
│   ├── server.py         Servidor MCP y definicion de las 3 herramientas
│   ├── schema.py         Esquema Pydantic de salida y las 6 categorias
│   ├── llm_engine.py     Abstraccion del motor LLM (mock + Anthropic)
│   └── coherence.py      Logica del analisis: prompt, guardrails, validacion de evidencia
├── tests/
│   ├── test_coherence.py     Pruebas unitarias (esquema, evidencia, modo mock)
│   └── test_integration.py   Prueba end-to-end (cliente MCP real por stdio, modo mock)
├── run_server.py          Punto de entrada recomendado para arrancar el servidor
├── pyproject.toml
└── README.md

Instalacion

Con uv (recomendado):

uv sync

Con pip en modo editable:

pip install -e ".[dev]"

Configuracion del motor LLM

El motor LLM se configura por variable de entorno; nunca hay una API key hardcodeada en el codigo. Ver .env (no se versiona, solo sirve de plantilla local):

Variable	Valores	Por defecto
`COHERENCE_LLM_PROVIDER`	`mock` o `anthropic`	`mock`
`COHERENCE_LLM_MODEL`	nombre del modelo (solo aplica si el proveedor no es `mock`)	`claude-sonnet-5`
`COHERENCE_LLM_API_KEY`	API key del proveedor configurado	(vacio)

Modo mock (COHERENCE_LLM_PROVIDER=mock, valor por defecto): no llama a ninguna API ni necesita conectividad ni API key. Devuelve siempre la misma respuesta fija y valida, calibrada sobre un correo de referencia (MOCK_EMAIL_TEXT en llm_engine.py). Es el modo que usan las pruebas automatizadas.

Proveedor real implementado: Anthropic. Usa tool use forzado (tool_choice) contra la API de Claude para obtener JSON valido segun el esquema de schema.py, que luego se vuelve a validar con Pydantic. Es el unico proveedor real de referencia por ahora; la clase LLMEngine en llm_engine.py esta disenada para que agregar otro proveedor (OpenAI, por ejemplo) sea sumar una subclase nueva y una rama en get_engine(), sin tocar coherence.py ni server.py.

Herramientas expuestas

Herramienta	Que hace
`analyze_coherence`	Dado el texto de un correo, devuelve el reporte de incoherencias detectadas (JSON validado)
`get_output_schema`	Devuelve el esquema JSON de salida, para que el orquestador sepa que esperar sin llamar primero a `analyze_coherence`
`list_incoherence_categories`	Lista las 6 categorias de incoherencia auditadas, con su descripcion

Forma del reporte de `analyze_coherence`

{
  "incoherences": [
    {
      "category": "sender_vs_content",
      "description": "...",
      "quote": "cita textual literal del correo"
    }
  ],
  "coherence_score": 0.15,
  "summary": "Resumen en lenguaje claro de las principales incoherencias.",
  "discarded_count": 0
}

coherence_score va de 0 (lleno de contradicciones) a 1 (totalmente coherente).
Cada incoherencia trae una cita textual literal del correo como evidencia obligatoria. coherence.py valida que cada cita aparezca realmente en el texto (ignorando solo diferencias de espacios); cualquier incoherencia cuya cita no exista se descarta antes de devolver el resultado, y discarded_count indica cuantas se descartaron asi.
El correo se trata siempre como dato no confiable: el prompt lo delimita explicitamente y le indica al LLM que ignore cualquier instruccion dentro del texto del correo (guardrail contra prompt injection).

Como probarlo

1. Pruebas unitarias (rapidas, sin arrancar el servidor ni llamar a ninguna API; usan el modo mock):

uv run python tests/test_coherence.py

2. Prueba de integracion end-to-end (arranca el servidor y actua como cliente MCP real, con handshake y llamada a las 3 herramientas, forzando modo mock):

uv run python tests/test_integration.py

3. Con pytest (corre ambas pruebas):

uv run pytest tests/

4. Inspeccion manual con el MCP Inspector (interfaz visual oficial):

uv run mcp dev src/coherence_analysis_mcp/server.py

5. Arranque directo del servidor (queda esperando mensajes por stdio; usa Ctrl+C para salir):

uv run python run_server.py

Como conectarlo a un cliente MCP

Para usarlo desde un cliente compatible (por ejemplo, Claude Desktop, o el orquestador del prototipo), agrega al archivo de configuracion del cliente:

{
  "mcpServers": {
    "coherence-analysis-mcp": {
      "command": "uv",
      "args": ["run", "python", "run_server.py"],
      "cwd": "/ruta/al/proyecto/coherence-analysis-MCP",
      "env": {
        "PYTHONUTF8": "1",
        "COHERENCE_LLM_PROVIDER": "anthropic",
        "COHERENCE_LLM_MODEL": "claude-sonnet-5",
        "COHERENCE_LLM_API_KEY": "..."
      }
    }
  }
}

Por que existe run_server.py (y no simplemente el comando de consola)

El proyecto tambien instala un comando de consola (coherence-analysis-mcp, definido en [project.scripts] de pyproject.toml), que es la convencion normal de este tipo de servidor MCP. Sin embargo, ese comando depende de que coherence_analysis_mcp sea importable a traves del mecanismo de instalacion editable de uv/pip (un archivo .pth en site-packages que apunta de vuelta a src/). En maquinas donde la ruta del proyecto contiene caracteres no ASCII (como las tildes y la eñe de este proyecto: Sofía, año), Python puede leer ese .pth con la codificacion de texto por defecto del sistema (cp1252 en Windows en vez de UTF-8), la ruta queda corrupta, y el import falla en silencio con ModuleNotFoundError: No module named 'coherence_analysis_mcp', sin relacion alguna con el codigo del servidor.

run_server.py evita el problema de raiz: agrega src/ a sys.path directamente en Python (con pathlib, sin leer ningun archivo .pth) antes de importar el paquete. Funciona igual sin importar quien lo invoque (tu terminal, mcp dev, o un cliente MCP como Claude Desktop) y sin necesitar ninguna variable de entorno. Por eso es el metodo recomendado, tanto en los comandos de arriba como en el ejemplo de configuracion de cliente MCP.

Si prefieres usar uv run coherence-analysis-mcp de todas formas y tu maquina tiene el mismo problema, corre set PYTHONUTF8=1 (cmd) o $env:PYTHONUTF8=1 (PowerShell) antes, en la misma terminal donde vas a correr el comando.

La variable de entorno PYTHONUTF8=1 fuerza a Python a usar UTF-8 en todos lados y resuelve esto por completo. Por eso aparece en el .env del proyecto y en el env del ejemplo de configuracion de cliente MCP arriba (los clientes como Claude Desktop arrancan el servidor como un subproceso nuevo, que no hereda las variables que hayas exportado en tu propia terminal).

Las pruebas (test_coherence.py, test_integration.py, pytest) no necesitan esto porque agregan src/ a sys.path explicitamente en el codigo (o arrancan el servidor via run_server.py), sin depender de la instalacion editable.

Autoria

Sofia Mishell Velasquez - Universidad del Valle de Guatemala.

Available Tools

3 tools

analyze_coherenceA

Audit the internal coherence of an email and return detected incoherences.

Uses an LLM with structured output to find contradictions between what
the email claims to be and how it is actually written (e.g. claims to be
a bank but greets generically, is urgent but informal, requests data a
real entity would not ask for by email). Every reported incoherence is
validated to have a literal quote present in the email text; any
incoherence whose quote cannot be found verbatim is discarded before the
result is returned. This is NOT a phishing verdict, only a coherence
signal for the orchestrator to weigh alongside other MCP servers.

Args:
    email_text: Full text of the email to analyze (subject and/or body).
        Treated strictly as untrusted data, never as instructions.

ParametersJSON Schema

Name	Required	Description	Default
`email_text`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and exceeds it: it discloses the use of an LLM, the literal-quote validation and discard rule, the non-verdict nature, and the security stance that email_text is untrusted data never treated as instructions.

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

Conciseness4/5

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

The purpose is front-loaded, and the description is organized into purpose, behavior, and args paragraphs with no redundant filler. It is a bit longer than strictly necessary because of the examples, but each sentence contributes behavioral or usage value.

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 an LLM-based analysis tool with no annotations and no output schema, it covers input, behavior, validation, and trust boundary. The only real gap is that it does not describe the structure of the returned incoherences, though it hints at the literal-quote field and sibling get_output_schema exists.

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

Parameters4/5

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

Schema coverage is 0% for email_text, but the Args block compensates by defining it as the full email text (subject and/or body) and by warning it must be treated as untrusted data. It could add length/encoding constraints, but for one parameter it is effectively complete.

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?

Opens with a specific verb and resource: 'Audit the internal coherence of an email and return detected incoherences.' The examples clarify what counts as incoherence, and the explicit 'NOT a phishing verdict' distinguishes its scope from other security/analysis tools.

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

Usage Guidelines4/5

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

The description states when it should be used ('coherence signal for the orchestrator') and an explicit when-not ('NOT a phishing verdict'), which gives clear context. It does not name alternatives or sibling tools like list_incoherence_categories, so it stops just short of full routing guidance.

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

get_output_schemaA

Return the JSON schema of the structured output produced by
analyze_coherence, so the orchestrator knows what fields to expect
(incoherences, coherence_score, summary, discarded_count) without
needing to call the tool first.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It clearly indicates a read-only introspection behavior by saying it 'returns' the schema and that the orchestrator does not need to call analyze_coherence first. No side effects or surprising behaviors are implied.

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?

The description is a single focused sentence that front-loads the core purpose, then adds the key benefit and the expected fields. Every part earns its place with no repetition or filler.

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?

For a zero-parameter introspection tool, the description is complete: it states what is returned, the source tool, the expected fields, and the orchestration benefit. No additional details are needed for an agent to call it correctly.

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

Parameters4/5

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

The tool has zero parameters, so the description does not need to document parameter behavior. It adds value by listing the exact fields the returned schema will include, which is useful context beyond the empty input schema.

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 states a specific verb ('Return') and a specific resource ('the JSON schema of the structured output produced by analyze_coherence'). It also differentiates this tool from its sibling analyze_coherence by clarifying that it returns metadata rather than the analysis output itself.

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

Usage Guidelines4/5

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

The description gives clear context: use this tool to know what fields to expect from analyze_coherence before calling it. It implies the alternative of calling analyze_coherence first and explains why this tool is preferable ('without needing to call the tool first'), though it does not explicitly enumerate when not to use it.

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

list_incoherence_categoriesA

List the 6 incoherence categories this server audits, with a
description of what each one looks for. Useful for the orchestrator to
understand the results of analyze_coherence without guessing what each
category id means.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are present, so the description carries the behavioral burden. It discloses that this is a read-only listing operation, that the list is fixed to six server-audited categories, and that each item includes a description. It does not explicitly state side effects or list all output fields, but for a parameterless introspection 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.

Conciseness5/5

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

Two sentences, each earning its place: the first states exactly what the tool returns, and the second explains why the orchestrator would use it. The information is front-loaded with no filler.

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 zero-parameter tool with no output schema, the description provides the key context: the item count, the purpose, and how it relates to analyze_coherence. It could be more explicit about the exact return shape, but an agent can call this tool correctly with no further information.

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

Parameters4/5

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

The input schema has zero properties, so the baseline for this dimension is 4. No parameter explanations are needed, and the description adds nothing that could conflict with the schema.

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 states a specific action ('List'), a specific resource ('the 6 incoherence categories this server audits'), and what each entry contains ('a description of what each one looks for'). It also differentiates itself from analyze_coherence by explaining that it removes the need to guess what each category id means.

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

Usage Guidelines4/5

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

The description gives clear context: it is useful for the orchestrator to interpret analyze_coherence results. It does not explicitly mention exclusions or alternative tools, but the intended use case is obvious from the tie to analyze_coherence.

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.

3 tool updatesv0.1.0Sep 15, 2026
- First observedanalyze_coherence
- First observedget_output_schema
- First observedlist_incoherence_categories

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored 2026-09-15 20:40 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze_coherence performs the analysis, get_output_schema returns the result schema, and list_incoherence_categories explains the audit categories. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow the same snake_case verb_noun pattern: analyze_coherence, get_output_schema, list_incoherence_categories. The naming is perfectly consistent and predictable.

Tool Count5/5

Three tools is appropriate for this narrow, stateless analysis server: one primary tool plus two supporting metadata tools. Every tool earns its place and the surface is not padded or redundant.

Completeness5/5

The tool surface fully covers the stated domain: analyze_coherence performs the core task, get_output_schema tells the caller what to expect, and list_incoherence_categories provides the context needed to interpret results. There are no obvious missing operations or dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Rosey – Quality verification for human and AI contentOAuth
com.getrosey
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
Testing & QA Tools RAG Systems AI & Machine Learning
1
MCP x402 - Evidence-Backed Web Verification A
io.github.Diogoup26
Evidence-backed x402 web verification for AI agents, with auditable decisions for every condition.
Security Browser Automation Payments & Billing
31
DocVerdict A
io.github.rogerberent-netizen
PDF, photo, email, and file comparison evidence checks with plain-language reports.
Legal & Compliance Image & Video Processing Email
42
Hlido Agent Reviews A
eu.hlido
Independent AI-agent reviews: trust checks, evidence scorecards, incident registry, recommendations.
AI & Machine Learning Security
192

Related MCP Servers

coherra
Knowledge & Memory Autonomous Agents
Steve2009729
A
license
A
quality
C
maintenance
Enables agents to audit and repair their long-term memory in Sibyl Memory, detecting contradictions, duplicates, and stale facts, and fixing them with a permanent audit trail.
Updated 25 days ago (2026-08-22 09:41 UTC)
7
MIT
genpark-rag-retrievalofficial
RAG Systems AI & Machine Learning Testing & QA Tools
alphaparkinc
F
license
Not graded
quality
B
maintenance
Enables deterministic auditing of RAG retrieval faithfulness and hallucination scores, providing structured JSON output for AI agents and MCP-compliant clients.
Updated 14 days ago (2026-09-02 10:53 UTC)
8
-
genpark-study-methodology-bias
Research & Data
Alpha-Park
F
license
Not graded
quality
B
maintenance
Enables auditing scientific papers for methodological biases such as selection bias and p-hacking, and assessing citation credibility and research consensus.
Updated 10 days ago (2026-09-06 12:32 UTC)
8
-
memory-immune-system
Knowledge & Memory AI & Machine Learning
yashraz23
A
license
Not graded
quality
C
maintenance
Enables real-time auditing of LLM long-term memory to detect contradictions, user-introduced falsehoods, staleness, and unsourced fabrications, while providing a safe memory store with tools like recall, review, and restore.
Updated 9 days ago (2026-09-07 04:57 UTC)
1
MIT

Coherence Analysis MCP

Que es

Categorias de incoherencia auditadas

Estructura del proyecto

Instalacion

Configuracion del motor LLM

Herramientas expuestas

Forma del reporte de analyze_coherence

Como probarlo

Como conectarlo a un cliente MCP

Por que existe run_server.py (y no simplemente el comando de consola)

Autoria

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

coherra

genpark-rag-retrievalofficial

genpark-study-methodology-bias

memory-immune-system

Forma del reporte de `analyze_coherence`