Skip to main content
Glama
Sign In

Assinafy

by io.github.assinafy
OverviewDiscussionsAdmin

Update signer

assinafy_update_signer
Destructive

Update a signer's information. Only supplied fields change; send null or an empty string to clear email, whatsapp_phone_number, or government_id.

Verification integrity: email / whatsapp_phone_number cannot be changed while the signer has verified that channel on an in-flight (not yet certificated) document — the response is 400 naming the offending document(s). Already-certificated documents do not block updates. Changing a channel that has unverified in-flight requests rotates their access/verification codes (invalidating previously sent links/OTPs); use the resend endpoint to redeliver. full_name can always be updated.

Input Schema

NameRequiredDescriptionDefault
emailNoA valid email address, or null/empty to clear it.
full_nameNo
signer_idYesThe signer ID.
account_idNoAuthorized workspace; discovered from OAuth when omitted.
government_idNoSigner's CPF (11 digits) or CNPJ (14 characters; may be alphanumeric). Formatting is accepted and the value is normalized on save. Required before the signer can use a verification method that identifies them by CPF. Null/empty clears it.
whatsapp_phone_numberNoE.164 and normalized on save; null/empty clears it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / email / anyOf
      Added value: +[
+  {
+    "format": "email",
+    "type": "string"
+  },
+  {
+    "maxLength": 0,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / email / description
      Added value: +"A valid email address, or null/empty to clear it."
    • removedInput schema / properties / email / format
      Removed value: -"email"
    • removedInput schema / properties / email / type
      Removed value: -"string"
    • changedInput schema / properties / government_id / description
      Previous value: -"Signer's CPF (11 digits) or CNPJ (14 characters; may be alphanumeric). Formatting is accepted and the value is normalized on save. Required before the signer can use a verification method that identifies them by CPF."New value: +"Signer's CPF (11 digits) or CNPJ (14 characters; may be alphanumeric). Formatting is accepted and the value is normalized on save. Required before the signer can use a verification method that identifies them by CPF. Null/empty clears it."
    • changedInput schema / properties / government_id / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedInput schema / properties / whatsapp_phone_number / description
      Previous value: -"E.164; normalized on save."New value: +"E.164 and normalized on save; null/empty clears it."
    • changedInput schema / properties / whatsapp_phone_number / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
  2. Changed2 schema fields changed
    • changedInput schema / anyOf
      Previous value: -[
-  {
-    "required": [
-      "full_name"
-    ]
-  },
-  {
-    "required": [
-      "email"
-    ]
-  },
-  {
-    "required": [
-      "whatsapp_phone_number"
-    ]
-  }
-]New value: +[
+  {
+    "required": [
+      "full_name"
+    ]
+  },
+  {
+    "required": [
+      "email"
+    ]
+  },
+  {
+    "required": [
+      "whatsapp_phone_number"
+    ]
+  },
+  {
+    "required": [
+      "government_id"
+    ]
+  }
+]
    • addedInput schema / properties / government_id
      Added value: +{
+  "description": "Signer's CPF (11 digits) or CNPJ (14 characters; may be alphanumeric). Formatting is accepted and the value is normalized on save. Required before the signer can use a verification method that identifies them by CPF.",
+  "type": "string"
+}
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true and idempotentHint=false; the description goes well beyond by disclosing that omitted fields are untouched, null/empty clears specific fields, verified-channel changes on in-flight documents return a 400 naming the offending documents, certificated documents do not block, and channel changes rotate access/verification codes. That is exactly the consequence information an agent needs before invoking a destructive mutation.

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 core behavior is front-loaded in one sentence, followed by a clearly labeled "Verification integrity" block. Every sentence carries operational meaning, though the dense parenthetical clauses make it slightly heavier than necessary.

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 destructive, non-idempotent mutation with no output schema, the description covers error behavior (400 with document names), side effects, and the follow-up action needed after a channel change. The only gap is what a successful response contains, which the caller must infer.

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 83%, so the baseline is 3, but the description adds real semantics the schema cannot: patch-style partial updates, the null/empty clearing contract across three fields, and the conditional mutability of email/whatsapp vs. the always-updatable full_name. It does not touch account_id or the signer_id lookup, which keeps it from a 5.

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 opens with a specific verb and resource ("Update a signer's information") that clearly distinguishes it from assinafy_create_signer and assinafy_get_signer. It also clarifies patch semantics ("Only supplied fields change"), but never names a sibling tool explicitly.

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 conditions an agent needs before calling: which fields can be cleared, when a channel change is rejected (verified channel on an in-flight document), and it names the alternative ("use the resend endpoint to redeliver") for the unverified-request case. It stops short of a full when-to-use/when-not framing against get_signer or create_signer.

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