Developers · MCP server

Let AI agents work in Qasha, as you.

Qasha’s MCP server gives AI agents twelve tools for documents, signatures, customers and invoices. Every call runs as the colleague whose token the agent carries, through the same rules and access as the workspace.

Connecting

Address: Your Qasha address followed by /api/mcp. It is shown, ready to copy, in Settings → API tokens & agents.
Transport: Streamable HTTP. JSON-RPC 2.0 messages, one or a batch, are sent with POST, and the answers come back as JSON.
Authentication: A personal token, sent as Authorization: Bearer <token>. See personal tokens.
Protocol versions: 2025-06-18 (the default), 2025-03-26 and 2024-11-05.
Methods: initialize, ping, tools/list and tools/call.

With Claude Code:

Terminal

claude mcp add --transport http qasha \
  https://<your-qasha-address>/api/mcp \
  --header "Authorization: Bearer $QASHA_TOKEN"

Clients that read their servers from a JSON file take the address and a header. The usual shape is:

mcp.json

{
  "mcpServers": {
    "qasha": {
      "url": "https://<your-qasha-address>/api/mcp",
      "headers": { "Authorization": "Bearer <your personal token>" }
    }
  }
}

Try it with curl

The server needs no session, so a single request is enough to see the tools:

List the tools

curl -s https://<your-qasha-address>/api/mcp \
  -H "Authorization: Bearer $QASHA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Then call one. Each tool answers with a single text item holding its result as JSON:

Call a tool

curl -s https://<your-qasha-address>/api/mcp \
  -H "Authorization: Bearer $QASHA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"search_documents","arguments":{"status":"sent","limit":5}}}'

Answer

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{ "type": "text", "text": "[ { \"id\": \"…\", \"title\": \"Master services agreement\", \"status\": \"sent\", … } ]" }]
  }
}

Tools

Twelve tools, described to the agent as below. Inputs in bold are required.

Tool	What it does	Inputs
`search_documents`	Finds documents (quotes and contracts) the colleague can see, by words in the title, customer or signers, and by status.	`querystatuskindlimit`
`get_document`	A document in full: its text, signers and where each stands, attachments and dates.	`id`
`create_document`	Creates a draft quote or contract, owned by the colleague. Nothing is sent until send_for_signature.	`titlekindcontentsignerscustomer_id`
`send_for_signature`	Sends a draft to its signers, in order. Each signer is emailed their own link.	`id`
`remind_signers`	Emails a reminder to everyone whose turn it is to sign, at most once a day each.	`id`
`waiting_for_my_signature`	Documents waiting for the colleague to sign, and those they are waiting on.	None
`review_document`	Has the assistant read a document for risky terms and hidden intent, and returns its verdict, summary and flags.	`id`
`list_customers`	Customers (organisations and people), with their contacts.	`query`
`list_invoices`	Invoices, with what is due and their status.	`status`
`create_invoice`	Creates a draft invoice for a customer. Amounts are in major units (dollars, not cents).	`customer_iditemscurrencydue_datenotes`
`send_invoice`	Emails an invoice to its customer with a link to view and pay it.	`id`
`my_notifications`	What has happened to the documents and invoices that concern the colleague.	None

status (documents): draft, sent, viewed, signed, declined or void.
status (invoices): draft, sent, partially_paid, paid, overdue or void.
kind: quote or contract.
content: Markdown: ## headings, paragraphs, - lists and **bold**.
signers: Who signs, in order: each with a name and email, and optionally an order and whether they are internal (your own colleagues).
items: At least one line, each with a description and unit_amount (in major units), and optionally a quantity and tax_percent.

Drafting a document

An agent drafts with create_document, and nothing reaches a customer until it calls send_for_signature. A draft made this way is owned by the colleague, like any draft they write themselves.

tools/call params

{
  "name": "create_document",
  "arguments": {
    "title": "Order form: Northwind",
    "kind": "quote",
    "content": "## Services\nImplementation and support, as discussed.\n\n**Total:** $12,000",
    "signers": [
      { "name": "Ada Obi", "email": "ada@northwind.example", "order": 1 },
      { "name": "Sam Reyes", "email": "sam@yourcompany.example", "order": 2, "internal": true }
    ]
  }
}

What an agent can do

Only what the colleague can. Each tool is an ordinary request of the colleague whose token the agent carries, through the same API, rules and access, so it sees their documents and customers and no others.
Drafts first. Creating a document or an invoice makes a draft. Sending is a separate tool the agent has to call.
Polite reminders. remind_signers reaches each signer at most once a day.
Your model for reviews. review_document uses the assistant your workspace has set up.
Cut off at once. Revoke the token and the next request is refused.

Errors

Code	Meaning
`401`	No live personal token was sent. The answer carries WWW-Authenticate: Bearer.
`405`	The request was not a POST. The server takes Streamable HTTP POST requests only.
`-32700`	The body is not JSON (with HTTP 400).
`-32600`	The message is not a JSON-RPC 2.0 request.
`-32601`	The method is not one the server answers.
`-32602`	There is no tool by that name.
`isError`	The tool ran and failed, for example because the colleague can’t see that document. The reason is in the result’s text.

See an agent work in Qasha.

We’ll connect an agent to a workspace with you and show what it can draft, send and answer.

Book a demo See pricing