Gets information about a document.
Use this tool when:
- You have a document's UUID and want to know more details about it. e.g. who is signing it, what values its dynamic fields or metadata have, etc
Called with no include parameter, returns the document's parties, teams, details, signatories, signing settings and workflow state. Use include to name the sections you want instead - among them dynamic_fields, conditions, metadata_values, signature_blocks, summary_text, tags, timestamps, attachments and stored_files - and the response carries exactly those, so a question about one aspect of a document costs one section rather than the whole document.
The stored_files section holds what the app shows as "Internal file storage", separate from attachments: call them that when talking to the user, never "stored files".
This tool covers a single document. Whenever possible avoid calling it once per document to gather the same information about several documents: list-documents returns parties, teams, tags and timestamps for a whole list via its include parameter, and specific metadata values for a whole list via its include_metadata parameter. Pass the UUIDs you already have to its filter_document_uuids parameter to get exactly the documents you are interested in.
The default response lists both the document's parties (the contracting entities, frequently organizations) and its signatories (the individual people who sign). These are distinct: a person often signs on behalf of a party (e.g. a business) without appearing as a party, so consider the signatories — not just the parties — when answering whether a specific named person is involved in or signs a document.
The dynamic_field_visibility argument narrows the dynamic_fields section to the fields that appear in the document itself, or to the ones that do not. A field belonging to a document is not necessarily written into it: fields get added and then never placed in the text, or the passage that referred to one gets rewritten, leaving a value no reader ever sees. Not every not_visible field is idle, though. Some exist only to drive a condition deciding which clauses the document shows, so they shape the contract without appearing in it (you can use the "conditions" include option to see which fields drive which conditions). Others sit inside a passage that a currently inactive condition removes, so they would appear if that condition flipped. Use "visible" when the question is about what the contract currently says. dynamic_field_visibility has no effect unless dynamic_fields is among the returned sections.
The workflow_state object - in the response by default, and requestable via include alongside other sections - describes what can currently be done with the document: whether the signing process can be started at all, which stages the document can be moved on to and everything standing in the way of each of them (stage_transitions, whose blockers say why), whether the requesting user can start signing, and — when a checkpoint blocks progress — who still needs to approve. Use it to answer questions like "why can't I sign this yet?", "what is blocking this document?" or "who still has to sign?", answering with the full list rather than one problem at a time. It is technical state, not display content: relay it to the user as natural-language prose and never echo raw field names or snake_case values.