Loading ToolBench
A Model Context Protocol (MCP) server that provides SignNow API integration capabilities.
The SignNow MCP server demonstrates moderate quality with consistent naming conventions and basic schema structures, but suffers from significant gaps in parameter descriptions and output documentation. All 15 tools follow verb-noun naming patterns (list_, send_, get_, create_, update_), which is excellent. However, many tools lack comprehensive parameter descriptions, and output schemas are not documented in the visible source. The server uses FastMCP with HTTP transport, which is current, but lacks modern tool annotations (readOnlyHint/destructiveHint/idempotentHint) that would clarify operation semantics. Tool definitions are registered with FastMCP decorators, making them directly visible and not inferred. Critical gaps include missing parameter descriptions for multi-parameter tools (e.g., send_invite's 'orders' array), no documented error handling guidance, and no evidence of pagination support despite list tools that could return large result sets.
Create an embedded document editor
Create an embedded invite for a document or template
Create an embedded sending flow
Create a document from an existing template
Create a new template
Get a download link for a document
Get the status of a sent invite
Output schemas not documented. No evidence of return type specifications in tool definitions. LLMs cannot plan downstream calls or extract chaining IDs (e.g., entity_id for follow-up operations).
Complex parameters lack detailed descriptions. send_invite's 'orders' parameter is described as 'Array of signing orders with recipients' but the structure of each order object is not documented. update_document_fields lacks any parameter description beyond the entity_id.
List tools (list_all_templates, list_documents, list_contacts) provide no pagination support (no limit, offset, page_size, or next_cursor parameters). Without pagination, large result sets will exhaust context windows and degrade agent reasoning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 67 | - | v1 |
List all available templates
List all contacts
List all documents
Send an invite for a document or template
Send a reminder for a previously sent invite
Discovery tool that lists SignNow API capabilities
Update fields in a document
Upload a new document
No tool annotations. Tools that modify state (send_invite, send_invite_reminder, create_*, update_*, upload_*) lack destructiveHint=true. Read-only tools (list_*, get_*) lack readOnlyHint=true. This prevents agents from reasoning about operation reversibility.
No documented error handling or recovery guidance. No evidence of error categorization (retryable vs. user-fixable vs. fatal) or actionable error messages. Agents cannot distinguish recoverable failures from unrecoverable ones.
No idempotency hints or guarantees documented. Tools like send_invite and create_from_template could be retried by agents on ambiguous failures, but idempotency semantics are not declared. Repeated calls risk duplicate invites or duplicate documents.
entity_type parameter inconsistency. Some tools accept 'document' | 'template', others only 'document'. This is not documented as an enum or constraint, forcing LLMs to guess valid values. No tool clearly states what values are accepted.
Tool chaining references missing from responses. If create_from_template returns a document_id, downstream tools like send_invite must accept that document_id as entity_id. No evidence that response fields match parameter names (entity_id in params, but response field unknown).