Click on "Deploy 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., "@ordis-mcp-server What were my KPIs in July 2026?"
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 de solo lectura para la API contable de Ordis SpA. Expone cada
endpoint de https://ordis.cl/api/v1 como una tool tipada, para consultar la
contabilidad de forma nativa desde Claude (Claude Code / Claude Desktop) sin
adivinar rutas.
El servidor no guarda el token: lo lee de la variable de entorno
ORDIS_API_KEY y actúa solo como cliente HTTP. Autentica únicamente por header
Authorization: Bearer.
Node.js 18 o superior (usa fetch nativo).
Un token de la API de Ordis (ordis_sk_...). Se genera en el portal:
ordis.cl → Acceso API a tus datos (/portal/api-keys) → Crear llave.
Se muestra una sola vez — guárdala como variable de entorno, nunca en un
archivo versionado.
Related MCP server: Pacioli
npm install
npm run buildGenera dist/index.js (el ejecutable del servidor).
ORDIS_API_KEY="ordis_sk_..." npx @modelcontextprotocol/inspector node dist/index.jsAbre la UI del Inspector, lista las 11 tools y prueba una llamada (ej.
ordis_get_kpis con periodo: "2026-07").
claude mcp add ordis \
--env ORDIS_API_KEY=ordis_sk_TU_TOKEN \
-- node /ruta/absoluta/ordis-mcp-server/dist/index.jsEn el archivo de config de MCP:
{
"mcpServers": {
"ordis": {
"command": "node",
"args": ["/ruta/absoluta/ordis-mcp-server/dist/index.js"],
"env": {
"ORDIS_API_KEY": "ordis_sk_TU_TOKEN"
}
}
}
}Usa la ruta absoluta a
dist/index.js. Reinicia el cliente para que detecte el servidor.
Variable | Requerida | Descripción |
| Sí | Token de solo lectura ( |
| No | Sobrescribe el base URL. Default: |
Tool | Endpoint | Parámetros |
|
| — |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
periodo valida el formato YYYY-MM en el cliente (falla rápido sin gastar
una llamada de red).
anio valida el rango 2020–2027.
page debe ser ≥ 1.
Enums validados en el cliente (mismos valores que la API): tipo =
emitida | recibida · estado de boletas = vigente | anulada | rechazada
· estado de deudas = activo | pagado | cancelado · estado de
trabajadores = activo | licencia | vacaciones | desvinculado.
En los endpoints con tope de filas (deudas, trabajadores), si la
respuesta trae meta.has_more: true hay más datos que los devueltos.
ordis-mcp-server/
├── package.json
├── tsconfig.json
├── README.md
└── src/
├── index.ts # arranque + transporte stdio
├── client.ts # cliente HTTP: auth por header, timeout, errores accionables
├── tools.ts # registro de las 11 tools
├── schemas.ts # campos Zod reutilizables (periodo, anio, page, estado)
└── constants.ts # base URL, timeout, límite de caracteresEste servidor usa el SDK v1 (@modelcontextprotocol/sdk), que es la línea
compatible y probada con la config stdio actual de Claude Code / Desktop.
Existe una línea v2 (@modelcontextprotocol/server, spec 2026-07-28) con
paquetes renombrados y zod/v4. Cuando v2 se estabilice en los hosts, la
migración es acotada: cambiar los imports, pasar inputSchema como z.object({...})
en vez de shape plano, y actualizar el transporte. La lógica de negocio
(client.ts, mapeo de params) no cambia.
Solo lectura: no hay tools que escriban, borren ni muten datos (la API de Ordis tampoco tiene endpoints de escritura).
El token vive solo en la variable de entorno; nunca se loguea ni se persiste.
En stdio, stdout es el canal del protocolo MCP: todos los logs van a stderr.
Puedes revocar el token cuando quieras desde ordis.cl/portal/api-keys; el
corte es inmediato. Rota el token si sospechas que se expuso.
Al reportar un issue en este repositorio, no pegues respuestas de la API (contienen datos de tu empresa). Describe el error y el endpoint; con eso alcanza.
Devuelve razón social, RUT, plan contable y el catálogo de endpoints disponibles. Útil como punto de partida para descubrir qué se puede consultar.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the specific data returned (razón social, RUT, plan contable, endpoint catalog) beyond the annotations, providing useful behavioral context without contradiction.
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 short sentences: the first states what is returned, the second states its purpose. The information is front-loaded and every word earns its place.
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 params, no output schema, read-only annotations), the description fully covers its purpose and output. It also mentions the endpoint catalog, which is essential for understanding the broader context of the sibling tools.
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 schema is trivially complete. Per rubric, 0 params earns a baseline of 4. The description correctly avoids discussing parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Devuelve' (returns) and the resource (company data: razón social, RUT, plan contable) plus the endpoint catalog. This distinguishes it from sibling tools that focus on specific financial records, making it the discovery entry point.
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 explicitly says 'Útil como punto de partida para descubrir qué se puede consultar', which gives clear context for when to use it (initial exploration). It does not explicitly rule out other tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Formulario 22 anual de renta: resultado a pagar o devolución por año tributario.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | Año (2020–2027). Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds 'resultado a pagar o devolución' which hints at the return value, but does not disclose any further behavioral traits such as default year behavior, response structure, or limitations. It adds little beyond 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 a single, focused sentence with no redundant wording. It is front-loaded with the tool's core purpose and outcome, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional parameter, read-only annotations), but there is no output schema to clarify return values. The description vaguely mentions 'resultado a pagar o devolución' but omits specifics like whether the result is a numeric value, a breakdown, or a PDF, and does not address sibling differentiation. It is adequate for basic invocation but has clear gaps.
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% and the only parameter 'anio' is clearly described with range and default behavior. The description does not add any parameter-specific meaning, but the schema does the heavy lifting, so a baseline score of 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 specifies the resource 'Formulario 22' and the output 'resultado a pagar o devolución' (amount to pay or refund). It distinguishes from sibling F29 by name and tax form type, though it lacks an explicit action verb like 'retrieve' or 'get'.
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. With siblings like ordis_get_f29 (another tax form) and ordis_get_empresa, the description should clarify that F22 is for annual income tax returns, but it does not, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Formulario 29 mensual: IVA (débito/crédito), PPM, retenciones y total a pagar. Sin período devuelve los últimos 12.
| Name | Required | Description | Default |
|---|---|---|---|
| periodo | No | Período contable YYYY-MM. Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent, so the description's added value lies in disclosing the 'last 12' default and the specific data fields returned. This goes beyond the structured metadata without contradicting it.
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, well-structured sentence that front-loads the key information and provides both scope and default behavior without extraneous 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?
With no output schema, the description conveys the essential data content (IVA, PPM, retentions, total) and the default period behavior. It doesn't cover error handling or response structure, but for a simple read-only tool with one optional parameter, it is reasonably 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?
The schema covers the 'periodo' parameter with format and default mention, but the description clarifies that omitting it returns the last 12 months. This fills in the exact default behavior, adding meaning beyond the schema's generic 'valor por defecto.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the monthly Form 29, listing its key components (IVA, PPM, withholdings, total payable) and explicitly stating the default behavior when no period is given. This distinguishes it from sibling tools like ordis_get_f22 by its specific form number and content.
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 clear context: it is for monthly F29 tax returns with IVA detail. It doesn't name alternatives explicitly, but the default period behavior is a useful 'when' condition for omitting the parameter. No exclusions are stated, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flujo de caja del año mes a mes: ingresos, egresos, impuestos y financiamiento.
| Name | Required | Description | Default |
|---|---|---|---|
| anio | No | Año (2020–2027). Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, idempotent, non-destructive operation. The description adds value by disclosing the content structure (month-by-month and categories like income, expenses, taxes, financing), which goes beyond the annotations. No contradictions exist.
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?
A single, concise sentence with no filler or redundancy. It front-loads the main purpose ('flujo de caja') and then clarifies the granularity and 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?
With no output schema, the description partially compensates by explaining the return structure (monthly, with income/expenses/taxes/financing). It does not mention default year behavior or exact response format, but the schema covers the year parameter, making the description sufficient for a simple 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 description covers 100% of the single parameter 'anio' with a clear description and range. Since the tool description does not add further parameter semantics, it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides annual cash flow broken down month by month, specifying the categories (income, expenses, taxes, financing). The verb 'get' in the name and 'flujo de caja' identify a distinct resource, setting it apart from sibling tools focused on invoices, tax forms, or KPIs.
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 clear context that this tool is for retrieving annual cash flow data, and the sibling tool names suggest alternative financial queries. However, it does not explicitly state when to use this tool over others or mention exclusions, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Indicadores del período: ventas, gastos, impuestos del F29 y resultado, con su desglose y una explicación en texto. Sin período usa el mes en curso.
| Name | Required | Description | Default |
|---|---|---|---|
| periodo | No | Período contable YYYY-MM. Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare safe read-only/idempotent behavior. The description adds value by specifying default period (current month) and output composition (breakdown + text explanation), which aren't in the 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?
Two concise sentences, front-loaded with the main content and a necessary default-period caveat.
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?
No output schema exists, so the description carries the burden of explaining returns. It mentions breakdown and explanation but doesn't specify the structure, units, or edge cases (e.g., empty months). It's adequate for a simple KPI tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the 'periodo' parameter, but the description clarifies the default value ('mes en curso'), which the schema only vaguely references as 'su valor por defecto'. This adds meaningful context.
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 explicitly names the KPIs (ventas, gastos, impuestos F29, resultado) and states the output includes breakdown and text explanation. It distinguishes from siblings by being an aggregate indicator tool rather than a specific report, though it lacks an explicit verb.
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 implies the tool is for period KPIs, but does not name alternatives or state when to use it over sibling tools like ordis_get_f29 or ordis_get_f22. The default-period note is behavioral guidance, not usage comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Boletas de honorarios con retención y estado (incluye anuladas, identificadas como tales). Paginado.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Número de página (empieza en 1) para resultados paginados. | |
| estado | No | Filtra por estado de la boleta: 'vigente', 'anulada' o 'rechazada'. Si se omite, devuelve todas. | |
| periodo | No | Período contable YYYY-MM. Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds that boletas include retention, status, and that voided ones are included and flagged, plus pagination. This provides useful behavioral detail beyond the 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?
One concise sentence with no filler. It states the core resource and key distinguishing features.
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 read-only annotations and fully documented schema, the description covers the essential aspects: resource type, included data, pagination. It doesn't describe return structure, but for a list tool without output schema, this is adequate.
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 full descriptions for all three parameters, so the description does not need to add parameter details. The description's mention of 'paginado' aligns with the page parameter but doesn't add new information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (boletas de honorarios) and includes relevant attributes (retención, estado, inclusion of anuladas), distinguishing it from sibling tools like facturas or liquidaciones. The verb 'list' is implied by the tool name.
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 usage guidance or alternatives are mentioned. The tool's name and resource type make its purpose obvious, but it does not state when to prefer it over sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deudas y compromisos (créditos, leasing, tarjetas) y cuentas por cobrar, con cuotas pendientes. La dirección la define 'naturaleza' (pasivo = debes / activo = te deben).
| Name | Required | Description | Default |
|---|---|---|---|
| estado | No | Filtra por estado de la deuda: 'activo' (vigente), 'pagado' o 'cancelado'. Si se omite, devuelve todas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by explaining the behavioral semantics of the 'naturaleza' field (pasivo = debes / activo = te deben) and the 'cuotas pendientes' detail. 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, front-loaded with the core resource and no filler. Every phrase adds meaning, including the nature direction explanation.
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 read-only list tool with one optional filter and rich annotations, the description supplies key domain context: types of debts, pending installments, and the nature semantics. Without an output schema, it doesn't enumerate return fields, but the low complexity and annotations make this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with a well-described estado parameter that has an enum and default behavior. The description adds no parameter-level information, so the schema carries the burden; 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 identifies the resource: 'Deudas y compromisos (créditos, leasing, tarjetas) y cuentas por cobrar' and adds specificity with 'con cuotas pendientes'. It distinguishes from siblings like list_facturas (invoices) and list_movimientos_banco (bank movements) by domain, and explains the nature field direction.
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 usage for debt and receivables queries but does not provide explicit when-to-use or alternatives. There is no exclusion like 'use list_facturas for invoices instead', so it lacks clear guidance for choosing among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista documentos tributarios emitidos y recibidos, con folio, contraparte y montos. Paginado. Filtra por período (YYYY-MM) y tipo.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Número de página (empieza en 1) para resultados paginados. | |
| tipo | No | Filtra por dirección: 'emitida' (ventas) o 'recibida' (compras). Si se omite, devuelve ambas. | |
| periodo | No | Período contable YYYY-MM. Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral details like pagination and filtering options, but does not disclose additional traits such as authentication, rate limits, or default values. This is adequate given the strong annotation coverage.
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 concise sentences, front-loaded with the core purpose, and includes necessary details without any filler or redundancy. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params, no output schema), the description covers the essential aspects: what is listed, key result fields, pagination, and available filters. Minor details like default page size or sort order are omitted, but the description is sufficiently complete for an agent to understand the tool's role.
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%, so all three parameters (page, tipo, periodo) are fully described in the schema. The description merely reiterates the filter options without adding new semantic detail, matching the baseline for schema-heavy tools.
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 explicitly states 'Lista documentos tributarios emitidos y recibidos' (lists issued and received tax documents) with specific fields (folio, contraparte, montos). It clearly differentiates from sibling tools that target other resources like liquidaciones, trabajadores, or deudas.
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 clear context: it is used to list invoices (facturas), with pagination and filters by period and type. It does not explicitly mention alternatives or exclusions, but the resource scope is obvious from the name and description, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liquidaciones de sueldo aprobadas. Sin período devuelve los últimos 3 meses con liquidaciones.
| Name | Required | Description | Default |
|---|---|---|---|
| periodo | No | Período contable YYYY-MM. Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds useful behavioral context: the 'aprobadas' filter and the default period behavior when 'periodo' is omitted. It does not disclose return format or other details, 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 concise sentences with no fluff. The first sentence states the core function, and the second provides the key default behavior. Information is front-loaded and every word earns its place.
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 tool is simple (one optional parameter) and has strong annotations, so the description is nearly complete for invocation. It covers purpose and the main behavioral default. It does not describe the return structure, but with no output schema that is a minor gap for a simple list tool; overall 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?
The schema describes 'periodo' as YYYY-MM and notes it uses a default value if omitted, yielding 100% coverage. The description adds specific meaning by stating the default is 'the last 3 months with settlements', which goes beyond the schema's generic 'default value' mention. This additional clarification elevates the parameter semantics beyond the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing approved salary settlements ('Liquidaciones de sueldo aprobadas'), matching the tool name and title. It distinguishes from siblings like 'list_facturas' and 'list_deudas' by the specific resource (liquidaciones) and the 'aprobadas' qualifier. The default-period behavior adds an additional distinctive detail.
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 clear context that omitting 'periodo' returns the last 3 months with settlements, which guides usage for default behavior. However, it does not explicitly state when to prefer this tool over siblings or provide exclusions, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Movimientos de las cartolas bancarias cargadas, con categoría y estado de conciliación. Paginado.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Número de página (empieza en 1) para resultados paginados. | |
| periodo | No | Período contable YYYY-MM. Si se omite, la API usa su valor por defecto. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond these: results are paginated ('Paginado') and include specific fields (category, reconciliation status). It also notes the source is previously loaded bank statements, which clarifies data provenance. 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, no filler. It front-loads the core purpose (bank movements) and adds high-value specifics (category, reconciliation status, pagination). Every word earns its place.
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 optional params, no output schema, no nested objects), the description covers the essential return contents and pagination behavior. It could be considered complete enough for an agent to select and invoke the tool correctly, especially with rich annotations and full schema coverage.
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%: both `page` and `periodo` have descriptions in the schema. The main description adds minimal param-related semantics beyond the word 'Paginado', which is already reflected in the `page` schema. With complete schema coverage and no enums or required params, the baseline of 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 the tool lists bank movements from loaded bank statements, including category and reconciliation status. This distinguishes it from sibling tools like list_facturas or get_f29, as it specifically targets bank cartolas. The verb is implied by 'Movimientos de' and reinforced by the tool name, making the purpose unambiguous.
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 no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where other sibling tools (e.g., list_facturas, get_flujo_caja) would be more appropriate. The intended use is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nómina completa con el estado de cada trabajador (activo, licencia, vacaciones, desvinculado).
| Name | Required | Description | Default |
|---|---|---|---|
| estado | No | Filtra por estado del trabajador. Si se omite, devuelve todos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the listing of statuses, which is useful return-content context, but does not disclose behaviors like ordering or pagination. 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 a single, front-loaded sentence that conveys the essential information with zero wasted words. It is an excellent example of concise, structured description.
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 parameter, good annotations, and no output schema, the description provides sufficient context by noting the complete payroll and statuses. It could benefit from mentioning what fields are returned, but overall it is adequate for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'estado' is fully documented with an enum and description. The description repeats the statuses but adds no additional parameter semantics beyond what the schema provides, so the baseline of 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 'Nómina completa con el estado de cada trabajador' clearly identifies the resource (trabajadores) and the scope (complete payroll with statuses). The verb is implicit rather than explicit ('list' is implied by 'Nómina'), and it distinguishes from sibling tools by focusing on workers rather than facturas or liquidaciones.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternatives. However, the resource (trabajadores) is clear, so usage context is implied rather than expressly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0ordis_get_empresaordis_get_f22ordis_get_f29ordis_get_flujo_cajaordis_get_kpisordis_list_boletas_honorariosordis_list_deudasordis_list_facturasordis_list_liquidacionesordis_list_movimientos_bancoordis_list_trabajadoresScored across 11 tools
Each tool targets a distinct financial entity or document type (e.g., invoices, tax forms F29/F22, payroll, debts, bank movements). The only slight overlap is between ' get_f29' and 'get_kpis' (which summarizes F29 data), but their purposes differ clearly.
All tools follow a consistent 'ordis_get_' or 'ordis_list_' prefix followed by a noun, using snake_case throughout. There is no mixing of conventions or vague verbs.
With 11 tools covering a broad financial domain, the count is well within the ideal range and each tool addresses a specific data source.
The server provides read-only access to a comprehensive set of Chilean tax and accounting data, including monthly and annual tax forms, invoices, payroll, cash flow, and KPIs. Minor gaps exist, such as no detail endpoints for individual invoices or payroll documents, but the core data needed for financial analysis is present.
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
MCP server for Quaderno — tax-rate calculation, invoices, contacts, products, receipts & expenses.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Headless API-first double-entry accounting & bookkeeping engine. 84 MCP tools over HTTP.
