InstaBids

Answer a job question

answer_intake

Destructive

Adds the homeowner's answer to one of their unsent draft jobs and returns the next intake question. A job already sent to contractors cannot be changed. US only. Reading the answer can take several seconds. A new answer to the same question replaces the earlier one on the unsent draft. message: up to 2000 characters; zip: 5 digits. bidCardId is the draft from start_job. 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. fill what you can; everything else can come later. Start with the homeowner’s description, trade and ZIP, plus a photo or a good description. Optional: photos, a description or transcript of a 20–60 s walk clip, timing and the job type’s must-haves from intake_templates. Never invent answers. ZIP only; never send a street address or a price. Nothing reaches contractors before the homeowner sends the card.

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": {
      "bidCardId": "<bidCardId>",
      "message": "<message>"
    },
    "name": "answer_intake"
  }
}

Input Schema

Name	Required	Description
`trade`	No	Job trade; generic home repair is allowed.
`message`	Yes	Your description of the job or answer to the latest intake question.
`bidCardId`	Yes	The job id from list_my_jobs
`photoUrls`	No	Optional photos; attachment still requires the existing scan and photo permissions.
`quotes_by`	No	ISO date, or null for no deadline; never a price.
`walk_clip`	No	Description or transcript of a 20–60 s walk clip. This tool does not upload video bytes or fetch video URLs.
`must_haves`	No	Known answers to this job type’s intake_templates must-haves; unknown answers can come later.
`intent_level`	No	10 emergency; 8 soon; 6 planned; 4 if the price is right; 2 someday. Use only evidence from the homeowner.
`deadline_hard`	No
`deadline_reason`	No	Optional reason for the date, without names or contact details.
`idempotency_key`	No	Optional. Reuse the same key to retry a write once; a new key makes a new request. 1-123 characters.
`intent_confidence`	No
`project_completion_deadline`	No	ISO date, or null for no deadline; never a price.

Output Schema

Name	Required	Description
`card`	No
`notice`	Yes
`photos`	No
`status`	Yes
`missing`	Yes	Field keys still required by intake. Empty when no must-haves remain; never inferred from the message.
`notices`	Yes
`bidCardId`	Yes
`readiness`	Yes
`openInAppUrl`	Yes
`statusHandle`	No
`assistantMessage`	Yes
`completionPercentage`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (destructive=true, idempotent=false, openWorld=false), the description discloses that a new answer replaces the earlier one on the unsent draft, that reads can take several seconds, that nothing reaches contractors until the homeowner taps, and that retries reuse an idempotency key. These are non-obvious behavioral traits that materially change how an agent sequences and retries calls.

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 core purpose and workflow are front-loaded well, but the paragraph then mixes operational rules, parameter hints, privacy policy, and a persona instruction ('say you are an AI assistant') into one dense run-on block. The compliance boilerplate is arguably required, yet the ordering makes the actionable call guidance harder to extract.

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?

An output schema exists, so return values need no explanation, and the description covers mutability, sequencing, and safety constraints well. It falls short only on the phantom ZIP parameter and on the duplicated/unexplained deadline fields, which an agent must guess between.

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 coverage is already 85%, and the description does add some meaning (must_haves sourced from intake_templates, walk_clip length and no video bytes, dates are never a price). However it repeatedly references a 'ZIP' input ('zip: 5 digits', 'ZIP only') that does not exist in the schema, which can send an agent looking for a nonexistent field, and it leaves deadline_hard, intent_confidence, quotes_by vs project_completion_deadline unexplained.

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

Purpose5/5

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

The opening sentence states a specific verb and resource: it adds the homeowner's answer to an unsent draft job and returns the next intake question. It also distinguishes itself from named siblings (start_job before, prepare_publish after, other writes needing the previous reply), so an agent can separate it from list_my_jobs or prepare_publish without reading their schemas.

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

Usage Guidelines5/5

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

Usage is explicit and ordered: call start_job first for a new job, answer_intake during intake, prepare_publish once the intake is ready, and for other writes read the previous reply and follow the returned next step. It also states an exclusion (jobs already sent to contractors cannot be changed) and a constraint on which tools may be used, which is exactly the when/when-not guidance an agent needs.

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?