Skip to main content
Glama

Check homeowner approval

check_approval
Idempotent

Returns whether the homeowner accepted or denied a pending approval request. The interval output field is the minimum wait in seconds before the next check (5 to 60 seconds). Each call records a poll time. Polling sooner than interval returns status slow_down, increases interval by 5 seconds up to 60, and restarts the wait from that poll. It cannot approve or send a job. US only. 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": {
      "approvalId": "<approvalId>"
    },
    "name": "check_approval"
  }
}

Input Schema

NameRequiredDescriptionDefault
approvalIdYesThe approvalId returned by request_approval or send_job_to_contractors.

Output Schema

NameRequiredDescriptionDefault
statusYes
outcomeYesPlain machine-readable result for any approval kind: 'approved_and_done' means the homeowner said yes and InstaBids carried out the request; the same word without _and_done means the homeowner said yes but it is not carried out yet (call the asking tool again with this approvalId if it told you to).
intervalYes
sentenceYesOne plain sentence the assistant can relay to the homeowner.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior4/5

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

The description goes well beyond the annotations by disclosing that every call records a poll time, that early polls return slow_down, that the interval grows by 5 seconds to a 60-second cap, and that the wait restarts from that poll. It also states the tool cannot approve or send anything, which matters because readOnlyHint is false. One tension: idempotentHint is true, yet repeated calls demonstrably change server state (poll time, interval), which the description itself reveals.

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 polling mechanics are useful and should lead, but they are buried under unrelated sequencing instructions for start_job, answer_intake and prepare_publish, plus an off-topic line about telling people you are an AI assistant. Roughly half the text does not help an agent invoke this tool correctly.

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

Completeness3/5

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

Because an output schema exists, the description need not explain return values, yet it helpfully explains the interval field. The behavioral picture for polling is complete, but the description spends much of its length on multi-step workflow rules that belong to other tools rather than on anything an agent needs to call check_approval.

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 100% and the single approvalId parameter already documents that it comes from request_approval or send_job_to_contractors. The description adds nothing about the parameter itself, so the baseline 3 applies.

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 first sentence gives a specific verb and resource: returns whether the homeowner accepted or denied a pending approval request. It is clearly distinguishable from siblings like request_approval or get_job_status. The rest of the description drifts into unrelated workflow routing, which dilutes but does not obscure the core purpose.

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

Usage Guidelines3/5

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

There is real usage guidance for polling: respect the interval, do not check sooner than 5-60 seconds, and expect slow_down if you do. However, most of the guidance ('call start_job before answer_intake, then prepare_publish', 'read the previous reply before calling') describes workflows for other tools rather than when to call check_approval versus an alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources