EvidenceLens MCP
EvidenceLens MCP
EvidenceLens MCP es un servidor TypeScript del Model Context Protocol para contratos deterministas de revisión de evidencia de solo lectura. La única herramienta review_evidence acepta contenido en línea de la Fase 2 y, cuando se configura explícitamente, fuentes del sistema de archivos de la Fase 3. Normaliza texto, tablas, PDFs, imágenes y capturas de pantalla en metadatos de procedencia, manteniendo los hallazgos vacíos y sin realizar llamadas a proveedores.
Desarrollo local
npm install
npm run dev
npm test
npm run buildnpm run dev inicia el servidor MCP a través de stdio desde src/server.ts. npm test ejecuta la suite de pruebas completa de contrato, normalizador, fixtures, seguridad y protocolo MCP. npm run build comprueba los tipos y compila el servidor.
Related MCP server: Observability Agent MCP
Contrato MCP
Consulta docs/mcp-contract.md para conocer el contrato exacto de solicitudes en línea/sistema de archivos, la gramática de configuración de raíces, los límites de bytes, la procedencia filesystem://, los metadatos de evidencia normalizados, los errores estables y los límites de solo lectura/sin proveedor/sin hallazgos.
Nota sobre plataformas: el lector de sistema de archivos predeterminado utiliza recorrido de componentes relativo a descriptores en Linux. En macOS, donde este proyecto no tiene un enlace Node openat/openat2 compatible, las lecturas de sistema de archivos ancladas predeterminadas fallan de forma segura con ACCESS_DENIED saneado y sin bytes; no hay respaldo por nombre de ruta. La evidencia en línea de la Fase 2 sigue siendo compatible, y las pruebas de incrustación pueden inyectar un adaptador de sistema de archivos seguro revisado para una cobertura portátil de lectura del sistema de archivos.
Raíces opcionales del sistema de archivos
El acceso al sistema de archivos está deshabilitado cuando no se configuran raíces; el servidor nunca recurre al directorio actual, al directorio personal, al repositorio ni a otro valor predeterminado amplio. Configura raíces explícitas con entradas repetidas id=absolute-path separadas por comas o puntos y coma:
EVIDENCELENS_ALLOWED_ROOTS='course=/absolute/path/course;examples=/absolute/path/examples' npm run devLos ID de raíz coinciden con [A-Za-z][A-Za-z0-9_-]{0,31}. Las entradas vacías, los ID duplicados, las colisiones de rutas canónicas, las raíces ilegibles, los elementos que no son directorios, las rutas relativas y las entradas malformadas fallan con el mensaje estable Invalid filesystem root configuration; las rutas nunca se muestran.
Available Tools
1 toolreview_evidenceReview EvidenceCRead-onlyIdempotent
Accept Phase 1 evidence review metadata and return a deterministic skeleton response.
| Name | Required | Description | Default |
|---|---|---|---|
| limits | No | ||
| evidence | No | ||
| reviewId | Yes | ||
| objective | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already document the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description adds the behavioral fact that the response is deterministic and skeleton-shaped. However, it does not say what the skeleton response contains or how input is handled, leaving a partial transparency gap.
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?
One sentence with no filler; the core action and outcome are front-loaded. It is appropriately sized but terse to the point of vagueness, so not a full 5.
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 a nested input schema and no output schema, the description is too thin: it does not explain the return shape, what 'Phase 1' means, or what evidence metadata is expected. Annotations cover safety but not operational context needed to 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 description coverage is 0%, so the description needed to compensate for parameter meaning, but it mentions no parameter names or semantics. The schema itself provides constraints and enums, but the tool description contributes nothing to clarify reviewId, objective, evidence, or limits.
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 a concrete verb-resource pair ('Accept Phase 1 evidence review metadata') and names the outcome ('return a deterministic skeleton response'), so an agent can tell this is a submission/stub endpoint for the review workflow. However, 'skeleton response' is unexplained and there is no sibling differentiation, though no siblings are listed.
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 gives no guidance about when to call this tool versus any alternative, no workflow conditions, and no preconditions or exclusions. The only hint is the phrase 'Phase 1,' which is not elaborated.
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.
1 tool update
v0.1.2- First observed
review_evidence
TDQS
Scored across 1 tool
There is only one tool, so there is no ambiguity between tools, but the single tool's purpose is vague and could overlap with future tools. Since there is no set to disambiguate, it scores minimal.
With only one tool, naming consistency is trivial but the naming is not informative; 'review_evidence' is a generic name that doesn't indicate what it does with evidence. No pattern can be assessed.
A single tool for a server called 'EvidenceLens MCP' that claims to 'review evidence' is too thin. The scope suggests a larger toolset for evidence review, but only one trivial tool is provided.
The tool description says 'Accept Phase 1 evidence review metadata and return a deterministic skeleton response.' This covers only a tiny fraction of what an evidence review workflow would need; there's no way to submit actual evidence, get details, update reviews, or handle later phases.
Maintenance
Related MCP Connectors
Read-only game, setup, place, evidence and travel decision tools with explicit provenance.
Agent memory that refuses to guess: evidence-gated recall, exact-source reads, verifiable deletion.
Read-only finance and operations controls for AI agents with evidence and safe next actions.
Browser-local and CLI static evidence for deployed AI model artifacts.
Related MCP Servers
AlicenseNot gradedqualityFmaintenanceProvides a universal read path for agents to extract facts, metadata, and provenance from local files and guarded remote URLs without using generative LLMs.MIT- AlicenseBqualityCmaintenanceA portable, read-only Model Context Protocol server for turning observability data into bounded evidence that AI agents can inspect safely.7Apache 2.0
- AlicenseNot gradedqualityDmaintenanceEnables step-debugging, deterministic replay, and signed audit evidence for AI agents, compliant with EU AI Act.62 PyPIMIT
- AlicenseNot gradedqualityCmaintenanceEnables secure, read-only access to local project files (including text, DOCX, PDF, and XLSX) through MCP, with strict directory whitelisting and no write, edit, or command-execution tools.1MIT