The siigo-pyme-mcp server exposes SIIGO Pyme's accounting features as MCP tools, enabling AI agents to interact with a Colombian ERP on Windows. It wraps the EXCELSIIGO.exe CLI, providing 56 tools: configuration, discovery, and 47 export/import functions.
Configuration & Discovery
Auto-detect SIIGO installations and available companies (SIIWI01–SIIWI99)
Set user/password credentials globally or per company, assign aliases, manually add installations, view masked config
List all 47 CLI functions, filter by group, and describe any function (parameters, examples)
Paginated reading of generated .xlsx files
Accounting (Contabilidad)
Export/Import: siigo_getmov/siigo_pushmov (journal entries), siigo_getmvt (cashier movements)
Export: siigo_getinf (trial balances by account/third party), siigo_getsal (AR/AP balances)
Export/Import: siigo_getcta/siigo_pushcta (chart of accounts), siigo_getmul/siigo_pushmul (multiple withholding accounts), siigo_getica/siigo_pushica (ICA tax activities)
Inventory (Inventarios)
Export/Import: siigo_getlin/siigo_pushlin (lines & groups), siigo_getinv/siigo_pushinv (products), siigo_getlis/siigo_pushlis (price lists), siigo_getkit/siigo_pushkit (kits/BOMs), siigo_getpre/siigo_pushpre (sales budget formulas), siigo_getbodm/siigo_pushbodm (warehouse min/max), siigo_gettbo/siigo_pushtbo (warehouses)
Export: siigo_getbod (warehouse stock), siigo_getbop (stock by classification)
Serials (Seriales)
Export: siigo_getsrl (serial master), siigo_getmsrl (serial movements), siigo_getbsrl (serials per warehouse)
Fixed Assets (Activos Fijos)
Export/Import: siigo_getact/siigo_pushact (assets), siigo_getgra/siigo_pushgra (asset groups)
Extra-Accounting Documents
Export/Import: siigo_getext/siigo_pushext (orders, quotes, etc.)
Master Data (Maestros)
Export/Import: siigo_getter/siigo_pushter (third parties), siigo_getven/siigo_pushven (salespeople), siigo_getcos/siigo_pushcos (cost centers)
Export: siigo_getciu (countries & cities)
Payroll (Nómina)
Export/Import: siigo_getempl/siigo_pushempl (employees)
Export: siigo_getnov (payroll novelties), siigo_gethn (novelty history)
All GET functions return parsed JSON with the first 50 rows, column names, and a next offset for pagination. PUSH functions write results to the company’s TEMP folder. Companies can be referenced by path, number, or alias. Credential precedence: per-company overrides global. Concurrent executions are queued, and SIIGO error dialog titles are surfaced as error messages.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@siigo-pyme-mcp dame los terceros de la empresa 02"
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.
Servidor MCP que expone SIIGO Pyme a un agente de IA.
Envuelve EXCELSIIGO.exe, el ejecutable de interfases de SIIGO, y convierte sus 47 funciones
de exportación e importación en herramientas MCP con parámetros documentados, descubrimiento
automático de empresas y resultados ya parseados a JSON.
Agente: "dame los terceros de la empresa 02"
→ siigo_run_function(funcion: "GETTER", empresa: "02")
→ EXCELSIIGO.exe Z:\SIIWI02\ 2026 GETTER L USUARIO **** ... Terceros.xlsx
→ { ok: true, archivo: "...", totalFilas: 1240, columnas: [...], filas: [...] }Se autodiagnostica: npx -y siigo-pyme-mcp --doctor dice si el equipo puede ejecutar SIIGO y qué
falta, y --print-config escupe el bloque de configuración exacto para su cliente MCP. Las dos
cosas funcionan antes de registrar nada.
Requisito | Por qué |
Windows | SIIGO Pyme solo existe en Windows. |
SIIGO Pyme instalado | Se necesita |
Microsoft Excel instalado | SIIGO genera los |
Sesión de escritorio activa | Consecuencia de lo anterior: no funciona como servicio de Windows, ni por SSH sin sesión, ni en un contenedor. Durante cada ejecución verás aparecer la ventana de progreso de SIIGO y Excel: no se pueden ocultar, con la ventana oculta el proceso se cuelga sin generar nada. |
Node.js 18 o superior | Para ejecutarlo con |
Related MCP server: Yxcel
No hace falta instalar nada: se ejecuta con npx. Cuatro pasos, y el propio paquete guía cada uno.
npx -y siigo-pyme-mcp --doctor # 1. ¿puede este equipo ejecutar SIIGO?
npx -y siigo-pyme-mcp --print-config --cliente hermes # 2. el bloque exacto a pegar
npx -y siigo-pyme-mcp --print-agent-rules --cliente hermes # 3. que el agente sepa usarlo
# 4. reinicie el cliente MCP y repita --doctor--print-config conoce hermes, Claude Desktop, Claude Code, VS Code y Cursor, e imprime
además los primitivos del protocolo para cualquier cliente que no esté en la lista. Sin argumento
--cliente los muestra todos. Para el caso genérico:
{
"mcpServers": {
"siigo": {
"command": "npx",
"args": ["-y", "siigo-pyme-mcp"],
"env": {
"SIIGO_USUARIO": "TU_USUARIO",
"SIIGO_CLAVE": "TU_CLAVE"
}
}
}
}El -y no es opcional: sin él npx pide confirmación por consola, se queda esperando, y el
cliente MCP interpreta ese silencio como que el servidor no arrancó.
Síntoma | Causa real |
| Se está instalando fuera de Windows (WSL, contenedor, Linux). Hay que registrarlo en la máquina Windows donde está SIIGO; |
El cliente dice que el servidor no arrancó, sin más detalle | Falta el |
| El cliente MCP no tiene |
Arranca, pero toda función falla sin generar archivo | Falta Excel, falta la sesión de escritorio, o alguna ruta pasa de 50 caracteres. Ejecute |
En hermes hay un detalle que rompe la configuración escrita a mano: en su config.yaml, args y
env son cadenas JSON dentro del YAML, no una lista y un mapa YAML. --print-config --cliente hermes ya lo emite así.
Registrar el servidor no basta para que el agente sepa qué hacer con él. El "cómo usarme" vive en tres canales del protocolo MCP, y no todos los clientes los leen:
instructions del InitializeResult — el texto que este servidor manda al conectar.
Recursos (siigo://guia/inicio, siigo://protocolo) y el prompt siigo_puesta_en_marcha.
Los nombres y descripciones de las herramientas — el único canal que todo cliente MCP entrega, porque sin él no podría llamarlas.
En hermes, por ejemplo, el canal 1 se pierde por completo: captura el InitializeResult solo
para leer capabilities y nunca lee .instructions (tools/mcp_tool.py, en el comentario junto
a self.initialize_result). Los recursos y prompts del canal 2 son opt-in y ningún agente los
consulta espontáneamente. Solo queda el canal 3, así que este servidor lo usa a fondo:
siigo_start_here es la primera herramienta de tools/list, titulada "LEER PRIMERO", y
devuelve el protocolo de uso completo.
Si el agente no la llama, la primera respuesta de cualquier otra herramienta siigo_* en
el proceso trae el protocolo anexado al final de su contenido, una sola vez.
npx -y siigo-pyme-mcp --print-agent-rules --cliente <su cliente> imprime ese mismo
protocolo en el formato de reglas del cliente (una skill con frontmatter para hermes y Claude
Code, un bloque para pegar en AGENTS.md o las instrucciones del proyecto para el resto), para
que llegue antes de la primera llamada. Con --instalar lo escribe directamente en la
carpeta de skills del cliente (por ejemplo %LOCALAPPDATA%\hermes\skills\siigo-pyme-mcp\SKILL.md);
nunca sobrescribe un fichero existente con contenido distinto salvo que se agregue --forzar.
siigo_doctor — verifica el entorno y dice qué falta. Es la primera llamada ante cualquier fallo.
siigo_list_companies — lista las empresas SIIWI01..SIIWI99 disponibles.
siigo_set_credentials — guarda usuario y clave. Sin indicar empresa, la credencial
se aplica a todas, que es lo más cómodo si usa el mismo usuario en todas ellas.
siigo_describe_function — los parámetros exactos de la función que va a usar.
siigo_run_function — ejecútela.
siigo_set_credentials(usuario: "TU_USUARIO", clave: "TU_CLAVE")
siigo_set_company_alias(empresa: "Z:\\SIIWI01\\", alias: "Inmunotek")
siigo_describe_function(funcion: "GETMOV")
siigo_run_function(funcion: "GETMOV", empresa: "Inmunotek",
params: { fechaInicial: "0101", fechaFinal: "0131", tipoComprobante: "F" })El paso 4 no es ceremonia: el CLI acepta un parámetro mal formateado, lo registra como 081 y
termina con código 0, así que un error de parámetros se parece a un éxito. Es la única forma
en la que este servidor puede devolver datos equivocados.
Instalaciones: se leen del registro de Windows
(HKLM\SOFTWARE\WOW6432Node\Informatica y Gestion S.A\Siigo Windows), de la configuración
del servidor, y escaneando las unidades en busca de carpetas <X>:\Siigo* que contengan
EXCELSIIGO.exe. Puede tener varias (C:\Siigo, C:\Siigo2, D:\Siigo...).
Empresas: cada instalación declara en su filepath.txt la ruta de una empresa.
A partir de ella se explora la carpeta que la contiene buscando SIIWI00..SIIWI99. Solo
se aceptan las que traen datos reales de SIIGO (ZnnSIIGO, CONFIMP.CFG, archivos .DIS),
de modo que carpetas homónimas vacías o de instalación no se ofrecen como empresas.
Para registrar algo que el autodescubrimiento no ve, use siigo_add_installation o
guarde credenciales directamente sobre la ruta de la empresa con siigo_set_credentials.
Puede referirse a una empresa por su ruta (Z:\SIIWI01\), por su número (01) o por el alias.
Por defecto expone 12. Cada esquema de herramienta viaja en cada llamada al modelo, así que
las 47 funciones como herramientas independientes cuestan unos 35 000 tokens por llamada —
medidos: 140 116 caracteres de tools/list frente a 8 927 del perfil por defecto, un 94 % menos.
Se controla con SIIGO_TOOLS:
| Herramientas | Coste de |
| 12: las de apoyo más | ~2 200 tokens |
| 58: una por cada función | ~35 000 tokens |
Herramienta | Para qué |
| LEER PRIMERO: protocolo de uso completo. Primera de |
| Verifica Windows, SIIGO, Excel, sesión de escritorio, credenciales, empresas y el límite de 50 caracteres. No ejecuta nada de SIIGO. |
| Instalaciones de SIIGO detectadas. |
| Empresas disponibles, con alias y si tienen credenciales. |
| Catálogo de las 47 funciones, filtrable por grupo. |
| Parámetros, orden posicional y ejemplo del manual de una función. |
| Guarda usuario y clave, global o por empresa. |
| Da un nombre legible a una empresa. |
| Registra una instalación que no se detectó sola. |
| Muestra la configuración (claves enmascaradas). |
| Lee de forma paginada cualquier |
En el perfil core, una sola: siigo_run_function, que ejecuta cualquiera de las 47 por
nombre. En all, una por función con el nombre en minúsculas (siigo_getmov, siigo_getter,
siigo_pushmov...). Las dos rutas construyen exactamente el mismo argv, y hay un test que lo
compara lado a lado.
Todas aceptan los mismos campos comunes — empresa (obligatorio), anio, norma,
instalacion, usuario, clave — más los parámetros propios de la función. Las de
exportación admiten además filasPreview.
siigo_run_function exige confirmarEscritura: true para las funciones PUSH*. Al colapsar
47 herramientas en una se pierde el destructiveHint por función, y una importación escribe en la
contabilidad sin que el servidor pueda deshacerla; la protección pasa a ser explícita.
siigo://guia/inicio trae la misma guía que --help, y siigo://funcion/{nombre} la firma de
una función en markdown, para consultarla sin gastar una llamada de herramienta. El prompt
siigo_puesta_en_marcha recorre el arranque completo. Los recursos no cuestan contexto salvo que
el cliente los pida.
Las funciones GET* devuelven la ruta del .xlsx, el total de filas, las columnas y las
primeras 50 filas ya parseadas, con un siguienteOffset para continuar con siigo_read_xlsx.
Los modelos de SIIGO no empiezan por los títulos: llevan el nombre de la empresa en la fila 1,
el del modelo en la 2, dos filas vacías, y los encabezados en la 5. El lector detecta esa fila
automáticamente y recorta el relleno de espacios que arrastra COBOL. Si algún modelo despista a
la heurística, siigo_read_xlsx acepta filaEncabezado para forzarla.
Se guarda en %APPDATA%\siigo-pyme-mcp\config.json (se puede reubicar con
SIIGO_MCP_CONFIG_DIR).
{
"installations": ["D:\\Siigo"],
"defaultCredentials": { "user": "TU_USUARIO", "password": "TU_CLAVE" },
"companies": {
"Z:\\SIIWI01\\": { "alias": "Inmunotek" },
"Z:\\SIIWI02\\": { "alias": "Comercial", "user": "CONTA", "password": "2222", "year": "2025" }
},
"outputDir": "C:\\SiigoMCP\\out",
"norma": "L",
"timeoutMs": 180000
}Precedencia, la misma para las credenciales y para el año: valor de la llamada → variable de entorno → valor de la empresa → valor por defecto (o el año actual).
Consecuencia que conviene tener presente: si define SIIGO_ANO en el entorno del cliente MCP, ese
año manda sobre el campo year de cualquier empresa. Para que una empresa trabaje en otro año,
pase anio en la llamada, o quite SIIGO_ANO del entorno y deje solo los year por empresa.
siigo_doctor avisa cuando detecta esa situación, porque consultar el año contable equivocado no
se nota en la respuesta.
Hasta la 0.2.0 el año de la empresa ganaba a
SIIGO_ANO, al contrario que las credenciales. Si usaba las dos fuentes a la vez, revise qué año va a consultar antes de actualizar a 0.3.0.
outputDir debe ser corto: SIIGO limita la ruta del .xlsx a 50 caracteres. siigo_doctor
calcula el margen que queda y avisa antes de que el CLI empiece a truncar en silencio.
Variable | Para qué |
| Credenciales, como alternativa a guardarlas en el |
| Año de proceso por defecto, 4 dígitos. |
|
|
| Reubica la carpeta de configuración. |
npx -y siigo-pyme-mcp --doctor # informe legible; exit 1 si el veredicto es NO LISTO
npx -y siigo-pyme-mcp --doctor --json # el mismo informe para consumo de máquina
npx -y siigo-pyme-mcp --doctor --sin-empresas # omite el escaneo de discos, más rápidoDiez comprobaciones, todas se ejecutan siempre: plataforma, Node, instalaciones de SIIGO, Excel,
sesión de escritorio, configuración, credenciales, empresas accesibles, carpeta de salida y
procesos de SIIGO o Excel vivos. Cada resultado que no esté en [ ok ] viene con una acción
concreta, y la última línea es siempre el paso que desbloquea.
Nunca ejecuta EXCELSIIGO.exe, no lanza Excel y no escribe ningún archivo. Detecta Excel por el
registro (App Paths, y el ProgID COM como respaldo) y la sesión por el número de sesión del
propio proceso: instanciar Excel para comprobar que existe se colgaría en una máquina sin
escritorio, que es justo el fallo que hay que diagnosticar. La clave nunca aparece en el informe;
hay un test que serializa el informe completo y falla si la encuentra.
La misma información está disponible como herramienta MCP, siigo_doctor, una vez registrado.
Nacen del ejecutable de SIIGO, no del servidor:
La clave es visible en la tabla de procesos. EXCELSIIGO.exe la recibe como argumento
posicional, así que aparece en Get-CimInstance Win32_Process mientras dura la ejecución.
No hay forma de evitarlo desde fuera. El servidor sí la mantiene fuera de logs, mensajes de
error y respuestas MCP.
Una ejecución a la vez. El CLI no tolera instancias simultáneas; el servidor las encola.
Ante un error abre un cuadro de diálogo y espera un clic, sin escribir el log. El servidor vigila el título de la ventana del proceso y, en cuanto reconoce un diálogo de error, cancela la ejecución y devuelve ese título: es el único sitio donde SIIGO explica qué pasó cuando no llega a escribir nada.
Las exportaciones tardan. Un GETTER de mil terceros ronda el minuto; un GETMOV de un
año completo con 25 000 movimientos, algo más de dos. El servidor emite notificaciones de
progreso para que el cliente no aborte la llamada por silencio, y corta a los 180 segundos
por defecto (timeoutMs en la configuración).
No todas las funciones aplican a todas las empresas. Si SIIGO está licenciado sin el
módulo de seriales o el de nómina, esas funciones responden 020 o 105. El servidor lo
distingue de un error corriente y devuelve moduloNoDisponible: true: reintentar no cambia
nada, hay que habilitar el módulo en SIIGO o usar otra función.
Rutas de 50 caracteres. Se aplica al .xlsx de salida y al log. El servidor genera
nombres cortos y avisa antes de invocar si una ruta se pasa.
Requiere Excel y sesión interactiva, por el uso de COM.
exit code 0 no significa éxito. El binario puede fallar (081 Parámetros de la función tienen errores) y salir con 0. El servidor combina tres señales antes de dar por buena una
corrida: código de salida, contenido del log y existencia y tamaño del archivo generado.
Las importaciones dejan su resultado en la carpeta TEMP de la empresa, según documenta
el manual, no en la ruta que se indique.
Si la empresa vive en una unidad de red mapeada y el recurso se cae, Windows deja el mapeo visible pero desconectado. El servidor lo detecta antes de ejecutar y lo dice explícitamente.
npm install
npm run typecheck
npm test # 220 tests, incluidos los dorados contra los ejemplos del manual
npm run build
npm run test:smoke # handshake MCP en los dos perfiles, más --doctor --json
npm run test:e2e # prueba negativa: exige que un fallo se reporte como fallo
npm run test:tools # ejercita LAS 56 herramientas contra una instalación realtest:e2e es el único script que necesita SIIGO instalado; el resto corre en cualquier
máquina, incluida la de CI.
Sin credenciales corre la prueba negativa: usa unas inválidas a propósito y exige que el
servidor reporte el fallo, que es justo lo que el binario no hace por su cuenta. Con
credenciales válidas corre la prueba positiva, que ejecuta un GETTER real y verifica que
el .xlsx exista, pese más de cero y traiga columnas y filas legibles:
SIIGO_USUARIO=TU_USUARIO SIIGO_CLAVE=TU_CLAVE npm run test:e2e # bash
$env:SIIGO_USUARIO='TU_USUARIO'; $env:SIIGO_CLAVE='TU_CLAVE'; npm run test:e2e # PowerShelltest:tools recorre las herramientas del perfil all: invoca las de apoyo, ejecuta de verdad las 29
exportaciones contra la empresa, y prueba las 18 importaciones solo por su ruta de
validación. Las importaciones escriben en la contabilidad y ese script no puede deshacerlo,
así que comprueba el esquema, la resolución de empresa y credenciales y la construcción del
argv, y verifica que rechacen un archivo de entrada inexistente antes de lanzar el ejecutable.
Su argv sí está cubierto al completo por los tests dorados. Para probar una importación de
verdad, use una empresa de pruebas.
El manual de SIIGO (<instalación>\ExcelSIIGO-Ayuda.LOG) trae una línea Ejemplo: por cada
función. src/siigo/args.golden.test.ts reconstruye el argv con esos mismos valores y exige
que coincida token por token. Es la única defensa real contra el error 081, que el binario
reporta en silencio. Si corrige la firma de una función en src/catalog/functions.ts, el test
correspondiente se lo confirmará.
La publicación es automática. No se publica nada a mano.
ci.yml valida cada PR y cada push a main en un runner de Windows: typecheck, tests,
build, smoke y comprobación de que el tarball solo lleva artefactos de distribución.
publish.yml se dispara al empujar un tag v* y, tras repetir la validación completa,
publica a npm con --provenance, publica al MCP Registry oficial autenticando con el OIDC
de GitHub Actions, y crea la GitHub Release con notas generadas.
Para sacar una versión:
npm version patch --no-git-tag-version # o minor / major
# sincronizar server.json a la misma versión (version y packages[].version)
git commit -am "release: v0.1.1"
git push
git tag v0.1.1
git push origin v0.1.1El workflow bloquea la publicación si package.json, el tag y server.json no coinciden:
el MCP Registry rechaza con 422 cuando las versiones difieren, y es mejor fallar antes de
haber subido nada a npm.
Configuración necesaria una sola vez en el repositorio: el secret NPM_TOKEN con un token
de tipo Automation de npm (los tokens Automation omiten el 2FA, que un runner no puede
resolver). El MCP Registry no necesita ningún secret.
MIT. Proyecto independiente, sin relación con Informática y Gestión S.A. (SIIGO).
Agrega manualmente una carpeta de instalacion cuando el autodescubrimiento no la encuentra. Debe contener EXCELSIIGO.exe.
| Name | Required | Description | Default |
|---|---|---|---|
| carpeta | Yes | Carpeta de la instalacion. Ej: D:\Siigo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (readOnlyHint=false, destructiveHint=false). The description adds a useful precondition: 'Debe contener EXCELSIIGO.exe' (must contain EXCELSIIGO.exe). However, it does not disclose what happens if the file is missing, error behavior, or side effects, so transparency is limited beyond the annotation baseline.
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 two sentences, with the action verb first, a clear condition, and a key requirement. No filler words or redundant information.
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 single parameter and no output schema, the description adequately covers the essential purpose, trigger condition, and validation requirement. It could mention the outcome or error handling, but for this simple add operation, it is sufficiently complete.
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%: the 'carpeta' parameter is documented with an example. The description adds the EXCELSIIGO.exe requirement, which is not in the schema, thus enriching parameter semantics and justifying a score above the baseline.
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 function: 'Agrega manualmente una carpeta de instalacion' (manually adds an installation folder). It specifies the verb, resource, and the manual/auto-discovery distinction, which differentiates it from sibling tools like siigo_list_installations.
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 when-to-use context: 'cuando el autodescubrimiento no la encuentra' (when autodiscovery doesn't find it). This clearly implies this is a manual fallback, but it does not name alternative tools or explicitly state when not to use it, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parametros, orden posicional, valores por defecto y ejemplo del manual para una funcion.
| Name | Required | Description | Default |
|---|---|---|---|
| funcion | Yes | Nombre de la funcion. Ej: GETMOV, PUSHTER. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds context about the output content (parameters, order, defaults, example), which is useful given no output schema, but it does not disclose other behavioral details such as error handling or prerequisites.
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 compact noun phrase that conveys the essential content without wasted words. It is appropriately sized, though it lacks a verb and could be slightly more explicit, so it does not earn a perfect 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?
For a simple tool with one parameter, read-only annotation, and no output schema, the description adequately explains what the tool returns. It is missing usage context, but the information provided is sufficient for a straightforward meta-function description 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?
The schema fully describes the single parameter 'funcion' with an example, so coverage is 100%. The tool description does not add any additional parameter-level meaning beyond that, so the baseline score of 3 applies.
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 lists what the tool provides (parameters, positional order, default values, and a manual example), making the purpose clear. The title 'Describir una funcion de ExcelSIIGO' adds the verb and resource, distinguishing it from sibling tools that perform actual operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like siigo_list_functions. The implication is that it is for looking up function details, but there is no direct statement of use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprueba que este equipo pueda ejecutar SIIGO: Windows, instalaciones con EXCELSIIGO.exe, Microsoft Excel, sesion de escritorio activa, configuracion, credenciales, empresas accesibles y margen frente al limite de 50 caracteres en las rutas. No ejecuta EXCELSIIGO.exe ni toca la contabilidad. Ejecutela primero cuando una funcion falle sin una explicacion clara.
| Name | Required | Description | Default |
|---|---|---|---|
| incluirEmpresas | No | Descubrir las empresas, que implica escanear discos y tarda mas. Por defecto si. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating it does not execute EXCELSIIGO.exe or affect accounting. It adds context about the environment components checked (Windows, Excel, desktop session, credentials, companies, path length limits), which goes beyond the structured annotations.
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 two sentences long, front-loads the main purpose, and packs essential information without fluff. Every clause adds value: the list of checks, the explicit non-actions, and the just-in-time usage instruction.
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 moderate complexity and the absence of an output schema, the description is complete enough to guide an agent: it explains what is checked, what is not touched, and when to invoke it. It does not describe the return format, but for a diagnostic tool with one optional parameter this is a minor gap.
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% for the single optional parameter, which already has a clear description ('Descubrir las empresas, que implica escanear discos y tarda mas'). The tool description does not add any further meaning about parameters, but this is unnecessary given the schema fully documents them.
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 specific verb ('Comprueba') and names the resource ('este equipo pueda ejecutar SIIGO') while enumerating the exact checks performed. It also distinguishes itself by explicitly stating what it does NOT do ('No ejecuta EXCELSIIGO.exe ni toca la contabilidad'), setting it apart from sibling tools that run or modify SIIGO.
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 guidance: 'Ejecutela primero cuando una funcion falle sin una explicacion clara.' It also clarifies the tool's safe, non-invasive nature through exclusions, effectively telling the agent when not to worry about side effects and when to choose this diagnostic tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Muestra la configuracion actual. Las claves aparecen enmascaradas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates the read-only nature, but the description adds valuable context beyond this: 'Las claves aparecen enmascaradas' (keys appear masked) discloses a specific behavioral trait—that secrets are not shown in plaintext. This is useful for an agent to set expectations about the response. No contradiction with annotations.
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 two short sentences, with the main action first ('Muestra la configuracion actual') and a key detail second. Every word earns its place; there is no fluff or redundant information.
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 simplicity (no parameters, no output schema, basic read operation), the description provides sufficient context: it names what is shown and the masking behavior. However, it does not describe the structure or format of the configuration returned, which could be helpful but is not critical for a config viewer. The presence of readOnlyHint annotation compensates for some missing context.
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 tool has zero parameters and the schema is empty, so there is nothing to add semantically. Per the rubric, 0 params defaults to a baseline of 4. The description does not need to elaborate on parameters since none exist.
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 function with a specific verb ('Muestra' = shows) and resource ('la configuracion actual' = current configuration). It is distinct from sibling tools, which focus on specific data entities like companies, functions, or financial records, making this the obvious tool for viewing server configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The purpose is self-evident (view config), but there is no explicit statement of context, such as 'use this to inspect current settings before making changes.' This is similar to the MID example (update_drive) which scored 2 for lacking usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Empresas SIIWInn visibles. Para cada instalacion se lee filepath.txt y se exploran las carpetas hermanas SIIWI00..SIIWI99, descartando las que no contienen datos de SIIGO. Indica si cada empresa ya tiene credenciales configuradas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnlyHint=true, and the description adds meaningful procedural details: reading filepath.txt, exploring SIIWI00..SIIWI99 folders, discarding non-SIIGO data, and checking credentials. This goes beyond the structured hint without contradicting it, providing context on what the tool inspects.
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 only two sentences and states the core behavior efficiently. However, the first sentence 'Empresas SIIWInn visibles' is a fragment and slightly cryptic, though the second sentence clarifies the process.
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 explains what the tool does, how it filters installations, and the output concept (credential status). Since there is no output schema, it would benefit from a more explicit output shape, but the simplicity of the tool (no inputs) and the clear process make it sufficiently complete.
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?
With zero parameters, the schema carries no parameter meaning, and the description doesn't need to explain any inputs. The 100% schema coverage and absence of parameters justify the baseline 4 per the rubric.
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 lists visible SIIGO companies ('Empresas SIIWInn visibles') and details the process of reading filepath.txt and scanning SIIWI folders, distinguishing it from list-installation and data-fetching siblings. 'Indica si cada empresa ya tiene credenciales configuradas' specifies the credential-status check, making the purpose concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering SIIGO companies and their credential status, but it does not explicitly state when to choose this over sibling tools like siigo_list_installations or siigo_get_config. Since the context is clear but no alternatives or exclusions are mentioned, it earns a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catalogo de las 47 funciones del CLI, con el nombre de la herramienta MCP equivalente. Use siigo_describe_function para ver los parametros de una en concreto.
| Name | Required | Description | Default |
|---|---|---|---|
| grupo | No | Filtra por grupo. Ej: Inventarios, Contabilidad, Nomina. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as safe/read-only. The description adds context by stating the exact count (47 functions) and that it maps CLI functions to MCP tool names, which is useful beyond the annotation. It does not mention filtering behavior, but the simple nature of the tool and annotation coverage make this adequate.
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 two sentences, front-loaded with the core purpose, and includes a cross-reference to a sibling tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional filter and no output schema, the description adequately conveys what the tool returns (catalog of functions with MCP names) and points to describe_function for deeper detail. It is self-contained for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'grupo', which is documented with examples in the schema. The description adds no extra detail about the parameter, so it relies on the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool lists a catalog of the 47 CLI functions with their equivalent MCP tool names, using a specific verb ('Catalogo') and resource. It distinguishes itself from siblings like siigo_list_companies and explicitly references siigo_describe_function for parameter details.
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 directs users to siigo_describe_function for viewing parameters of a specific function, indicating when to use this tool (to browse the catalog) versus when to use an alternative. This is clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Instalaciones de SIIGO Pyme detectadas en el equipo (carpetas con EXCELSIIGO.exe). Se buscan en el registro de Windows, en la configuracion del servidor y escaneando las unidades.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the exact search sources (Windows registry, server configuration, drive scanning) and detection criterion (folders containing EXCELSIIGO.exe). This adds valuable context about the tool's behavior and what to expect in terms of scope and method.
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 two sentences and immediately front-loads the main purpose. Every sentence contributes: the first defines what the tool returns (installations), the second explains how they are found. No fluff or repetition.
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?
For a zero-parameter, read-only list tool with no output schema, the description is largely sufficient. It explains the object (installations), the detection method, and the search areas. However, it could be slightly more explicit about the returned data format (e.g., folder paths, installation names), which is not specified but is reasonably inferred.
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 tool has zero parameters, so the description does not need to explain any. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the schema coverage is trivially complete. The description adds no parameter-related details because none exist.
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 resource (SIIGO Pyme installations) and the action (detected on the computer), and the title explicitly says 'Listar'. It distinguishes from siblings like siigo_list_companies by specifying it scans for folders with EXCELSIIGO.exe. The verb is slightly implicit in the description ('detectadas') but the title and context make it clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions or prerequisites, relying entirely on the user to infer that it is for listing installations. Given the sibling tools list existing, a brief note on when to choose this over, say, siigo_list_companies or siigo_add_installation would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lee de forma paginada cualquier .xlsx generado por SIIGO. Util para recorrer un resultado grande despues de que una funcion de exportacion devolviera solo la primera pagina.
| Name | Required | Description | Default |
|---|---|---|---|
| hoja | No | Nombre o indice 1-based de la hoja. Por defecto la primera. | |
| ruta | Yes | Ruta completa del archivo .xlsx. | |
| limite | No | Maximo de filas a devolver. Por defecto 50. | |
| offset | No | Fila de datos desde la que empezar, 0-based. Por defecto 0. | |
| filaEncabezado | No | Fila 1-based donde estan los titulos de las columnas. Por defecto se detecta sola: los modelos de SIIGO llevan el nombre de la empresa y del modelo encima de los encabezados. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the pagination behavior and the SIIGO file requirement, which is valuable context beyond the simple read-only hint. It does not detail error handling or return structure, but with annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, then the use case. No fluff or 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 tool's simplicity and the comprehensive schema, the description covers the main use case and the pagination concept well. The absence of an output schema makes a note about return format slightly desirable, but the description is complete enough for an agent 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?
The input schema provides 100% coverage with detailed descriptions for all 5 parameters, so the description does not need to add parameter-level detail. The baseline of 3 applies; the description contributes no additional parameter meaning beyond what the schema already provides.
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 reads any .xlsx generated by SIIGO in a paginated manner ('Lee de forma paginada cualquier .xlsx generado por SIIGO'). This specific verb+resource combination distinguishes it from sibling tools that manage installations or execute functions.
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 usage context: use after an export function returns only the first page of a large result ('despues de que una funcion de exportacion devolviera solo la primera pagina'). It clearly indicates when to use, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ejecuta cualquiera de las 47 funciones de SIIGO Pyme por nombre. Las de exportacion generan un .xlsx y devuelven sus primeras filas; las PUSH* importan y exigen confirmarEscritura=true. Llame antes a siigo_describe_function: un parametro mal formateado hace que el CLI responda 081 y termine con codigo 0, asi que el error se parece a un exito.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | Anio de proceso en SIIGO, 4 digitos. Por defecto el anio configurado para la empresa o el actual. | |
| clave | No | Clave del usuario, hasta 8 caracteres. Por defecto la configurada. Nunca se devuelve en las respuestas. | |
| norma | No | Norma de la que se extrae la informacion: L = local (PUC colombiano), N = NIIF. Por defecto L. | |
| params | No | Parametros propios de la funcion, por nombre. Consulte siigo_describe_function para saber cuales lleva y en que formato: el CLI acepta un valor mal formateado, lo reporta como codigo 081 y aun asi termina con codigo 0. | |
| empresa | Yes | Empresa sobre la que ejecutar. Acepta la ruta completa (Z:\SIIWI01\), solo el numero (01) o un alias configurado. Use siigo_list_companies para ver las disponibles. | |
| funcion | Yes | Nombre de la funcion de ExcelSIIGO. Ej: GETMOV, GETTER, PUSHTER. Use siigo_list_functions para verlas. | |
| usuario | No | Usuario de SIIGO, hasta 8 caracteres. Por defecto el configurado para la empresa. | |
| instalacion | No | Carpeta de la instalacion de SIIGO a usar (por ejemplo C:\Siigo2). Por defecto la asociada a la empresa. | |
| filasPreview | No | Cuantas filas del xlsx generado incluir en la respuesta. Por defecto 50; use 0 para no leer el archivo. | |
| confirmarEscritura | No | Obligatorio en true para las funciones PUSH*, que ESCRIBEN en la contabilidad de la empresa. Confirme con el usuario antes de enviarlo: el servidor no puede deshacer una importacion. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that export functions generate an .xlsx and return its first rows, while PUSH* functions import and require confirmation. It also warns that a malformed parameter causes the CLI to return code 081 and still exit with code 0, making errors look like successes. This goes well beyond the annotations, which only indicate destructiveness.
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, using three sentences to convey the core action, behavior differences, and a critical error-handling tip. The warning about the 081 code is front-loaded and every clause carries meaning, so it earns a high score.
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?
For a tool with 10 parameters and no output schema, the description covers the essential context: what the tool does, the difference between export and import functions, and the critical error mode. It doesn't detail the exact return structure, but it mentions that export functions return the first rows, which is the key behavior. The reference to describe_function fills the gap for parameter specifics.
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 schema provides detailed descriptions for all 10 parameters, so the baseline is 3. The description adds value by warning about malformed parameters and referencing siigo_describe_function for parameter formats, which helps with the nested 'params' object. It also highlights that confirmarEscritura is mandatory for PUSH*, reinforcing 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 states the tool executes any of the 47 SIIGO Pyme functions by name, specifying export vs import behaviors. It distinguishes from siblings like siigo_describe_function (which describes functions) and siigo_read_xlsx (which reads files). The verb 'Ejecuta' and resource 'funciones de SIIGO Pyme' make the purpose specific.
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?
It tells the user to call siigo_describe_function first to understand the required parameters, which is an explicit usage prerequisite. It also clarifies that PUSH* functions require confirmarEscritura=true, guiding correct operation. However, it doesn't explicitly state when to use sibling tools instead (e.g., siigo_list_functions), so it's clear but not fully exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Da un nombre legible a una empresa para poder referirse a ella por nombre en vez de por ruta.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | Nombre legible. Ej: Inmunotek. | |
| empresa | Yes | Ruta de la empresa. Ej: Z:\SIIWI01\ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (readOnlyHint: false, destructiveHint: false) already indicate this is a non-read-only, non-destructive operation. The description adds modest context by explaining that the tool assigns a readable name, but it does not disclose additional behavioral traits such as persistence, overwrite behavior, or permissions. With annotations covering the safety profile, a score of 3 is appropriate.
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, concise sentence that is front-loaded with the action and resource. Every word contributes to meaning, with no redundancy or filler.
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 simplicity (2 required parameters, no output schema, no nested objects) and the presence of annotations and full schema coverage, the description is sufficiently complete. It provides the core purpose and the schema handles parameter details, making it adequate for an agent to select and invoke the tool 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?
The input schema has 100% coverage: both 'empresa' and 'alias' have descriptive examples ('Ruta de la empresa' and 'Nombre legible'). The description adds a little context by explaining the rationale (refer by name instead of path), but it does not add parameter-level details beyond the schema. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Da' (gives) and the resource 'un nombre legible a una empresa' (a readable name to a company), making the purpose specific. It also explains the benefit of referring to a company by name instead of path. However, it does not explicitly distinguish this tool from sibling tools, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: you use this tool when you want a readable alias for a company. It does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. This is implied usage rather than explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guarda usuario y clave en la configuracion del servidor. Sin "empresa" se guarda como credencial por defecto para todas las empresas, que es lo mas comodo si se usa el mismo usuario en todas. Con "empresa" se guarda solo para esa. La clave nunca se devuelve en ninguna respuesta.
| Name | Required | Description | Default |
|---|---|---|---|
| clave | Yes | Clave del usuario, hasta 8 caracteres. | |
| empresa | No | Ruta de la empresa para la que aplica. Omitir para guardar la credencial por defecto. | |
| usuario | Yes | Usuario de SIIGO, hasta 8 caracteres. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a valuable security guarantee that the password is never returned in any response, which goes beyond the minimal annotations. It also clarifies the scoping behavior for default vs. company-specific credentials. However, it does not mention whether existing credentials are overwritten.
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 three sentences long, front-loaded with the main action, and every sentence provides useful context. There is 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?
For a simple credential-setting tool, the description covers the core purpose, scoping options, and an important security property. It could mention whether it overwrites existing credentials or returns confirmation, but these are minor omissions for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for all parameters, including the default behavior for 'empresa'. The description mainly rephrases this and adds a convenience note, offering marginal additional meaning 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 states the tool saves a user and password in the server configuration using a specific verb and resource. It also distinguishes between the default and company-specific scenarios, making the tool's behavior clear and distinct from siblings.
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 explains when to omit or include the 'empresa' parameter, providing clear usage context for both default and per-company credential saving. It does not explicitly name alternatives, but the tool's unique purpose among siblings makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el protocolo de uso de este servidor: por donde empezar, la trampa que produce datos equivocados y que funciones no se pueden deshacer. Llamela antes de cualquier otra herramienta siigo_* en esta conversacion. Es necesaria porque varios clientes MCP descartan las instrucciones que el servidor manda al conectar, y esta herramienta es el unico canal que llega siempre.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with these. It adds useful behavioral context beyond the annotations: the tool reveals a 'trampa' that produces wrong data and which functions cannot be undone, and asserts it is the 'unico canal que llega siempre'. This provides meaningful transparency about its role and reliability.
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 compact: three sentences that state the return value, the usage rule, and the rationale. It is front-loaded with the main function and every sentence adds value. No fluff or repetition.
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 no parameters, a simple read-only annotation, and no output schema, the description covers all necessary context for an agent to use this tool correctly. It explains what it returns, when to call it, and why it exists, making it complete for its onboarding purpose.
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 tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to add parameter semantics, and it correctly focuses on what the tool returns rather than on inputs.
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 function: 'Devuelve el protocolo de uso de este servidor' (returns the usage protocol for this server). It specifies the content of the protocol (starting point, the trap that causes wrong data, and irreversible functions) and distinguishes itself from sibling tools by being a mandatory first step before all other siigo_* tools.
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 explicit usage instruction: 'Llamela antes de cualquier otra herramienta siigo_* en esta conversacion' (call it before any other siigo_* tool). It also explains why this is necessary, because MCP clients may discard server-sent instructions, making this tool the only reliable channel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or action: installation discovery, company listing, function catalog vs. execution, credential management, aliases, config, and file reading. There is no functional overlap; even similar-sounding tools like list_functions, describe_function, and run_function are clearly separated by purpose.
All tools share the 'siigo_' prefix and mostly follow a verb_noun pattern (list_installations, set_credentials, read_xlsx). Two exceptions, 'start_here' and 'doctor', break the verb_noun convention, but they are still intuitively named and the overall pattern is highly consistent.
With 12 tools, the server is well-scoped for its purpose of managing SIIGO Pyme installations and executing CLI functions. Each tool has a clear role, and the count comfortably fits within the ideal 3-15 range without feeling excessive or sparse.
The tool set covers the full workflow: discovery (list_installations, add_installation), diagnostics (doctor), configuration (set_credentials, set_company_alias, get_config), function access (list_functions, describe_function, run_function), and output handling (read_xlsx). The mandatory start_here tool ensures agents follow the correct protocol, leaving no obvious dead ends for core operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/javalenciacai/siigo-pyme-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
