Skip to main content
Glama

Assinafy

by io.github.assinafy
OverviewDiscussionsAdmin

Create assignment (request signatures)

assinafy_create_assignment

Request signatures on a document. Use method: virtual to sign without input fields, or method: collect to place input fields on specific pages.

For virtual, the document may be in uploaded, metadata_processing or metadata_ready; it is promoted to pending_signature automatically once metadata processing completes. For collect, the document must be in metadata_ready (fields reference specific pages).

step controls signing order: signers sharing a step sign in parallel, and the next step is notified only after the previous step completes. If supplied, every signer must supply it and values must be contiguous starting at 1. Obtain signer IDs from assinafy_list_signers or assinafy_create_signer and page IDs from assinafy_get_document. This sends signing invitations. Check with assinafy_get_document that no assignment exists first; this can consume credits.

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.
estimate_onlyNoPreview cost and balances without creating an assignment or notifying anyone.
copy_receiversNoSigner IDs that only receive a copy.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 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"
+      ]
+    }
+  }
+]
    • addedInput schema / properties / estimate_only
      Added value: +{
+  "description": "Preview cost and balances without creating an assignment or notifying anyone.",
+  "type": "boolean"
+}
    • 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. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), and the description adds non-obvious behavior beyond them: 'this sends signing invitations', 'can consume credits', and the automatic promotion from uploaded/metadata_processing to pending_signature. It does not describe the response payload, but with no output schema that is a minor gap.

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?

Front-loaded with the action and the two modes, then prerequisites, ordering, ID sourcing, and the credit/invitation warning. Dense but every clause carries operational information; slightly long, yet nothing reads as filler.

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?

Given 8 parameters, no output schema and a mutation tool, the description covers the essentials an agent needs: mode selection, document-state preconditions, signer ordering rules, ID sourcing, invitation/credit side effects. It omits what the call returns, but with no output schema declared that omission is acceptable.

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 75% and the schema itself is very detailed (step only says minimum 1, verification_method and notification_methods carry long docs). The description compensates for the weakest field by explaining `step` semantics: parallel within a step, next step notified after the previous completes, and 'every signer must supply it and values must be contiguous starting at 1'. It also adds state requirements for `method`.

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 opening sentence states a specific verb+resource ('Request signatures on a document') and immediately disambiguates the two modes ('virtual' vs 'collect') by what each one does. An agent can distinguish this from siblings like assinafy_place_fields or assinafy_send_pdf_for_signature without opening any schema.

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?

Explicitly states when each method applies (virtual needs no input fields; collect places fields on specific pages), the required document state per method, and the precondition to 'Check with assinafy_get_document that no assignment exists first'. It also names where to obtain signer IDs (assinafy_list_signers / assinafy_create_signer) and page IDs (assinafy_get_document).

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

All Assinafy toolsInspect
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