Skip to main content
Glama

update_document_fields

Modify text fields in multiple SignNow documents by specifying document IDs and field values to update.

Instructions

Update text fields in multiple documents (only individual documents, not document groups)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
update_requestsYesArray of document field update requests

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYesArray of update results for each document

Implementation Reference

  • Core handler function _update_document_fields that loops through update requests and calls the SignNow API client.prefill_text_fields for each document.
    def _update_document_fields(client: SignNowAPIClient, token: str, update_requests: list[UpdateDocumentFields]) -> UpdateDocumentFieldsResponse:
        """
        Update fields for multiple documents.
    
        This function updates text fields in multiple documents using the SignNow API.
        Only text fields can be updated using the prefill_text_fields endpoint.
    
        Args:
            client: SignNow API client instance
            token: Access token for authentication
            update_requests: List of UpdateDocumentFields with document IDs and fields to update
    
        Returns:
            UpdateDocumentFieldsResponse with results for each document update
        """
    
        results = []
    
        for update_request in update_requests:
            try:
                # Convert FieldToUpdate to PrefillTextField format
                prefill_fields = []
                for field in update_request.fields:
                    prefill_fields.append({"field_name": field.name, "prefilled_text": field.value})
    
                # Create PrefillTextFieldsRequest
                from signnow_client.models.templates_and_documents import (
                    PrefillTextField,
                    PrefillTextFieldsRequest,
                )
    
                prefill_request = PrefillTextFieldsRequest(fields=[PrefillTextField(field_name=field.name, prefilled_text=field.value) for field in update_request.fields])
    
                # Update fields using the client
                success = client.prefill_text_fields(token=token, document_id=update_request.document_id, request_data=prefill_request)
    
                results.append(UpdateDocumentFieldsResult(document_id=update_request.document_id, updated=success, reason=None))  # No reason needed for success
    
            except Exception as e:
                # Log error and mark as failed
                error_message = str(e)
                print(f"Failed to update fields for document {update_request.document_id}: {error_message}")
                results.append(UpdateDocumentFieldsResult(document_id=update_request.document_id, updated=False, reason=error_message))
    
        return UpdateDocumentFieldsResponse(results=results)
  • MCP tool registration and thin handler wrapper that authenticates and delegates to the core _update_document_fields implementation.
    @mcp.tool(
        name="update_document_fields",
        description="Update text fields in multiple documents (only individual documents, not document groups)",
        tags=["document", "fields", "update", "prefill"],
    )
    def update_document_fields(
        ctx: Context,
        update_requests: Annotated[
            list[UpdateDocumentFields],
            Field(
                description="Array of document field update requests",
                examples=[
                    [
                        {
                            "document_id": "abc123",
                            "fields": [
                                {"name": "FieldName1", "value": "New Value 1"},
                                {"name": "FieldName2", "value": "New Value 2"},
                            ],
                        },
                        {
                            "document_id": "def456",
                            "fields": [{"name": "FieldName3", "value": "New Value 3"}],
                        },
                    ],
                ],
            ),
        ],
    ) -> UpdateDocumentFieldsResponse:
        """Update text fields in multiple documents.
    
        This tool updates text fields in multiple documents using the SignNow API.
        Only text fields can be updated using the prefill_text_fields endpoint.
    
        IMPORTANT: This tool works only with individual documents, not document groups.
        To find out what fields are available in a document or document group,
        use the get_document tool first.
    
        Args:
            update_requests: Array of UpdateDocumentFields with document IDs and fields to update
    
        Returns:
            UpdateDocumentFieldsResponse with results for each document update
        """
        token, client = _get_token_and_client(token_provider)
    
        # Initialize client and use the imported function from document module
        return _update_document_fields(client, token, update_requests)
  • Pydantic schema definitions for input (UpdateDocumentFields containing list of FieldToUpdate) and output (UpdateDocumentFieldsResponse with list of results).
    class FieldToUpdate(BaseModel):
        """Single field to update in a document."""
    
        name: str = Field(..., description="Name of the field to update")
        value: str = Field(..., description="New value for the field")
    
    
    class UpdateDocumentFields(BaseModel):
        """Request model for updating document fields."""
    
        document_id: str = Field(..., description="ID of the document to update")
        fields: list[FieldToUpdate] = Field(..., description="Array of fields to update with their new values")
    
    
    class UpdateDocumentFieldsResult(BaseModel):
        """Result of updating document fields."""
    
        document_id: str = Field(..., description="ID of the document that was updated")
        updated: bool = Field(..., description="Whether the document fields were successfully updated")
        reason: str | None = Field(None, description="Reason for failure if updated is false")
    
    
    class UpdateDocumentFieldsResponse(BaseModel):
        """Response model for updating document fields."""
    
        results: list[UpdateDocumentFieldsResult] = Field(..., description="Array of update results for each document")
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation) and clarifies it works on individual documents only, but doesn't mention permissions required, whether changes are reversible, rate limits, error handling, or what happens to fields not specified. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core functionality and a key limitation. Every word earns its place - 'Update text fields in multiple documents' establishes the action, and '(only individual documents, not document groups)' adds necessary context without redundancy. It's appropriately front-loaded with the main purpose.

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

Completeness3/5

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

Given this is a mutation tool with no annotations but with a rich input schema (100% coverage) and an output schema exists, the description is moderately complete. It covers the basic operation and scope limitation, but for a tool that modifies multiple documents, it should ideally mention permissions, side effects, or error handling. The existence of an output schema means return values are documented elsewhere, but behavioral aspects remain under-specified.

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 description coverage is 100%, so the schema already fully documents the single parameter 'update_requests' and its nested structure. The description adds no additional parameter information beyond what's in the schema - it doesn't explain field naming conventions, value constraints, or batch size limits. With high schema coverage, the baseline score of 3 is appropriate.

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 clearly states the verb ('Update') and resource ('text fields in multiple documents'), making the purpose evident. It distinguishes from potential alternatives by specifying 'only individual documents, not document groups', though it doesn't explicitly name sibling tools. This is clear but lacks direct sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'only individual documents, not document groups' which hints at a limitation, but doesn't explain when to choose this over other document-related tools like 'get_document' or 'create_from_template'. No explicit when/when-not instructions or named alternatives are provided.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/signnow/sn-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server