Skip to main content
Glama

Review a signature request

assinafy_review_signature_request
Read-onlyIdempotent

Preview an assinafy_create_assignment call without sending anything: same arguments, checked against the document and signers. Use it when the user wants to review before sending. Apps-capable hosts render a card whose Send button performs the request; other clients get the summary as text, and the request is sent only after the user confirms.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYesvirtual
entriesNoRequired for `collect`: field placements per page.
messageNoText included in the invitation email.
signersYes
expires_atNoISO 8601; default is no expiration. Must be at least one hour in the future.
document_idYesDocument ID.
copy_receiversNoSigner IDs that only receive a copy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • changedInput schema / allOf
      Previous value: -[
      -  {
      -    "if": {
      -      "properties": {
      -        "method": {
      -          "const": "collect"
      -        }
      -      },
      -      "required": [
      -        "method"
      -      ]
      -    },
      -    "then": {
      -      "properties": {
      -        "entries": {
      -          "minItems": 1
      -        }
      -      },
      -      "required": [
      -        "entries"
      -      ]
      -    }
      -  }
      -]New value: +[
      +  {
      +    "if": {
      +      "properties": {
      +        "method": {
      +          "const": "collect"
      +        }
      +      },
      +      "required": [
      +        "method"
      +      ]
      +    },
      +    "then": {
      +      "properties": {
      +        "entries": {
      +          "minItems": 1
      +        }
      +      },
      +      "required": [
      +        "entries"
      +      ]
      +    }
      +  },
      +  {
      +    "else": {
      +      "properties": {
      +        "signers": {
      +          "items": {
      +            "required": [
      +              "id"
      +            ]
      +          }
      +        }
      +      }
      +    },
      +    "if": {
      +      "properties": {
      +        "estimate_only": {
      +          "const": true
      +        }
      +      },
      +      "required": [
      +        "estimate_only"
      +      ]
      +    }
      +  }
      +]
    • changedInput schema / properties / expires_at / description
      Previous value: -"ISO 8601; default is no expiration."New value: +"ISO 8601; default is no expiration. Must be at least one hour in the future."
    • changedInput schema / properties / signers / items / properties / notification_methods / description
      Previous value: -"Channels used to notify the signer of the request. Any combination of `Email` and `Whatsapp` (WhatsApp incurs an additional cost and is available only on paid subscriptions). Omit to default to `{\"Email\"}`."New value: +"How the signer is told a signature is being requested. **Exactly one method per signer** — the array shape is historical, and sending two returns `400`. The method must also be compatible with `verification_method`: `Email` verification takes `Email`, `Whatsapp` verification takes `Whatsapp`, and `DigitalCertificate` and `IdDocumentFaceMatchBasic` take either. WhatsApp incurs an additional cost and is available only on paid subscriptions. Omit it to have it inferred from `verification_method`, or `{\"Email\"}` when neither is sent. See **Verification & Notification Methods** for the full pairing table."
    • addedInput schema / properties / signers / items / properties / notification_methods / example
      Added value: +[
      +  "Email"
      +]
    • addedInput schema / properties / signers / items / properties / notification_methods / maxItems
      Added value: +1
    • addedInput schema / properties / signers / items / properties / step / minimum
      Added value: +1
    • changedInput schema / properties / signers / items / properties / verification_method / description
      Previous value: -"How the signer's identity is verified before signing. `Email` (default) sends a one-time code to the signer's email; `Whatsapp` sends the code over WhatsApp — the verification itself is not billed, but it requires the WhatsApp notification channel, so the signer costs 0.45 credits (available only on paid subscriptions); `DigitalCertificate` has the signer sign with their own ICP-Brasil certificate (A1/A3) — it requires the Digital Certificate feature, the signer's CPF or CNPJ must already be registered on their Assinafy contact (added in Assinafy, never through this tool), must be alone in its signing step, and is charged 2 credits per signer. A CPF requires that person's certificate (an e-CPF, or an e-CNPJ naming them as legal representative); a CNPJ requires an e-CNPJ for that company, from any of its representatives. Omit to default to `Email`."New value: +"How the signer's identity is verified before signing. `Email` (default) sends a one-time code to the signer's email; `Whatsapp` sends the code over WhatsApp — the verification itself is not billed, but it requires the WhatsApp notification channel, so the signer costs 0.45 credits (available only on paid subscriptions); `DigitalCertificate` has the signer sign with their own ICP-Brasil certificate (A1/A3) — it requires the Digital Certificate feature, the signer must have a CPF or CNPJ in `government_id`, must be alone in its signing step, and is charged 0.5 credits per signer. A CPF requires that person's certificate (an e-CPF, or an e-CNPJ naming them as legal representative); a CNPJ requires an e-CNPJ for that company, from any of its representatives. `IdDocumentFaceMatchBasic` verifies the signer from a photo of their government ID, a photo of them holding it and a liveness check — it requires the ID Document + Face Match feature, the signer must have a valid CPF in `government_id`, and is charged a per-signer fee. Omit to default to `Email`."
    • changedInput schema / properties / signers / items / properties / verification_method / enum
      Previous value: -[
      -  "Email",
      -  "Whatsapp",
      -  "DigitalCertificate"
      -]New value: +[
      +  "Email",
      +  "Whatsapp",
      +  "DigitalCertificate",
      +  "IdDocumentFaceMatchBasic"
      +]
    • addedInput schema / properties / signers / items / properties / verification_method / example
      Added value: +"Email"
    • removedInput schema / properties / signers / items / required
      Removed value: -[
      -  "id"
      -]
  2. Changed1 schema field changed
    • changedInput schema / properties / signers / items / properties / verification_method / description
      Previous value: -"How the signer's identity is verified before signing. `Email` (default) sends a one-time code to the signer's email; `Whatsapp` sends the code over WhatsApp — the verification itself is not billed, but it requires the WhatsApp notification channel, so the signer costs 0.45 credits (available only on paid subscriptions); `DigitalCertificate` has the signer sign with their own ICP-Brasil certificate (A1/A3) — it requires the Digital Certificate feature, the signer must have a CPF or CNPJ in `government_id`, must be alone in its signing step, and is charged 2 credits per signer. A CPF requires that person's certificate (an e-CPF, or an e-CNPJ naming them as legal representative); a CNPJ requires an e-CNPJ for that company, from any of its representatives. Omit to default to `Email`."New value: +"How the signer's identity is verified before signing. `Email` (default) sends a one-time code to the signer's email; `Whatsapp` sends the code over WhatsApp — the verification itself is not billed, but it requires the WhatsApp notification channel, so the signer costs 0.45 credits (available only on paid subscriptions); `DigitalCertificate` has the signer sign with their own ICP-Brasil certificate (A1/A3) — it requires the Digital Certificate feature, the signer's CPF or CNPJ must already be registered on their Assinafy contact (added in Assinafy, never through this tool), must be alone in its signing step, and is charged 2 credits per signer. A CPF requires that person's certificate (an e-CPF, or an e-CNPJ naming them as legal representative); a CNPJ requires an e-CNPJ for that company, from any of its representatives. Omit to default to `Email`."
  3. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: nothing is sent until user confirmation, apps-capable hosts render an interactive card, other clients get a text summary. It does not say what the preview actually returns or how validation failures surface, leaving a modest gap.

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 the core preview semantics before host-specific rendering details. Every sentence carries distinct information with no repetition of the title or schema.

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 preview/validation tool with no output schema, the description covers the send-confirmation flow and the two client renderings, which is the key context an agent needs. It omits what the preview returns on validation failure, a minor gap given no output schema is declared.

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 coverage is 71%, so the schema documents most parameters in detail. The description's 'same arguments, checked against the document and signers' usefully tells the agent the parameter set mirrors assinafy_create_assignment, but adds no field-level semantics. Baseline 3 is appropriate.

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 ('Preview') plus the exact resource it mirrors, naming the sibling assinafy_create_assignment as the call being previewed. The distinction between this tool and its sibling (preview vs. send) is immediately clear without opening either 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?

'Use it when the user wants to review before sending' gives a clear triggering condition and the named sibling supplies the alternative. There is no explicit when-not statement (e.g. what to do if the user has already confirmed), so it stops short of full routing guidance.

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.