Skip to main content
Glama
Dattics

Alegra MCP Server

by Dattics

Servidor MCP para Alegra API

Este proyecto implementa un servidor compatible con el Protocolo de Contexto de Modelo (MCP) que actúa como un puente hacia la API de contabilidad de Alegra. Permite que los Modelos de Lenguaje Grandes (LLMs) interactúen de forma segura con una amplia gama de recursos de Alegra, como facturas, contactos, ítems, pagos y más.

Elaborado por Juan Sánchez.

Características

  • Integración Completa con Alegra: Ofrece una herramienta (AlegraAPI) para realizar operaciones CRUD (GET, POST, PUT, PATCH, DELETE) en la mayoría de los endpoints de la API de Alegra.

  • Amplia Gama de Recursos: Soporta una gran variedad de recursos, incluyendo invoices, contacts, items, credit-notes, purchase-orders, bills, warehouses, bank-accounts, taxes, entre muchos otros.

  • Operaciones Flexibles: Permite la consulta de colecciones de recursos, la obtención de un recurso por su ID específico, la creación de nuevos recursos y la actualización parcial (PATCH) o completa (PUT) y la eliminación de los existentes.

  • Búsqueda y Filtrado: Admite el uso de parámetros de consulta para filtrar y paginar resultados en las solicitudes GET.

  • Manejo de Cuerpo de Solicitud: Utiliza el parámetro queryParams para enviar el cuerpo (body) de las solicitudes POST, PUT y PATCH.

  • Registro de Actividad: Todas las solicitudes (con su código de respuesta HTTP) y errores se registran en un archivo local alegra-mcp.log para facilitar la depuración y el seguimiento.

  • Sin dependencias externas de red: Utiliza el fetch nativo de Node.js 18+, sin librerías adicionales de HTTP.

Related MCP server: MCP-Odoo

Aviso de Seguridad Importante

Sus credenciales de Alegra nunca salen de su máquina.

Este servidor está diseñado con la seguridad como prioridad. La autenticación con la API de Alegra se gestiona de la siguiente manera:

  1. Credenciales Locales: El servidor lee su usuario (ALEGRA_USER) y token (ALEGRA_TOKEN) directamente desde variables de entorno en su máquina.

  2. Sin Almacenamiento en Disco: Las credenciales no están codificadas en el programa ni se guardan en ninguna base de datos. Se mantienen en memoria solo durante la sesión del proceso.

  3. Caché en Memoria (solo en RAM): Los headers de autenticación se calculan una vez y se reutilizan durante la sesión activa para mayor eficiencia; se descartan al cerrar el servidor.

  4. Protección en Git: El archivo .gitignore está configurado para excluir explícitamente cualquier archivo .env, evitando que sus credenciales sean enviadas accidentalmente a un repositorio de código.

Usted puede utilizar su LLM de confianza para validar el código y confirmar que sus credenciales no son almacenadas ni transmitidas a terceros. El archivo clave para revisar es src/auth.ts, donde se leen las variables de entorno para generar los headers de autorización.

Método 1: Ejecución Directa con NPX (para usuarios finales) - Fácil

Si no necesita modificar el código y solo desea utilizar la herramienta con su LLM, puede configurar su cliente MCP (por ejemplo, en el settings.json de VS Code) para que descargue y ejecute el servidor automáticamente.

Agregue la siguiente configuración a su cliente MCP:

{
"mcpservers": {
    "Alegra-MCP-Public": {
        "command": "npx",
        "args": [
            "-y",
            "@juancsanchez/alegra-mcp"
        ],
        "env": {
            "ALEGRA_USER": "su_email@dominio.com",
            "ALEGRA_TOKEN": "su_token_de_api_aqui"
        }
    }
}
}

Esta configuración le indica a su cliente que use npx para ejecutar la última versión del paquete, pasando sus credenciales de forma segura a través de variables de entorno, sin necesidad de clonar o instalar el proyecto manualmente.

Método 2: Instalación Local (para desarrolladores)

Siga estos pasos si desea modificar o examinar el código.

Requisitos Previos

  • Node.js: Se requiere la versión 18 o superior (utiliza fetch nativo).

  • Credenciales de Alegra: Necesita un usuario y un token de API de su cuenta de Alegra.

Instalación y Configuración

  1. Clonar el Repositorio

    git clone https://github.com/juancsanchez/Alegra-MCP
    cd alegra-mcp
  2. Instalar Dependencias

    npm install
  3. Configurar las Credenciales Cree un archivo llamado .env en la raíz del proyecto.

    touch .env

    Añada sus credenciales de Alegra al archivo .env:

    # Archivo .env
    ALEGRA_USER="su-correo@ejemplo.com"
    ALEGRA_TOKEN="su_token_secreto_de_la_api"

Uso

  1. Compilar el Código

    npm run build
  2. Iniciar el Servidor

    npm start

Available Tools

1 tool
AlegraAPIC

Una herramienta para interactuar con la API de contabilidad de Alegra. Permite realizar operaciones CRUD en una amplia gama de recursos como Facturas, Contactos, Items, Notas de Crédito, Órdenes de Compra y muchos más.

ParametersJSON Schema
NameRequiredDescriptionDefault
endpointYesEl tipo de recurso de la API de Alegra a consultar o modificar. Ej: 'invoices', 'contacts', 'items', 'credit-notes', 'purchase-orders', etc.
idNoEl ID específico de un recurso (ej: el ID de una factura para get, put, delete).
methodNoEl método HTTP a utilizar (get, post, put, delete).get
queryParamsNoParámetros de consulta adicionales (ej: 'start', 'limit', 'query' para GET) o cuerpo de la solicitud para POST/PUT.

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool allows CRUD operations but doesn't mention authentication requirements, rate limits, error handling, or what happens during mutations (e.g., are deletions permanent?). For a generic API tool with multiple endpoints and methods, this is a significant gap in 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.

Conciseness4/5

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

The description is concise and front-loaded, stating the core purpose in the first sentence and listing example resources. It avoids unnecessary fluff, though it could be slightly more structured (e.g., explicitly noting it's a generic wrapper). Every sentence contributes to understanding the tool's scope.

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

Completeness2/5

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

Given the tool's complexity (generic API wrapper with 4 parameters, multiple endpoints/methods, no output schema, and no annotations), the description is inadequate. It doesn't explain how to construct requests, handle responses, or manage errors. For a flexible but potentially error-prone tool, more guidance is needed to ensure correct usage.

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

Parameters3/5

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

The description mentions 'recursos' like Facturas and Contactos, which aligns with the 'endpoint' parameter, but doesn't add meaningful semantics beyond what the 100% schema coverage already provides. The schema descriptions thoroughly document each parameter, so the description adds minimal value here. Baseline 3 is appropriate given high schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'interactuar con la API de contabilidad de Alegra' and 'realizar operaciones CRUD en una amplia gama de recursos'. It specifies the action (CRUD operations) and resources (Facturas, Contactos, Items, etc.), though it doesn't need to differentiate from siblings since none exist. The description is specific but could be more precise about being a generic API wrapper rather than dedicated CRUD tools.

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

Usage Guidelines2/5

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. It mentions CRUD operations on various resources but doesn't explain prerequisites, constraints, or appropriate contexts for use. Without sibling tools, this is less critical, but the description still lacks any usage context or limitations.

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

Tool Schema Changelog

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

  1. 1 tool updatev1.0.0
    • First observedAlegraAPI

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool clearly handles all operations for the Alegra accounting API, so agents cannot misselect between multiple options.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect. The tool name 'AlegraAPI' follows a clear and descriptive pattern, and there are no other tools to compare it against for inconsistency.

Tool Count2/5

The server has only one tool, which is too few for the stated purpose of handling CRUD operations on a wide range of resources like invoices, contacts, items, credit notes, and purchase orders. A single tool for such a broad domain forces agents to handle complex parameter parsing and lacks the granularity needed for effective tool use.

Completeness2/5

While the single tool claims to cover all CRUD operations for many resources, this monolithic approach creates significant gaps in the tool surface. Agents will struggle with dead ends due to the lack of specific tools for distinct operations (e.g., separate create_invoice, get_contact tools), making the surface incomplete for reliable agent workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants to interact with Odoo ERP systems, providing comprehensive tools for searching, creating, updating, and managing Odoo records through a standardized interface.
    24
    GPL 3.0
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that bridges Odoo ERP systems with AI agents, enabling them to access and manipulate partner information, accounting data, invoices, and perform financial reconciliation through a standardized interface.
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server for KikoBooks enterprise bookkeeping software that enables AI assistants to perform accounting operations on accounts, customers, invoices, bills, and more through natural language.
    MIT
  • A
    license
    B
    quality
    A
    maintenance
    A Model Context Protocol (MCP) server for the Holded Invoice API. This server allows AI assistants like Claude to interact with Holded's invoicing, contacts, products, and more.
    78
    58
    19
    MIT

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dattics/Alegra-MCP'

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