Skip to main content
Glama

Configurar Perfil Tecnico Colegiado

configurar_perfil_tecnico_colegiado

Configures and persistently saves a certifying technician's professional and association details to auto-fill all generated CE3X, XML, and PDF certificates. Run once or when details change.

Instructions

Configura y guarda de forma persistente los datos colegiales y profesionales del técnico certificador (nombre, NIF, titulación, colegio, número de colegiado) para auto-cumplimentar todos los certificados generados.

Cuándo usar: Invoque esta herramienta una sola vez o cuando cambien los datos profesionales del técnico para que se inyecten automáticamente en los archivos .cex, .xml y .pdf.

Comportamiento y efectos secundarios: Operación de configuración persistente (Write). Guarda los datos en el archivo de perfil local del usuario.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoCorreo electrónico profesional de contacto.
telefonoNoTeléfono de contacto profesional.
domicilioNoDomicilio o dirección profesional del técnico.
municipioNoMunicipio del domicilio profesional.
provinciaNoProvincia del domicilio profesional.
titulacionYesTitulación académica habilitante (ej. 'Arquitecto Técnico', 'Ingeniero de Edificación', 'Arquitecto').
nif_tecnicoYesNIF o NIE del técnico certificador.
razon_socialNoRazón social del estudio o empresa técnica (opcional).
codigo_postalNoCódigo postal profesional de 5 dígitos.
nombre_tecnicoYesNombre y apellidos completos del técnico certificador competente.
numero_colegiadoYesNúmero de colegiado profesional.
comunidad_autonomaNoComunidad Autónoma donde ejerce habitualmente la actividad.Galicia
colegio_profesionalYesNombre oficial del Colegio Profesional (ej. 'Colegio Oficial de la Arquitectura Técnica de A Coruña').

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed42 schema fields changed
    • removedInput schema / properties / codigo_postal / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / codigo_postal / default
      Previous value: -nullNew value: +""
    • addedInput schema / properties / codigo_postal / description
      Added value: +"Código postal profesional de 5 dígitos."
    • addedInput schema / properties / codigo_postal / type
      Added value: +"string"
    • removedInput schema / properties / colegio_profesional / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / colegio_profesional / default
      Removed value: -null
    • addedInput schema / properties / colegio_profesional / description
      Added value: +"Nombre oficial del Colegio Profesional (ej. 'Colegio Oficial de la Arquitectura Técnica de A Coruña')."
    • addedInput schema / properties / colegio_profesional / type
      Added value: +"string"
    • addedInput schema / properties / comunidad_autonoma / description
      Added value: +"Comunidad Autónoma donde ejerce habitualmente la actividad."
    • removedInput schema / properties / domicilio / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / domicilio / default
      Previous value: -nullNew value: +""
    • addedInput schema / properties / domicilio / description
      Added value: +"Domicilio o dirección profesional del técnico."
    • addedInput schema / properties / domicilio / type
      Added value: +"string"
    • removedInput schema / properties / email / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / email / default
      Previous value: -nullNew value: +""
    • addedInput schema / properties / email / description
      Added value: +"Correo electrónico profesional de contacto."
    • addedInput schema / properties / email / type
      Added value: +"string"
    • removedInput schema / properties / municipio / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / municipio / default
      Previous value: -nullNew value: +""
    • addedInput schema / properties / municipio / description
      Added value: +"Municipio del domicilio profesional."
    • addedInput schema / properties / municipio / type
      Added value: +"string"
    • addedInput schema / properties / nif_tecnico / description
      Added value: +"NIF o NIE del técnico certificador."
    • addedInput schema / properties / nombre_tecnico / description
      Added value: +"Nombre y apellidos completos del técnico certificador competente."
    • removedInput schema / properties / numero_colegiado / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / numero_colegiado / default
      Removed value: -null
    • addedInput schema / properties / numero_colegiado / description
      Added value: +"Número de colegiado profesional."
    • addedInput schema / properties / numero_colegiado / type
      Added value: +"string"
    • removedInput schema / properties / provincia / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / provincia / default
      Previous value: -nullNew value: +""
    • addedInput schema / properties / provincia / description
      Added value: +"Provincia del domicilio profesional."
    • addedInput schema / properties / provincia / type
      Added value: +"string"
    • removedInput schema / properties / razon_social / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / razon_social / default
      Previous value: -nullNew value: +""
    • addedInput schema / properties / razon_social / description
      Added value: +"Razón social del estudio o empresa técnica (opcional)."
    • addedInput schema / properties / razon_social / type
      Added value: +"string"
    • removedInput schema / properties / telefono / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • changedInput schema / properties / telefono / default
      Previous value: -nullNew value: +""
    • addedInput schema / properties / telefono / description
      Added value: +"Teléfono de contacto profesional."
    • addedInput schema / properties / telefono / type
      Added value: +"string"
    • removedInput schema / properties / titulacion / default
      Removed value: -"Arquitecto Técnico"
    • addedInput schema / properties / titulacion / description
      Added value: +"Titulación académica habilitante (ej. 'Arquitecto Técnico', 'Ingeniero de Edificación', 'Arquitecto')."
    • changedInput schema / required
      Previous value: -[
      -  "nombre_tecnico",
      -  "nif_tecnico"
      -]New value: +[
      +  "nombre_tecnico",
      +  "nif_tecnico",
      +  "titulacion",
      +  "colegio_profesional",
      +  "numero_colegiado"
      +]
  2. First observedv1.5.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare write (readOnlyHint=false, destructiveHint=false). The description adds real behavioral context: it is persistent, it writes to a local user profile file, and the data is auto-injected into .cex/.xml/.pdf outputs. It does not clarify overwrite-vs-merge semantics or auth/permission requirements, keeping it below 5.

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?

Well front-loaded and organized into purpose, 'Cuándo usar', and 'Comportamiento' sections. Slightly redundant in repeating the persistent-write notion in both the opening and the side-effects block, but otherwise efficient.

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?

With an output schema present, the description need not explain return values, and annotations cover the safety profile. Purpose, timing, and side effects are all covered; only edge-case behavior (overwrite semantics, validation failures) is unaddressed.

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% across 13 parameters, so the schema already carries the semantic load. The description only restates the 5 required fields (nombre, NIF, titulación, colegio, número), adding nothing beyond what the schema documents; the baseline of 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 ('Configura y guarda') and a highly specific resource ('datos colegiales y profesionales del técnico certificador'), then enumerates the key fields. This is unmistakably distinct from the analysis/certificate-generation siblings, so an agent can identify it without opening the schema.

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

Usage Guidelines4/5

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

The 'Cuándo usar' block gives explicit triggering guidance: invoke once, or when professional data changes. It lacks an explicit 'when-not'/alternative statement, but no sibling competes for this function, so the practical ambiguity is low.

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