FreeDailyPro Tools

business_bill_of_sale_draft

Read-onlyIdempotent

Bill of sale draft

Input Schema

Name	Required	Description
`date`	Yes
`item`	Yes
`buyer`	Yes
`price`	Yes
`seller`	Yes
`odometer`	No	Odometer reading for a vehicle.
`warranty`	No	as-is (default) or the seller states it works as described.
`condition`	No
`identifier`	No	Make, model, serial number or VIN.
`governingLaw`	No	Whose law governs, for example "the State of Texas" or "England and Wales". Default: the place where the property or the parties are.
`paymentMethod`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedNov 3, 2026

addedInput schema / properties / condition
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / governingLaw

Added value: +{
+  "description": "Whose law governs, for example \"the State of Texas\" or \"England and Wales\". Default: the place where the property or the parties are.",
+  "maxLength": 120,
+  "type": "string"
+}

addedInput schema / properties / identifier

Added value: +{
+  "description": "Make, model, serial number or VIN.",
+  "type": "string"
+}

addedInput schema / properties / odometer

Added value: +{
+  "description": "Odometer reading for a vehicle.",
+  "type": "string"
+}

addedInput schema / properties / paymentMethod
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / warranty

Added value: +{
+  "description": "as-is (default) or the seller states it works as described.",
+  "enum": [
+    "as-is",
+    "warranty"
+  ],
+  "type": "string"
+}

Changed5 schema fields changedNov 1, 2026
- addedInput schema / properties / buyer / minLength
```
Added value: +1
```
- addedInput schema / properties / date / minLength
```
Added value: +1
```
- addedInput schema / properties / item / minLength
```
Added value: +1
```
- addedInput schema / properties / price / minLength
```
Added value: +1
```
- addedInput schema / properties / seller / minLength
```
Added value: +1
```
First observedOct 23, 2026

TDQS

D1.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. However, the description adds nothing beyond those annotations—no indication that this generates a document, what inputs are required, or what the output contains. The bar is lower with annotations, but this still provides zero behavioral context.

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

Conciseness2/5

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

The description is only four words: technically concise, but under-specified rather than well-structured. It is front-loaded in the trivial sense but contains no useful structure or detail for an agent to act on.

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

Completeness1/5

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

For a document-drafting tool with 11 parameters, multiple required fields, optional vehicle-specific fields like odometer and identifier, and no output schema, the description is completely inadequate. It gives no sense of what the tool produces or how to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 11 parameters with only 36% description coverage, so the description carries substantial responsibility to explain parameter meaning. Instead, it provides no parameter information at all—not even clarification for required fields like seller, buyer, item, price, and date. This is a severe gap for a tool with 5 required and 6 optional fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description "Bill of sale draft" merely restates the tool name and title, adding no verb, scope, or distinguishing detail. An agent cannot tell from this text what the tool actually does beyond the obvious resource label.

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

Usage Guidelines1/5

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives among the many sibling drafting tools such as business_lease_draft or business_nda_draft. The description leaves selection entirely to the name.

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

All FreeDailyPro Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?