contracts

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

Discloses that analysis is AI-generated and not legal advice, and mentions a usage limit of 2 per day. However, with no annotations, it lacks details on data handling, confidentiality, or any destructive actions. The description adds some value but leaves gaps.

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?

Extremely concise: one sentence plus three short caveats. Every sentence adds value, and the key action is front-loaded. No wasted words.

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?

Despite lacking an output schema, the description adequately conveys the tool's output (risk analysis). It also clarifies limitations (free, not legal advice). Could be more complete with notes on accuracy or error cases, but sufficient for a straightforward analysis tool.

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%, with both parameters (contract_text, focus) already described well in the input schema. The description adds no additional parameter-level meaning beyond what is in the schema, so baseline 3 applies.

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?

Clearly states the verb 'Analyze' and resource 'contract', listing specific outputs: red flags, one-sided clauses, missing protections, and questions. Distinct from sibling tools like check_non_compete_enforceability, which focus on specific aspects.

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 usage context ('Paste contract text', 'Free (2/day)') but does not specify when to use this tool versus alternatives like get_intake_questions or check_non_compete_enforceability. No exclusions or prerequisites mentioned.

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?

With no annotations provided, the description carries the full burden for behavioral transparency. It explains the output (enforceability status, salary thresholds, key statute) and confirms data coverage. It does not describe any side effects, but as a read-only query tool, this is sufficient. No contradictions or missing disclaimers about potential limitations.

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?

The description is brief but complete: two sentences that convey purpose, scope, and output details without any extraneous information. Every sentence serves a purpose.

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 (single parameter, no output schema, no annotations), the description is fully adequate. It covers what the tool does, what it returns, and its data coverage. No additional context is necessary for an agent to select and invoke this tool correctly.

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?

The only parameter 'state' is already well-described in the input schema with examples ('California' or 'california'). The tool description does not add any additional semantic information beyond the schema's description. Since schema coverage is 100%, a baseline score of 3 is appropriate.

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 tool checks enforceability of non-compete agreements in a specific US state, including salary thresholds and key statutes. It mentions data covers all 50 states + DC, and the tool name and title align with this purpose. It is distinct from sibling tools like 'analyze_contract' which likely handle broader contract analysis.

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?

The description implicitly suggests using this tool when you need to check non-compete enforceability by state, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or restrictions. No 'when not to use' or 'see also' references to siblings.

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?

No annotations are provided, so the description carries full burden. It discloses the return type (URL) and purpose, but does not discuss behavior like idempotency, link expiration, or side effects such as marking the draft as pending payment. This is adequate but not comprehensive.

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, front-loaded with the main purpose, no redundant information. Every word is useful.

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 and lack of output schema, the description covers the essential: what it returns, when to use it, and the prerequisite. It lacks details on error conditions (e.g., invalid preview_id) but is complete enough for typical use.

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% for the single parameter, which is well-described in the schema. The description adds the context that the preview_id comes from start_contract_draft, which the schema already implies. No additional meaning beyond the schema is provided.

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 tool returns a URL for preview and payment of a drafted contract, using specific verbs ('Returns', 'Share') and explicitly ties it to start_contract_draft, distinguishing it from sibling tools like analyze_contract or get_draft_status.

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?

The description implies usage after start_contract_draft and for sharing with a user to unlock the contract. It does not explicitly state when not to use it or list alternatives, but the context is clear given the sibling set.

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?

With no annotations, the description carries the full burden. It discloses the 'pending' and 'complete' states and what each returns, including that locked sections require payment. It does not discuss error handling, rate limits, or authentication, but for a simple polling tool, the disclosure is adequate.

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?

The description is two sentences long, front-loaded with the purpose. Every sentence provides essential information: action, usage context, states, and output. No superfluous content.

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 has 1 parameter, no output schema, and no annotations, the description is fairly complete. It covers input, behavior, and output, and references the sibling tool. It could be more explicit about polling behavior, but it is sufficient for an agent to understand and use the tool correctly.

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?

The schema covers 100% of parameters with description and pattern for preview_id. The description adds value by explaining that the parameter comes from start_contract_draft, which is not in the schema. This helps agents understand the source of the parameter.

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 that the tool checks a contract draft started with start_contract_draft, and distinguishes between 'pending' and 'complete' states. It specifies the output: free preview, locked section titles, and a URL. This is specific and differentiates from sibling tools like start_contract_draft and analyze_contract.

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?

The description tells when to use the tool: after calling start_contract_draft. It implies usage for polling by mentioning pending status. However, it does not explicitly state when not to use it or provide alternative tools for similar purposes, such as retrieving a completed contract directly.

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?

No annotations exist, so the description carries the transparency burden. It implies a read-only operation by saying 'Get intake questions' and describes return content, but does not explicitly state non-destructive behavior, authentication needs, or rate limits.

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 with clear front-loading of purpose. Every word adds value; no redundancy or filler.

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 params, no output schema), the description covers the key aspects: what it returns and how it fits into the drafting workflow. Minor gaps like handling empty results or errors do not significantly impair utility.

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%, so baseline is 3. The description does not add parameter details beyond schema descriptions (contract_type and jurisdiction), but it reinforces the context of using contract_type from list_contract_types.

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 tool retrieves intake questions for a specific contract type, explicitly naming the returned elements (fields, types, options, validation rules). It distinguishes from sibling tool start_contract_draft by positioning this as a prerequisite step.

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 explicit usage guidance: use these questions to collect information before calling start_contract_draft. This contextualizes the tool within a workflow but does not mention when to avoid it or compare to other siblings like list_contract_types.

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?

No annotations are provided, so the description carries the full burden. It states the tool returns legal content (statutes, pitfalls, FAQs), implying a read-only operation. It does not mention auth needs or rate limits, but the behavior is sufficiently clear for a non-destructive info tool.

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?

The description is two sentences long, front-loading the purpose (what is returned) and then giving usage instructions. Every sentence is necessary and there is no fluff.

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 no output schema, the description explains the return content in sufficient detail. It covers the purpose and parameter usage well, though it could mention how to obtain valid slugs or any prerequisites. Nonetheless, it is fairly complete for the tool's complexity.

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% with descriptions for both parameters. The description adds value by explaining the usage pattern and providing specific examples (e.g., 'contractor-agreement', 'california'), which clarifies the format beyond the schema alone.

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 tool returns statute-cited legal requirements, key differences, pitfalls, terminology, and FAQs for a contract type in a jurisdiction. It uses specific verbs and resources, and is distinct from sibling tools like 'analyze_contract' or 'check_non_compete_enforceability' by focusing on jurisdiction-specific requirements.

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?

The description tells the user to use contract slug and jurisdiction slug, providing examples. It implicitly guides when to use this tool (when needing jurisdiction-specific legal info), but does not explicitly contrast with siblings like 'check_non_compete_enforceability', though the purpose is clear enough.

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?

With no annotations provided, the description carries full burden and clearly states the tool lists (a read-only operation) and specifies the output includes descriptions, use cases, and prices, which is transparent about behavior and output.

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: first states the action and content, second provides guidance. Every word is functional, no redundancy.

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 zero-parameter list tool without an output schema, the description fully covers what the tool does, what it returns, and why it is useful in the context of sibling 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% due to zero parameters, so baseline is 3. The description adds value by explaining the tool's output (descriptions, use cases, prices) and its utility (finding slug/id), elevating the score above baseline.

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 tool lists all contract and legal document types with descriptions, use cases, and prices, and indicates it serves as an entry point for finding slugs/IDs, distinguishing it from sibling tools like analyze_contract or start_contract_draft.

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?

The description explicitly advises to 'start here' to find the right contract type slug/id for other tools, providing clear context for when to use this tool. It does not explicitly mention when not to use it or alternatives, but given the sibling tools, the guidance is sufficient.

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?

With no annotations, the description carries the full burden. It discloses timing (3-5 minutes), immediate return of preview_id, async polling, and the checkout gate for full contract. Could mention error conditions or idempotency but covers key behaviors well.

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?

The description is front-loaded with the main action and uses multiple sentences, each providing necessary detail. Could be slightly more concise but every sentence serves a purpose.

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 no output schema, the description fully explains the return value (preview_id) and follow-up action (poll get_draft_status). It integrates with sibling tools and covers the preview/unlock mechanism. No gaps for the tool's complexity.

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% and each parameter has a description. The description adds value by explaining that deal_summary must come from get_intake_questions and specifying minimum required fields. This provides context beyond the schema alone.

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 it starts generating a contract draft using an AI engine. It references specific sibling tools (get_draft_status, get_intake_questions) to distinguish its role in the workflow, making its 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?

Provides explicit guidance: prerequisites (use get_intake_questions to collect deal_summary), expected flow (poll get_draft_status), and what the free preview vs full contract entails. Explains the asynchronous behavior and unlocking mechanism.

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