Skip to main content
Glama
edpauce

ISO Agents

by edpauce
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

4.2 · Matriz de partes interesadas

contexto_partes_interesadas_4_2

Generate an ISO clause 4.2 stakeholder matrix with needs, expectations, requirements and Peruvian legal tagging, built from client documents in house or client format.

Instructions

Genera la Matriz de Partes Interesadas del requisito 4.2 (necesidades, expectativas y requisitos pertinentes al SIG), con marca de requisito legal según el marco peruano. 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 burden. It discloses the generar/actualizar and casa/cliente behaviors and the legal-requirement marking, but never states that the tool writes output files or generates a .docx, nor any prerequisites beyond the modes. Moderate transparency gap for a mutating generator.

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

Conciseness4/5

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

Two front-loaded sentences with no waste; the resource and clause are stated first, then the supported modes. Efficient and readable, if a bit terse given the tool's complexity.

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 document-generation tool with no annotations and no output schema, the description is thin on the mutating behavior and output artifacts (files, .docx, template paths). The rich schema compensates for parameter details, but the overall narrative is not fully complete.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents all 15 parameters with enums and defaults. The description reinforces the key selector parameters (modo, formato, documento del cliente), adding slight context over the schema baseline of 3.

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 specific verb ('Genera') and resource ('Matriz de Partes Interesadas del requisito 4.2'), and clarifies the SIG clause. The clause number and resource name distinguish it from siblings like contexto_foda_4_1, though it never explicitly references alternatives.

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?

Mentions the supported options (documento del cliente, modo generar|actualizar, formato casa|cliente) but only implies when to choose each. There is no explicit when-to-use vs when-not guidance or routing to sibling tools, so usage must be inferred.

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