Skip to main content
Glama
JoseAlmeida-Ploomes

Ploomes MCP Server

identificar_campos_html_ia

Identify dynamic fields in HTML from the model builder, inject field tags, and return the list of detected fields for CRM field creation.

Instructions

    Identificar, via IA, os campos dinâmicos marcados num HTML gerado
    (ou editado) pela ferramenta gerar_modelo_html_ia.

    Endpoint: POST {PLOOMES_AI_BASE_URL}/html_fields_identification.
    Recebe o HTML e devolve o mesmo HTML com tags <field id="N"> injetadas
    nos pontos detectados, mais a lista de campos identificados.

    Parâmetros:
        html: HTML retornado por gerar_modelo_html_ia, contendo as
            marcações que o usuário pediu para a IA reconhecer como campo.
        root_entity_id: mesmo Id usado em gerar_modelo_html_ia — usado
            para calcular o caminho (PathId) de cada campo detectado.
        idioma: idioma do usuário (ex.: "pt-BR").

    Retorno (api_response.Fields), cada item com:
        Id: identificador interno (é o valor que aparece em <field id="N">
            no HTML retornado — use para casar campo↔posição no HTML).
        EntityId: entidade do campo (ex.: Proposta, Contato, Produto).
        Name: nome sugerido pela IA para o campo.
        TypeId: tipo sugerido (texto, número, data, etc.).
        Key: preenchido SE o campo já existir no sistema (nesse caso ele
            só será vinculado, não recriado). Vazio/None = campo novo.
        PathId: caminho da entidade (relação entre a entidade raiz e a
            entidade do campo).
        Multiple: se True, o campo é um bloco repetível (ex.: lista de
            produtos) — mesma lógica de multiple-field-key descoberta na
            investigação do bloco de Produtos (ver bugs-mcp-ploomes.md
            item 9); ainda não testamos se os dois mecanismos produzem
            exatamente o mesmo HTML por baixo.

    Próximo passo: para os campos SEM Key (novos), chame
    criar_campos_em_massa_ia. Depois, use aplicar_campos_no_html_ia para
    obter o HTML final pronto (com <field key="..."> no lugar de
    <field id="N">).
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
htmlYes
idiomaNopt-BR
root_entity_idYes
Behavior5/5

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

No annotations are provided, so the description carries full responsibility. It discloses that the tool returns the same HTML with injected <field id="N"> tags and a list of fields with detailed attributes (Id, EntityId, Name, TypeId, Key, PathId, Multiple). It also mentions a caveat about the 'Multiple' field behavior, enhancing transparency.

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?

The description is well-structured with clear sections and bullet points, but includes some extraneous details like the raw endpoint URL and a reference to a bug file ('ver bugs-mcp-ploomes.md item 9'), which are not helpful for an AI agent. These minor wastes prevent a perfect score.

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

Completeness5/5

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

Given the lack of output schema, the description provides a thorough explanation of the return structure and how to use the results. It also contextualizes the tool within the broader pipeline, referencing sibling tools and steps, making it fully complete for an agent.

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

Parameters5/5

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

The input schema has 0% description coverage, but the description adds significant meaning: 'html' is the HTML from 'gerar_modelo_html_ia', 'root_entity_id' is the same ID used there for computing PathId, and 'idioma' is the user's language. This fully compensates for the lack of schema descriptions.

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?

The description clearly states the tool's purpose: identifying dynamic fields in HTML generated by 'gerar_modelo_html_ia'. It specifies the verb 'identificar' and the resource 'campos dinâmicos'. This distinguishes it from sibling tools like 'criar_campos_em_massa_ia' and 'aplicar_campos_no_html_ia'.

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?

The description explicitly tells when to use the tool (after obtaining HTML from 'gerar_modelo_html_ia') and lays out the next steps: for new fields call 'criar_campos_em_massa_ia', then 'aplicar_campos_no_html_ia'. This provides clear context and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JoseAlmeida-Ploomes/ploomes-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server