quicksign

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

While annotations declare readOnlyHint=true, the description adds crucial behavioral context missing from structured fields: it specifies the return format ('full markdown/text content along with metadata'), which compensates for the lack of an output schema. It also clarifies this operates on 'previously pushed' drafts.

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?

Three efficient sentences with zero waste. Front-loaded with the core action, followed by usage context, and closing with return value description. Every clause 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?

For a simple single-parameter read operation with good annotations, the description is complete. It compensates for the missing output schema by describing return values, explains the domain context (QuickSign drafts), and provides usage scenarios.

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?

With 100% schema description coverage, the schema already fully documents the 'id' parameter ('The AI Session ID...'). The description adds domain context ('QuickSign session/document ID') but does not provide additional syntax, format constraints, or semantic details beyond the schema.

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 opens with a specific verb ('Retrieve'), clear resource ('full text content of a previously pushed draft'), and scope ('by its session ID'). It effectively distinguishes from siblings by emphasizing content retrieval versus status checks (get_draft_status) or creation (push_draft_text).

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?

Provides clear when-to-use guidance ('when you have a QuickSign session/document ID and need to read the current draft text') with concrete examples ('revise a contract, check what was previously sent'). However, it does not explicitly name sibling alternatives (e.g., 'use get_draft_status instead for status checks').

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

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

Annotations declare readOnlyHint=true/destructiveHint=false (safe read), so description adds value beyond safety by detailing the three specific status components returned (session states, lifecycle states, template conversion flags). Documents the state machine values (active/completed, draft/ready/pending/completed/cancelled) that annotations cannot convey. No contradictions with annotations.

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?

Three sentences with zero waste. Front-loaded with action (Check), followed by detailed return specification, closed with usage example. Every sentence earns its place—no tautology, no filler. Appropriate density for the information conveyed.

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?

No output schema exists, so description compensates by thoroughly documenting return structure (three specific data points with their possible values). With simple 2-parameter input and clear annotations, the description provides complete coverage of what the agent needs to know to interpret results (status chains, template conversion flags).

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 coverage is 100% (both params fully documented), establishing baseline 3. Description adds valuable workflow context: implies 'id' parameter comes from push_draft_text return value ('draft you previously pushed'), helping agent understand the parameter source. Also reinforces 'type' parameter domain by mentioning QuickSign's handling of PDF vs text drafts in the system context.

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?

Clear specific verb (Check) + resource (full status chain of document draft in QuickSign). Explicitly details what gets returned (session status, lifecycle status, template conversion). Implicitly distinguishes from siblings by context: 'follow up on a draft you previously pushed' positions it after push_draft_text, while 'status' differentiates it from get_draft_content (content) and get_handoff_link (link).

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?

Explicit when-to-use with concrete scenario: 'Use this to follow up on a draft you previously pushed' with practical example ('has the owner reviewed that NDA yet?'). Provides clear temporal context (follow-up action). Lacks explicit 'when-not-to-use' or named alternatives (e.g., 'use get_draft_content for content retrieval'), but the example strongly implies appropriate usage context.

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

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

Annotations establish readOnly/destructive safety profile. Description adds valuable behavioral context beyond annotations: explains the URL opens the QuickSign editor and details the specific user capabilities enabled (review, add recipients, place fields, send). No contradictions with annotations.

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 sentences, zero waste. First sentence establishes purpose and resource. Second sentence explains return value and usage workflow. Perfectly front-loaded with no redundant information.

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 tool's simplicity (2 simple parameters, no nested objects, good annotations, no output schema), the description is complete. It explains what the tool returns (URL), what it does (opens editor), and the workflow (share with user for specific actions).

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% ('The document ID...', 'Whether this was a PDF or text draft'), so the schema carries the full semantic load. Description mentions 'document owner' and 'review' but does not add parameter-specific guidance beyond the schema, warranting baseline 3.

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?

Clear specific verb ('Get') + resource ('direct link') + context ('for the document owner to review a draft in QuickSign'). Effectively distinguishes from siblings: get_draft_content retrieves content, get_draft_status retrieves status, while this specifically retrieves a review/handoff link for user interaction.

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?

Explicit usage guidance: 'Share this with the user so they can review the contract, add recipients, place signature fields, and send it.' Clearly scopes usage to scenarios requiring user review/action in the editor. Lacks explicit mention of alternatives (e.g., when to use get_draft_content instead), preventing a 5.

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

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

Annotations indicate non-destructive write operations (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context: the review workflow (owner reviews, adds recipients, places fields), the 500,000 character limit, and format recommendations (markdown preferred) that are not captured in annotations.

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?

Well-structured with logical flow: purpose → supported types → workflow → usage conditions → technical constraints. Every sentence adds distinct value, though the paragraph describing the workflow could be slightly more terse.

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?

Comprehensive for the input side given 100% schema coverage and detailed workflow description. No output schema exists, and the description omits what the tool returns (e.g., draft ID), which would be helpful given the sibling retrieval tools.

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 coverage is 100%, establishing baseline clarity. The description adds critical constraint information not in the schema: the 500,000 character maximum for content and the recommendation to use markdown format for best results.

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 clearly states the core action ('Send a contract or agreement to QuickSign for e-signature') with specific examples (NDA, freelance agreement, consulting contract, SOW) that distinguish it from the 'get_' siblings which are retrieval operations.

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?

Explicitly states when to use ('Use this whenever a user needs to get a document signed...') providing clear triggering conditions. Lacks explicit 'when-not' guidance or named alternatives, though the workflow steps imply it's for drafting prior to final signature.

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