Skip to main content
Glama

Identik Firma Digital

Crear documento desde plantilla

crear_documento_desde_plantilla

Genera un documento de firma digital a partir de una plantilla. Flujo: listar_plantillas → esta herramienta → enviar_documento. Devuelve el documentId y el signingUrl de cada firmante. IMPORTANTE: el documento queda en borrador (no consume crédito) hasta que lo envíes con enviar_documento.

Input Schema

NameRequiredDescriptionDefault
asuntoNoAsunto del email de invitación.
tituloNoTítulo del documento (si no, hereda el de la plantilla).
mensajeNoMensaje del email de invitación.
firmantesYesLos firmantes de esta instancia.
plantilla_idYesEl `id` de la plantilla.
avisar_por_whatsappNotrue = a cada firmante que tenga `telefono` cargado se le manda el link de firma por WhatsApp, ADEMÁS del email cuando se habilitan los avisos iniciales al enviar. En Electrónica y contratos prepago consume 1 crédito por mensaje; en Digital pago por documento se consumen los 5 créditos incluidos del paquete al enviar con este canal. Consultá estado_cuenta. Sin saldo o sin teléfono no se manda el WhatsApp.
verificar_personeriaNotrue = los firmantes que tengan `en_representacion_de` deben acreditar su personería para poder firmar: el propio firmante sube desde su link la documentación societaria (acta, poder, estatuto), Identik compara su DNI y nombre con la nómina y recién acreditado presta una declaración jurada y firma. El envío no se bloquea; la barrera es al firmar. La constancia deja asentada la verificación. Requiere el módulo de personería habilitado en la organización.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / firmantes / items / properties / en_representacion_de
      Added value: +{
      +  "description": "CUIT de la sociedad en cuyo nombre firma este firmante (por ej. \"30-71234567-1\"). Si no está en el catálogo de la organización se crea con ese CUIT; la documentación que acredita al firmante la sube el propio firmante desde su link antes de firmar. El documento tiene que tener `verificar_personeria: true`. Sin este campo el firmante firma por sí.",
      +  "type": "string"
      +}
    • addedInput schema / properties / firmantes / items / properties / razon_social_representada
      Added value: +{
      +  "description": "Razón social de la sociedad de `en_representacion_de`. Opcional: si la sociedad no está en el catálogo se crea con el CUIT y la razón social se completa con la documentación que aporte el firmante.",
      +  "maxLength": 200,
      +  "minLength": 3,
      +  "type": "string"
      +}
    • addedInput schema / properties / verificar_personeria
      Added value: +{
      +  "description": "true = los firmantes que tengan `en_representacion_de` deben acreditar su personería para poder firmar: el propio firmante sube desde su link la documentación societaria (acta, poder, estatuto), Identik compara su DNI y nombre con la nómina y recién acreditado presta una declaración jurada y firma. El envío no se bloquea; la barrera es al firmar. La constancia deja asentada la verificación. Requiere el módulo de personería habilitado en la organización.",
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / avisar_por_whatsapp / description
      Previous value: -"true = a cada firmante que tenga `telefono` cargado se le manda el link de firma por WhatsApp, ADEMÁS del email. Consume 1 crédito de WhatsApp por mensaje enviado (ver estado_cuenta). Sin saldo o sin teléfono no se manda nada y el email sale igual."New value: +"true = a cada firmante que tenga `telefono` cargado se le manda el link de firma por WhatsApp, ADEMÁS del email cuando se habilitan los avisos iniciales al enviar. En Electrónica y contratos prepago consume 1 crédito por mensaje; en Digital pago por documento se consumen los 5 créditos incluidos del paquete al enviar con este canal. Consultá estado_cuenta. Sin saldo o sin teléfono no se manda el WhatsApp."
    • changedInput schema / properties / firmantes / items / properties / telefono / description
      Previous value: -"Teléfono en formato internacional (por ej. \"+5491123456789\") para mandarle el link de firma por WhatsApp además del email. Requiere que la cuenta tenga saldo de WhatsApp (ver estado_cuenta) y que el documento lo tenga activado; si falta algo se ignora y el firmante recibe el email."New value: +"Teléfono en formato internacional (por ej. \"+5491123456789\") para mandarle el link de firma por WhatsApp además del email, cuando los avisos iniciales están habilitados. Requiere saldo de WhatsApp (ver estado_cuenta) y el canal activado en el documento. El consumo depende del plan; si falta teléfono o saldo no se manda el WhatsApp."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden well: it discloses the return values (documentId, signingUrl per signer) and critically that the document stays in draft and consumes no credit until sent. It does not cover permission requirements or limits, but the draft/credit behavior is a meaningful, non-obvious trait.

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?

Three tight sentences, front-loaded with purpose and flow, then the payoff (return values) and the critical constraint. No filler; each sentence earns its place.

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

Completeness4/5

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

For a 7-parameter mutation tool with no annotations and no output schema, the description supplies the workflow, the return values, and the draft/credit semantics that an agent needs to call it correctly. Remaining gaps (auth scope) are minor against the rich schema.

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 every parameter (including nested firmantes fields and the WhatsApp/personería flags) is already fully documented in the schema. The description adds no parameter-level syntax or constraints beyond what the schema provides, so the baseline 3 applies.

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 and resource ('Genera un documento de firma digital a partir de una plantilla') and positions it distinctly from siblings like enviar_documento and listar_plantillas. An agent can tell immediately what this creates and from what source.

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

Usage Guidelines5/5

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

Explicitly lays out the workflow ('listar_plantillas → esta herramienta → enviar_documento') and names the alternative that completes the process. It also clarifies the condition that changes state (draft until sent), giving the agent a clear when-to-use and what-comes-next.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.