For assistant makers

Last updated October 16, 2026

Usher Up gives your assistant a way to contact a business on a user's behalf: request a quote, book a callback, or open a support ticket. The business receives a handoff with the user's message, a summary of the conversation and a record of the user's consent. This page is the policy you agree to by calling the tool.

Connect

• MCP (Streamable HTTP): https://usherup.com/mcp. One tool, usher_up_contact. No authentication is required today; the business id in each call decides where the handoff goes.
• REST: POST https://usherup.com/v1/contact with the same fields as JSON.
• Find a business: businesses publish their Usher Up id in their llms.txt and in a schema.org ContactPoint on their website. GET https://usherup.com/v1/businesses/{id} returns the public profile: services, prices and hours.

Use with a custom GPT or an agent framework

Everything above is described in an OpenAPI 3.1 document at https://usherup.com/openapi.json. Import it as an action in a custom GPT, or hand it to any agent framework that reads OpenAPI, and you get the usher_up_contact operation with its schema and examples. The document also lists the profile and discovery endpoints.

If your agent browses rather than calls tools, every business also has a contact page at https://usherup.com/b/{business_id} with a plain form that produces the same handoff. Send the user there, or fill it in for them once they have agreed.

Consent comes first

Before calling the tool, tell the user exactly what will be shared (their name, contact details and a summary of this conversation), with whom, and ask for a clear yes. Set consent to true only after that yes. Never infer consent from an earlier message, a profile setting or the fact that the user asked for a recommendation. Requests without consent are rejected and nothing is stored.

Send what the business needs, and no more

• Summarise the conversation factually in a few sentences. What was asked, what was decided, what is still open.
• Leave out anything the business does not need to respond: unrelated topics, other businesses the user considered, and any payment, government ID or password details, which we never want to see.
• If the user shares health, legal or financial details that matter to the request, include only what is necessary and tell the user you are including it.
• Use the user's own words for user_message. Do not embellish.
• Identify yourself in the assistant field so the business knows where the handoff came from.

After the call

Tell the user the handoff was sent, give them the reference id from the response, and explain that the business will reply by the contact method they provided. If the response reports a delivery problem, say so plainly.

If the response has status: "held", the business is on a free plan and has used its free handoffs for the month, so delivery is delayed until it upgrades. You must tell the user this in plain words, and offer the business's phone number and website, which the response includes, so they can reach it directly if they do not want to wait. Never present a held handoff as delivered.

Limits

Each business has a daily cap and the endpoint is rate limited per source. Do not retry a rejected request without changing it. Do not send the same handoff twice. An assistant that sends spam, fabricates consent or ignores these rules will be blocked.

Questions

Use our contact form. We are happy to help you test against the sample business, sample-plumbing, which accepts handoffs and delivers them nowhere real.