list-documents-toolFind documents available to send for electronic signature. Use this to browse what documents the organization has ready to send.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter documents by name (partial match, case-insensitive). | |
| include_archived | No | Include archived documents in the results. Defaults to false. |
| Name | Required | Description | Default |
|---|---|---|---|
| documents | Yes |
Changes observed during successful MCP inspections.
Output schema / properties / documents / items / properties / default_attestation_type / enumPrevious value: -[
- "acknowledgment",
- "signature"
-]New value: +[
+ "signature",
+ "acknowledgment"
+]Output schema / properties / documents / items / properties / app_urlAdded value: +{
+ "type": "string"
+}Output schema / properties / documents / items / properties / edit_urlAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / documents / items / requiredPrevious value: -[
- "id",
- "name",
- "has_published_revision",
- "archived",
- "resource_uri"
-]New value: +[
+ "id",
+ "name",
+ "has_published_revision",
+ "archived",
+ "resource_uri",
+ "app_url"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "documents": {
+ "items": {
+ "properties": {
+ "archived": {
+ "type": "boolean"
+ },
+ "auto_renew": {
+ "type": [
+ "boolean",
+ "null"
+ ]
+ },
+ "default_attestation_type": {
+ "enum": [
+ "acknowledgment",
+ "signature"
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "has_published_revision": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "latest_published_revision_pdf_uri": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "renewal_interval_days": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "resource_uri": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "has_published_revision",
+ "archived",
+ "resource_uri"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "documents"
+ ],
+ "type": "object"
+}Input schema / properties / include_archivedAdded value: +{
+ "description": "Include archived documents in the results. Defaults to false.",
+ "type": "boolean"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the document scope ('available to send for electronic signature') but does not disclose behaviors like pagination, sorting, or the effect of the include_archived flag. With annotations covering safety, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The core purpose is front-loaded, and the usage instruction follows naturally. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the simplicity of the tool (two optional parameters), the description is nearly complete. It covers what the tool does and when to use it. It does not mention the optional filters, but those are in the schema. Minor gap: it doesn't explicitly state that it lists all documents when no filters are provided, but that is implied by 'browse'. A 4 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (name and include_archived) are already documented in the input schema. The description adds no additional parameter semantics, such as how filters combine or the meaning of 'available to send' relative to the filters. Baseline 3 is appropriate when the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find') and resource ('documents available to send for electronic signature'), clearly distinguishing it from sibling tools like search-docs or query-docs. The phrase 'available to send' adds scope beyond just listing all documents, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this to browse what documents the organization has ready to send,' giving a clear usage context. However, it does not mention alternatives or when not to use it (e.g., for searching archived docs or other collections), which would strengthen differentiation from siblings like search-docs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.