Loading ToolBench
Conecta Claude con la API REST de Piriod.com. Autenticación por URL única: /mcp/{code} -> credenciales en Supabase. Fallback local: variables de entorno PIRIOD_TOKEN y PIRIOD_ORG.
Piriod MCP has 26 tools with consistent naming (verb_noun pattern) and basic schemas. All tools have descriptions and input parameters are typed via Zod. However, descriptions are often generic or reference external docs ('ver docs de Piriod'), parameter descriptions lack actionable constraints (enums, ranges, formats), and output schemas are not documented. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. The server accepts a generic 'body' object for create/update operations, which defeats schema validation and forces LLMs to guess valid fields. No pagination limits documented despite list tools returning potentially large result sets.
Crea un contacto.
Crea un cliente. Campos requeridos: name, address, country (ID), state (ID). Opcionales: currency, email, phone, tax_id, zip_code, reference, send_invoices, metadata.
Crea una unidad organizacional.
Snapshot del estado del cliente (suscripciones, deuda, etc).
Elimina un contacto.
Elimina un cliente (soft-archive si tiene actividad).
Generic 'body' parameter defeats schema validation. Tools create_contact, update_contact, create_org_unit, update_org_unit accept z.record(z.string(), z.any()) with only a reference to external docs. LLMs cannot infer required fields, valid enums, or constraints. This violates pattern:constrained-input and forces agents to guess or make extra discovery calls.
No output schemas documented. Tools return JSON via json() helper but LLMs cannot see what fields to expect. This breaks pattern:tool and prevents downstream tool chaining. E.g., list_customers returns results but no schema shows whether 'id' is 'cus_xxx' or 'customer_id', forcing LLMs to guess field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Elimina una unidad organizacional.
Busca clientes por nombre o email (alias de list_customers con search).
Lista contactos.
Lista los países disponibles.
Lista las monedas soportadas (CLP, USD, etc).
Lista clientes con filtros.
Lista los tipos de referencia de documento.
Lista los tipos de documento disponibles (boleta, factura, etc). Devuelve el ID que se usa en create_invoice.
Lista tipos de cambio entre monedas.
Lista las frecuencias de facturación (mensual, anual, etc).
Lista los bancos del directorio (no las cuentas conectadas).
Lista facturas con filtros.
Lista unidades organizacionales.
Lista estados / provincias.
Obtiene un contacto.
Obtiene un cliente por ID.
Obtiene una unidad organizacional.
Actualiza un contacto.
Actualiza parcialmente un cliente.
Actualiza una unidad organizacional.
List tools lack pagination limits and result count guidance. No mention of max results, default limit, or how to handle large datasets. list_customers, list_contacts, list_org_units, list_invoices could return hundreds of items, exhausting context. Violates pattern:paginated-result.
Descriptions reference external docs instead of being self-contained. E.g., 'Objeto con los campos del recurso (ver docs de Piriod)' forces LLMs to infer field names and constraints. Violates pattern:tool-description, descriptions must be actionable without external lookups.
No error handling or recovery guidance. Tools do not document what errors are retryable, what user actions are needed, or how to recover from failures. E.g., delete_customer says 'soft-archive if has activity' but does not explain what happens if the operation fails or what the LLM should do next. Violates pattern:recovery-guide.