Skip to main content
Glama
edpauce

ISO Agents

by edpauce
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

4.1 · Análisis FODA (con FODA cruzado)

contexto_foda_4_1

Generates a sector-specific SWOT for ISO clause 4.1 plus a crossed TOWS strategy matrix (FO/FA/DO/DA), grounded on client documents and exportable as a formatted .docx.

Instructions

Genera el Análisis FODA (SWOT) del requisito 4.1 y la matriz cruzada de estrategias (FO/FA/DO/DA · TOWS), específico al sector y a las normas objetivo. Admite documento del cliente (documentoCliente/documentoClientePath), 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.6/5.0
Behavior3/5

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

No annotations, so the description carries the burden. It discloses that it produces sector/norm-specific output, accepts client documents, and supports modes/formats, but does not explain side effects like file writes to salidaPath, whether existing files are overwritten, or what the response looks like.

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 sentences, front-loaded with the core purpose and deliverables. The second sentence is a somewhat dense list of inputs but still earns its place by surfacing the client-document and mode/format options.

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 tool with no output schema and no annotations, the description gives purpose and input options but omits how outputs are returned, the default output location, and permission/auth expectations, leaving gaps an agent must guess at.

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%, so enums and all 15 parameters are already documented. The description only echoes 'documentoCliente/documentoClientePath', 'generar|actualizar', and 'casa|cliente' without adding format or behavior detail beyond the schema.

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

Purpose5/5

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

States a specific verb ('Genera') and two concrete deliverables: the FODA/SWOT analysis of requirement 4.1 and the crossed TOWS strategy matrix. This clearly differentiates it from the PESTEL and stakeholders siblings.

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 supported 'modo generar|actualizar' and 'formato casa|cliente' options and the client-document input, which hints at usage contexts. But it never says when to choose this tool over contexto_pestel_4_1 or when to prefer generar vs actualizar beyond the enum labels echoed from the schema.

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