Assinafy MCP Server

Place signature fields

assinafy_place_fields

Read-onlyIdempotent

Open a visual editor to place signature, initials, date and input fields on a metadata_ready document, then send it with method collect. Takes the assinafy_create_assignment arguments except method and entries. Sends nothing by itself: in apps-capable hosts the user places fields and presses Send; other clients get page sizes and field IDs as text to build entries.

Input Schema

Name	Required	Description
`message`	No	Text included in the invitation email.
`signers`	Yes
`expires_at`	No	ISO 8601; default is no expiration. Must be at least one hour in the future.
`document_id`	Yes	Document ID.
`copy_receivers`	No	Signer IDs that only receive a copy.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

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 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`."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 `method: virtual`, the Digital Certificate feature, 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`."

Changed10 schema fields changedOct 16, 2026

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"
-]
```

Changed1 schema field changedOct 13, 2026

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`."

AddedOct 8, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real context: it 'sends nothing by itself,' the user completes the send in apps-capable hosts, and other clients receive page sizes and field IDs as text. That host-dependent behavior is not derivable from the annotations.

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

Conciseness3/5

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

Three sentences, front-loaded with the purpose, with no obvious filler. The middle sentence is slightly dense and the 'then send it with method collect' clause sits awkwardly against the later 'sends nothing by itself' clarification, costing some crispness.

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?

There is no output schema, and the description compensates by describing what non-apps hosts get back (page sizes and field IDs). Combined with the host-dependent behavior and the argument inheritance from create_assignment, an agent has enough to invoke it correctly, though the send/no-send flow could be stated more unambiguously.

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

Parameters4/5

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

Schema coverage is already 80%, but the description adds a non-obvious mapping ('takes the assinafy_create_assignment arguments except method and entries'), telling the agent which argument set applies without opening the sibling schema. It does not explain individual parameters, but it adds meaning beyond the schema's per-field descriptions.

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?

It states a specific verb+resource ('place signature, initials, date and input fields') and the mechanism ('open a visual editor'), and it distinguishes itself from assinafy_create_assignment by noting it takes the same arguments minus method/entries. The only blur is whether the tool sends or merely stages, though the description resolves this in the next sentence.

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

Usage Guidelines3/5

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

It gives situational context ('in apps-capable hosts... other clients get page sizes and field IDs') and ties itself to the create_assignment argument set, which implies its place in the workflow. However, it never states explicitly when to choose this over create_assignment or send_pdf_for_signature, so the routing decision is left to inference.

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

All Assinafy MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?