Skip to main content
Glama
Sign In

SELISE Signature

by com.selisesignature
OverviewDiscussionsAdmin

Get signature document status

get_signature_document_status
Read-onlyIdempotent

Read document status events once using an actual documentId UUID. Use to check progress after preparation/sending, especially pending or UNKNOWN_OUTCOME. Does not upload, prepare, send, sign, or continuously poll. Returns {statuses: [...]} containing only distinct observed values: preparation_success (preparation succeeded), preparation_failed (preparation failed), sending_success (dispatch succeeded, not completed signing), sending_failed (dispatch failed), completed (document completion recorded). These are historical observations, not one current state. Success and failure can both appear; array order does not establish chronology. An empty list means no recognized events were returned: it does not prove existence, failure, completion, or that resubmission is safe. Other events, including cancellation, expiration, and individual-signer progress, are omitted; this is not a complete lifecycle report. Returns no timestamps, signer details, download URLs, or signing links. Request/authentication failures return an error, not an empty status list. If polling is needed, space checks by at least 3 seconds and avoid concurrent polling of the same document. A status check does not authorize retrying a state-changing tool. Use only the declared fields. Ask for missing facts instead of inventing values. Service credentials are configured on the server and must not be included in tool arguments.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "documentId": "<documentId>"
    },
    "name": "get_signature_document_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
documentIdYesDocument UUID returned by a previous preparation/submission or supplied from a trusted source. Use the exact documentId, not fileId, trackingId, or operationId. Do not generate a placeholder UUID; format validity does not prove the document exists.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / anyOf
      Previous value: -[
-  {
-    "additionalProperties": false,
-    "description": "One status lookup. Only statuses are returned; no signer details, links, raw events, or timestamps.",
-    "properties": {
-      "statuses": {
-        "description": "Distinct observed statuses, not a single current state or a chronological list. Success and failure may coexist. Empty means no recognized events were returned, not proof of existence, failure, completion, or safety to retry. Other lifecycle events are omitted.",
-        "items": {
-          "description": "preparation_success/preparation_failed: preparation outcome; sending_success/sending_failed: dispatch outcome; completed: document completion recorded. sending_success does not mean completed signing.",
-          "enum": [
-            "preparation_success",
-            "preparation_failed",
-            "sending_success",
-            "sending_failed",
-            "completed"
-          ],
-          "type": "string"
-        },
-        "type": "array"
-      }
-    },
-    "required": [
-      "statuses"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "description": "Error payload returned with the MCP result's isError flag set to true. Known IDs are optional and may be provisional; do not assume an error makes resubmission safe.",
-    "properties": {
-      "code": {
-        "description": "INVALID_REQUEST: input validation failed. REQUEST_FAILED: operation failed; use referenceId for diagnosis. UNKNOWN_OUTCOME: an action may have succeeded despite the error; inspect document status before considering a retry.",
-        "enum": [
-          "INVALID_REQUEST",
-          "REQUEST_FAILED",
-          "UNKNOWN_OUTCOME"
-        ],
-        "type": "string"
-      },
-      "documentId": {
-        "description": "Document identifier. Reuse as documentId in subsequent calls; an ID in an error response may be provisional and does not prove the document was created or the command accepted.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "fileId": {
-        "description": "Storage identifier of the PDF. Reuse with its matching documentId when sending; not a download URL.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "message": {
-        "description": "Safe error explanation or recovery guidance; no private upstream diagnostics.",
-        "type": "string"
-      },
-      "operationId": {
-        "description": "Identifier for tracing this tool operation. Not a document ID or proof of completion.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "referenceId": {
-        "description": "Sentry error reference for support and diagnostics. Not a documentId or trackingId.",
-        "minLength": 1,
-        "type": "string"
-      },
-      "trackingId": {
-        "description": "Backend command correlation identifier, when available. Not a document ID or proof of completion.",
-        "minLength": 1,
-        "type": "string"
-      }
-    },
-    "required": [
-      "code",
-      "message",
-      "referenceId"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "description": "One status lookup. Only statuses are returned; no signer details, links, raw events, or timestamps.",
+    "properties": {
+      "statuses": {
+        "description": "Distinct observed statuses, not a single current state or a chronological list. Success and failure may coexist. Empty means no recognized events were returned, not proof of existence, failure, completion, or safety to retry. Other lifecycle events are omitted.",
+        "items": {
+          "description": "preparation_success/preparation_failed: preparation outcome; sending_success/sending_failed: dispatch outcome; completed: document completion recorded. sending_success does not mean completed signing.",
+          "enum": [
+            "preparation_success",
+            "preparation_failed",
+            "sending_success",
+            "sending_failed",
+            "completed"
+          ],
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "statuses"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "description": "Error payload returned with the MCP result's isError flag set to true. Known IDs are optional and may be provisional; do not assume an error makes resubmission safe.",
+    "properties": {
+      "code": {
+        "description": "INVALID_REQUEST: input validation failed. SIGNATURE_LIMIT_REACHED: signature quota exhausted; explain the message and do not retry sending until quota is available. REQUEST_FAILED: operation failed; use referenceId for diagnosis. UNKNOWN_OUTCOME: an action may have succeeded despite the error; inspect document status before considering a retry.",
+        "enum": [
+          "INVALID_REQUEST",
+          "REQUEST_FAILED",
+          "UNKNOWN_OUTCOME",
+          "SIGNATURE_LIMIT_REACHED"
+        ],
+        "type": "string"
+      },
+      "documentId": {
+        "description": "Document identifier. Reuse as documentId in subsequent calls; an ID in an error response may be provisional and does not prove the document was created or the command accepted.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "fileId": {
+        "description": "Storage identifier of the PDF. Reuse with its matching documentId when sending; not a download URL.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "message": {
+        "description": "Safe error explanation or recovery guidance; no private upstream diagnostics.",
+        "type": "string"
+      },
+      "operationId": {
+        "description": "Identifier for tracing this tool operation. Not a document ID or proof of completion.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "referenceId": {
+        "description": "Sentry error reference for support and diagnostics. Not a documentId or trackingId.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "trackingId": {
+        "description": "Backend command correlation identifier, when available. Not a document ID or proof of completion.",
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "code",
+      "message",
+      "referenceId"
+    ],
+    "type": "object"
+  }
+]
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, yet the description adds substantial beyond-schema behavior: it enumerates the distinct observed status values, warns that observations are historical rather than a single current state, explains that order is not chronological, and clarifies that success and failure may both appear. It further defines the empty-list semantics, lists omitted events (cancellation, expiration, signer progress), and states that authentication failures return an error rather than an empty list — a genuinely valuable distinction for an agent's decision logic.

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 substantive content is front-loaded: purpose, then usage, then return semantics, then polling guidance. It is dense but earns most of its length, losing points only for generic boilerplate at the end ('Use only the declared fields. Ask for missing facts instead of inventing values') that is not specific to this tool.

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

Completeness5/5

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

An output schema exists, so the description did not need the per-status enumeration, yet that enumeration and the ambiguity warnings (non-chronological order, empty list not proving anything, omissions) make the return contract unambiguous. Combined with the annotation-covered safety profile and the documented single parameter, an agent has everything needed to call this correctly and interpret the result.

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 100% and the parameter's own description already warns to use the exact documentId and not a placeholder UUID, so the description's 'using an actual documentId UUID' is largely redundant. With a single fully documented parameter, the baseline of 3 is appropriate — the description neither adds format detail nor introduces new parameter semantics.

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 and resource: 'Read document status events once using an actual documentId UUID.' It immediately distinguishes the tool from the sibling write operations by declaring 'Does not upload, prepare, send, sign, or continuously poll,' so an agent can tell it apart from prepare_and_send_free_signature_document 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 Guidelines4/5

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

'Use to check progress after preparation/sending, especially pending or UNKNOWN_OUTCOME' gives a clear triggering condition, and the negative list plus 'If polling is needed, space checks by at least 3 seconds' covers when-not. It stops short of naming the sibling tools as explicit alternatives for the write path, so it reads as strong context rather than a full routing table.

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

All SELISE Signature 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