Loading ToolBench
MCP server for DigiSign.cz digital signature API. Exposes tools for envelope management, document upload, recipient management, and signature tag placement.
The DigiSign server has 15 well-defined tools with explicit Zod schemas and descriptions. All tools are registered with proper verb_noun naming (list_*, get_*, create_*, add_*, send_*, delete_*, discard_*). Input parameters have type definitions and descriptions. However, OUTPUT schemas are not documented, responses are serialized as JSON strings with no structured schema specification. Error handling returns plain error messages but lacks categorization (retryable, user-fixable, fatal) and recovery guidance. Descriptions are generally adequate (average ~120 chars) but lack some specificity around when to use similar tools (e.g., delete_envelope vs discard_envelope distinction). Parameter enums are well-defined (status, role, tag types), and required vs optional is clear via Zod. The code shows no exposed secrets in parameters (credentials passed server-side). Parameter naming is consistent (envelopeId, recipientId), though some descriptions could better explain constraints (e.g., filePath accepts absolute paths, why not relative? What formats?). Composition is sound, tools chain properly (create_envelope → add_recipient → add_signature_tag → send_envelope). Idempotency is not explicitly addressed for write operations.
Add a signer, approver, or CC recipient to an envelope.
Place a signature or form tag on a document. Use placeholder for text-based positioning or coordinates for exact placement.
Cancel a sent envelope. Signers will be notified.
Create a new draft envelope for digital signature. Returns envelope ID for subsequent operations.
Delete a draft envelope. Cannot delete sent/completed envelopes.
Discard a draft envelope. Moves it to discarded state. Use this instead of delete when the API key lacks ROLE_ENVELOPE_DELETE.
Output schemas not documented. Tool responses serialized as JSON strings with no structured schema specification. LLM cannot predict response fields for planning downstream calls.
Error messages lack categorization and recovery guidance. errorResult() returns plain text errors without indicating whether the error is retryable, user-fixable, or fatal. LLM cannot infer next action.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Get DigiSign account info — credits, plan, usage.
Get a temporary download URL (valid 5 min) for signed documents from a completed envelope.
Get detailed information about a specific envelope including status, recipients, documents.
List documents attached to an envelope.
List envelopes with optional status filter. Returns envelope IDs, names, and statuses.
List recipients of an envelope with their signing status.
List signature/form tags on an envelope.
Send a draft envelope for signature. Requires at least one document, one signer, and signature tags placed.
Upload a local file (PDF/DOCX) and attach it to an envelope.
Destructive operations (delete_envelope, discard_envelope, cancel_envelope) lack confirmation/dry-run mechanism. No guard against accidental deletion or cancellation.
No documented output schema structure. Responses returned as JSON strings but LLM cannot see what fields are present (e.g., does get_envelope return status, recipients, documents all together?). This breaks downstream tool chaining predictions.
upload_and_attach_document combines file upload and document attachment in one tool. This violates single-responsibility principle. Should be split into upload_document and attach_document_to_envelope.
add_signature_tag has complex parameter relationships (placeholder + positioning vs documentId + page + xPosition/yPosition) but these dependencies are not formally documented in parameter descriptions. LLM may pass incompatible parameter combinations.
filePath parameter in upload_and_attach_document requires absolute path but description doesn't specify this. Does it accept relative paths? Can it access any filesystem or restricted directories? No clarity.
delete_envelope vs discard_envelope distinction not well explained. Description of discard_envelope says 'use this instead of delete when API key lacks ROLE_ENVELOPE_DELETE' but this is an implementation detail, not a user-facing distinction. What is the semantic difference to an agent?
No idempotency guarantees documented for write operations. If create_envelope is retried, will it create duplicates or return the same envelope ID?
Pagination parameters (page, itemsPerPage) present in list_envelopes but response structure (total count? hasMore? nextPage?) is not documented. LLM cannot reliably paginate.