BizClaw Business Directory MCP

Reply to Proposal

reply_to_proposal

Reply to a company's response on a proposal. Use this for back-and-forth negotiation.
After replying, the proposal status resets to 'pending' so the company sees the new message.

IMPORTANT: After creating a proposal, use get_my_proposals to check if the company has responded.
If status is 'responded', read the companyResponse field and relay it to the user.
If the user wants to reply, use this tool.

Args:
    api_key: Your agent API key (starts with 'bzcl_sk_')
    proposal_id: The UUID of the proposal to reply to
    message: The reply message from the customer

Returns:
    Updated proposal with new status.

Input Schema

TableJSON Schema

Name	Required	Description
`meta`	No	Optional UCP request metadata. Use {'ucp-agent': {'profile': 'https://agent.example/.well-known/ucp'}} for UCP-aware negotiation.
`api_key`	No	Optional BizClaw agent API key starting with bzcl_sk_. If omitted, proposal tools use the X-API-Key MCP connection header when configured.
`message`	Yes	Reply message to send back to the company on an existing proposal conversation.
`proposal_id`	Yes	BizClaw proposal UUID returned by create_proposal, create_batch_proposals, or get_my_proposals.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the annotations (which indicate a mutating, non-idempotent operation), the description reveals a significant side effect: 'the proposal status resets to pending so the company sees the new message.' It also states the return value is an updated proposal, adding useful context without contradicting the annotations.

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

Conciseness4/5

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

The description is well-structured with an opening purpose, an IMPORTANT workflow callout, and an Args/Returns section. It is mostly efficient, but the Args section repeats parameter information already present in the input schema, slightly reducing the score from 5.

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?

The description fully covers the operational workflow, the status-reset side effect, and the return value, and an output schema is available. It does not discuss error cases (e.g., replying when the company has not responded), but the usage guidance mitigates that gap, making it largely complete.

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%, so the schema already documents all parameters. The description largely restates the parameter meanings (e.g., API key prefix, proposal UUID origin) rather than adding new semantics, so the baseline of 3 is appropriate.

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 description opens with a specific verb-resource pair ('Reply to a company's response on a proposal') and explicitly frames it for 'back-and-forth negotiation.' This clearly distinguishes it from sibling tools like create_proposal and get_my_proposals, even without inspecting the schema.

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?

The description gives an explicit workflow: after creating a proposal, use get_my_proposals to check for a response, read the companyResponse field if status is 'responded', and then use this tool when the user wants to reply. This is direct, step-by-step guidance on when to use this tool versus alternatives.

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

All BizClaw Business Directory MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Most tools target clearly distinct actions: searching, retrieving company details, creating proposals, and replying. The main potential confusion is between search_companies and ask_about_companies, and between create_proposal and create_batch_proposals, but their descriptions clarify the intended use cases well.

Naming Consistency4/5

Tool names mostly follow a consistent snake_case verb_noun pattern like search_companies, get_company, create_proposal, and reply_to_proposal. ask_about_companies deviates slightly from the pattern but is still readable and predictable.

Tool Count5/5

Nine tools is well-scoped for a business directory MCP server covering discovery, company lookup, and proposal management. Each tool has a distinct role and no tool feels redundant or unnecessary.

Completeness4/5

The tool surface covers the core workflow well: search companies, get details, create proposals individually or in batch, list proposals, and reply to company responses. Minor gaps exist—such as no explicit cancel/update proposal or direct proposal-by-ID lookup—but these are not blocking for typical usage.

Resources

Need Help?