Skip to main content
Glama
edpauce

ISO Agents

by edpauce
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

4.4 · Mapa de procesos y sus interacciones

contexto_mapa_procesos_4_4

Generates ISO clause 4.4 process maps covering strategic, operational and support processes with SIPOC, indicators and owners; creates or updates using house or client formats.

Instructions

Genera el Mapa de Procesos del requisito 4.4 (procesos estratégicos/operativos/apoyo con enfoque SIPOC: proveedores, entradas, salidas, clientes, indicadores y responsable). Admite documento del cliente, modo generar|actualizar y formato casa|cliente.

Input Schema

NameRequiredDescriptionDefault
modoNogenerar = crear de cero con la metodología casa (default). actualizar = partir del documento del cliente, conservar lo correcto y actualizarlo/reforzarlo a la versión vigente de la norma. 'actualizar' requiere un documento.
nombreYesRazón social o nombre de la empresa.
normasNoNormas ISO objetivo del sistema de gestión. Por defecto ISO 9001. Usa 37001 para sistemas de gestión antisoborno (SGAS).
sectorYesSector / rubro económico (ej. 'Distribución de energía eléctrica').
tamanoNoTamaño o nº de trabajadores (texto libre, admite rangos: '51-200').
formatoNocasa = plantilla estándar de la casa (default). cliente = replicar la estructura, columnas, escala y metodología del documento del cliente. 'cliente' requiere un documento.
materialNoMaterial fuente OPCIONAL: texto extraído de documentos reales del cliente (políticas, actas, informes) para fundamentar la generación (grounding).
procesosNoProcesos principales de la organización.
ubicacionNoPaís / región de operación. Por defecto se asume Perú (marco legal peruano).
salidaPathNoCarpeta o ruta de archivo .docx donde escribir la salida. Por defecto: carpeta 'salidas/' del proyecto.
exportarDocxNoSi es true, además del Markdown genera un archivo Word (.docx) con formato casa (tablas y colores) y devuelve su ruta para abrirlo en Word.
plantillaPathNoRuta a una PLANTILLA .docx del cliente con marcadores docxtemplater ({campo}, {#bucle}…{/bucle}). Si se da, rellena esa plantilla conservando su formato visual EXACTO (colores, bordes, logo) y devuelve la ruta del .docx generado.
documentoClienteNoTexto del documento VIGENTE del cliente (matriz previa, política, acta, FODA anterior). Base para grounding, actualización o para replicar su formato.
productosServiciosNoProductos y servicios principales de la organización.
documentoClientePathNoRuta local a un documento del cliente (.docx/.txt/.md) que el servidor leerá y usará como base. Alternativa a documentoCliente.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden and does state the deliverable's content (SIPOC sections). However it says nothing about side effects such as writing files to salidaPath, the default Markdown output, the docx/plantilla variants, or permission/grounding behavior; those facts exist only in the parameter descriptions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences, front-loaded with the artifact and requirement ID, with the capability list second. No filler or repetition.

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

Completeness3/5

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

For a 15-parameter generation tool with no annotations and no output schema, the description omits the default output format (Markdown), that exports produce file paths to open in Word, and how documentoCliente vs documentoClientePath vs plantillaPath interact. Much of this is rescued by the rich schema, but the description alone is only minimally sufficient.

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

Parameters3/5

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

Schema description coverage is 100% and the parameter docs are detailed (enum meanings, defaults, alternatives between documentoCliente and documentoClientePath). The description merely restates the modo and formato enums and adds no format, precedence, or interaction guidance beyond the schema.

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

Purpose4/5

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

States a concrete verb and resource ('Genera el Mapa de Procesos') and pins it to ISO requirement 4.4, which is what separates it from the sibling 4.1/4.2/4.3 tools. The SIPOC field list adds specificity about what the artifact contains, though it doesn't explicitly name the siblings it replaces.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence enumerates the supported options (client document, modo generar|actualizar, formato casa|cliente) but never states when an agent should pick one over the other or when not to call it. The conditions ('requiere un documento') live only in the schema, leaving usage rules implicit here.

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

Deploy Server

Other Tools