Skip to main content
Glama

ZapSign

by io.github.mcp-dir

zapsign_signers_write_update

Gerenciar signatários no ZapSign. Ações:

  • add (doc_token, data): adiciona signatário. Campos: name*, email*; opc phone_country, phone_number, auth_mode (assinaturaTela|tokenEmail|tokenSms|tokenWhatsapp), lock_name/email/phone, qualification, send_automatic_email, send_automatic_whatsapp, require_document_photo.

  • update (signer_token, data): atualiza (só antes de assinar) ou reenvia lembrete. Mesmos campos de add.

  • remove (signer_token): remove (não pode remover quem já assinou nem o único signatário).

  • sign (data): assina em lote via API (assíncrono). Campos: signer_tokens[]*; opc selfie_photo, document_photo_url. (user_token é injetado automaticamente.)

[Flattened action: update]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
accountNo
doc_tokenNo
signer_tokenNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

B3.3/5.0
Behavior3/5

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

The description adds useful non-annotation behavior: update is only allowed before signing and can resend reminders. However, it does not disclose side effects, whether changes are reversible, permission requirements, or what happens under failure, so transparency beyond annotations is limited.

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

Conciseness2/5

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

The description is not concise: it includes full explanations for add, update, remove, and sign even though this tool is flattened to update. Only the update bullet and final 'Flattened action: update' note are relevant; the rest is noise for an agent selecting this specific tool.

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

Completeness2/5

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

With no output schema and annotations that only indicate readOnly/idempotent/destructive hints, the description should cover response/error behavior and clarify all parameters. It gives update constraints and field lists, but omits the meaning of account/doc_token, required-parameter details, and post-update behavior, leaving the tool incomplete for reliable invocation.

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 0%, so the description must compensate. It documents the data fields (name*, email*, and optional fields) and mentions signer_token, but it never explains the 'account' parameter or why doc_token is in the schema for update. The nested 'data' object is partially clarified but not fully.

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?

The description identifies 'update' as the flattened action and states that it updates a signer or resends a reminder, which is a clear verb+resource combination. It also distinguishes from sibling operations by listing add/remove/sign as separate actions, though the overall header 'Gerenciar signatários' is generic.

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?

It gives concrete usage context: update only works before signing and can also resend a reminder. It implies this tool is for update rather than add/remove/sign, but it does not explicitly say 'when not to use' or name alternative tools beyond the action list.

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

All ZapSign toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0
Disambiguation4/5

Each tool has a distinct name and purpose, with clear separation between read and write actions. However, the high number of similarly-prefixed tools (e.g., zapsign_documents_write_*) and the overlap between create and create_from_template could occasionally cause misselection.

Naming Consistency3/5

Domain tools follow a consistent zapsign_<resource>_<action> pattern, with writes marked by _write_. However, platform-level tools (authenticate, connect, marketplace) break the pattern, and zapsign_list_accounts deviates from the resource-prefix convention.

Tool Count2/5

35 tools is excessive, especially since many are flattened actions from a smaller set of underlying operations. The inclusion of non-domain platform tools further inflates the count, making the tool list feel heavy and harder to navigate.

Completeness4/5

The core ZapSign domain is well covered: documents, signers, templates, webhooks, checks, and account management all have CRUD-like operations. Minor gaps exist, such as no listing endpoint for checks and no webhook list (due to API limitations), but these are not fatal for typical workflows.

Resources