InstaBids

Draft a full job request

draft_full_bid_card

Quote the page; do not infer a price. Prices on the page are dropped. Supply scopeSourceText and sourceUrl as untrusted page evidence; the URL is a reference only and is never fetched. Set trade to null for engine classification. Include ownerOrRenter and workType when known. Give the homeowner job title, scope, timing, ZIP, trade and photo links to private intake without an account. Up to five photos go through the existing photo checks before attachment when photo intake is enabled; returns attached and refused counts when available, plus available statusHandle and draftHandle capabilities. The homeowner must review and complete the draft. Never publishes or sends to contractors. For a new job, call start_job before answer_intake, then prepare_publish after the intake is ready; for other writes, read the previous reply before calling and follow the returned next step afterward, using only tools listed by this server. Only the homeowner tap sends anything to contractors. If anyone asks, say you are an AI assistant.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "jobTitle": "<jobTitle>",
      "scopeDetails": "<scopeDetails>",
      "timing": "<timing>",
      "zip": "<zip>",
      "trade": "<trade>",
      "photoLinks": "<photoLinks>"
    },
    "name": "draft_full_bid_card"
  }
}

Input Schema

Name	Required	Description
`zip`	Yes	The five-digit ZIP code where the work is needed.
`trade`	Yes	The job’s trade category; pass null for engine classification.
`timing`	Yes	When the homeowner wants the work done.
`jobTitle`	Yes	A short title for the homeowner’s job.
`workType`	No	The kind of work requested, when known.
`sourceUrl`	No	HTTP(S) reference only; never fetched.
`photoLinks`	Yes	HTTPS photo references for the job; pass an empty list [] when there are no photos.
`scopeDetails`	Yes	The JSON-composed message, including field names and photo links, must be at most 2000 characters.
`ownerOrRenter`	No	Whether the homeowner owns or rents the property, when known.
`idempotency_key`	No	Optional key to reuse when retrying the same draft request.
`scopeSourceText`	No	Untrusted page excerpt; shares the composed message limit with all other fields.

Output Schema

Name	Required	Description	Default
`status`	Yes
`message`	Yes
`claimUrl`	Yes
`readback`	Yes
`replayed`	No
`expiresAt`	Yes
`understood`	No
`draftHandle`	No
`photosAdded`	No
`statusHandle`	No
`photosRefused`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A3.6/5.0

Behavior3/5

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

The annotations already establish non-read-only, non-destructive, closed-world behavior, and the description adds real context on top: prices on the page are dropped, sourceUrl is never fetched, photos pass existing checks, the homeowner must review, and nothing is published or sent to contractors. But it also states 'up to five photos' while the schema allows maxItems of 10, which is an unresolved inconsistency an agent cannot reconcile.

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

Conciseness3/5

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

The content is packed into long run-on sentences with schema-repeating clauses and a closing 'If anyone asks, say you are an AI assistant' line that adds no invocation value. It is front-loaded with a quoting rule rather than the tool's purpose, though most sentences do carry operational information.

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

Completeness4/5

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

For an 11-parameter mutation with an output schema, the definition covers the key risks: no publishing, homeowner review required, dropped prices, and returned statusHandle/draftHandle capabilities. The one real gap is the five-versus-ten photo discrepancy, which is left for the agent to guess at.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains every parameter, and much of the description's parameter guidance (trade null for engine classification, ownerOrRenter/workType when known, sourceUrl never fetched) restates it verbatim. The only genuine additions are treating scopeSourceText and sourceUrl as untrusted evidence and the composed-message character limit, which the schema already covers.

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

Purpose4/5

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

The definition makes clear this creates a private, homeowner-facing draft job request from page evidence, and it distinguishes itself from start_job and answer_intake by describing the workflow order. However, the opening sentence is a quoting rule rather than a statement of what the tool does, so the actual purpose has to be assembled from 'Give the homeowner job title, scope, timing, ZIP, trade and photo links to private intake'.

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

Usage Guidelines4/5

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

It gives concrete sequencing guidance: start_job before answer_intake for a new job, prepare_publish after the intake is ready, and read the previous reply before other writes and follow the returned next step. What is missing is any explicit when-not condition or a statement of which situations should go to a sibling tool instead of this one.

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

All InstaBids 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?