Skip to main content
A common question from integrators: can an assistant give my users the same experience as abigail.app, or is MCP a read only feed on the side? It is the same product. The MCP server is a proxy in front of the identical backend the web app calls, so an assistant is not working against a reduced copy of Abigail. What changes is the surface, not the system. A case added by an assistant appears on My Docket. A draft generated in the web wizard is downloadable through MCP. There is no sync step and no second copy of the data.

​
Screen by screen

Every major surface of the web app, and the tool or sequence that reproduces it.

​
Recipe: the morning docket review

What a user does in three clicks on the web, as one turn in an assistant.
1

Read the docket

get_docket for the case list, get_docket_metrics for the counts.
2

Surface what is urgent

get_alerts, then get_case_deadline for any case the user asks about.
3

Open one case

get_case_details for the header, get_claim_analysis for what the examiner actually rejected and why.

​
Recipe: a complete office action response

This is the flow that matters most, and it is fully available. The wizard is a state machine on the backend, so the six tools drive the same steps as the web wizard and produce the same document.
1

Start the wizard

roa_wizard_start with the application number. Returns parsed claims and the rejections to answer.Show the claim text verbatim at this point. It is legal text.
2

Run the experts

roa_wizard_run_experts returns a job id. Poll roa_wizard_expert_status until it completes, then present the proposed strategies per rejection.
3

Let the user choose

roa_wizard_select_strategies with one selection per rejection. This is the step where the assistant earns its place: it can explain each option in conversation, which the web wizard cannot.
4

Generate and deliver

roa_wizard_generate, then poll roa_wizard_status for the download link. The export fee is deducted the same way it is on the web.
Where no human is picking strategies, generate_roa, check_roa_status, and download_roa do the same job unattended.

​
Recipe: a form, then a filing package

1

Pick a template

list_form_templates, then create_form_draft.
2

Fill it from the case

autofill_form populates from case context. get_form_status reads back the values so the assistant can show them for confirmation.
3

Review, then produce the PDF

submit_form_for_review, and after approval generate_form_pdf.
4

Assemble the filing

prepare_filing_package returns the documents, the fee calculation, and step by step Patent Center instructions. The human files. record_filing_receipt stores the confirmation number.

​
Four things that make it feel like the product

Never summarise, condense, or skip a claim. Preserve strikethrough as deleted text, underline as inserted text, every status identifier, the numbering, and the dependency structure. Show cancelled and withdrawn claims too. Add analysis after the complete text, never in place of it. Long output should be batched, never truncated.
When a tool cannot find a case it returns next_actions naming the tool to call next with arguments already filled in, typically add_case. Offering that is the difference between “I could not find it” and the guided path the web app gives.
Expert analysis and document generation are asynchronous. Poll the status tool. Never infer that a job finished, and never compute a USPTO deadline yourself. Deadlines come from the calculator that applies weekend and federal holiday rollover. A wrong date here can abandon an application.

​
What is not available through MCP

Stated plainly so you can scope around it. These exist in the web app and have no tool behind them today: One further limit worth knowing: Abigail never submits to USPTO Patent Center on a user’s behalf. Filing is always a human action.

Connect

Setup and the OAuth handshake.

Tool reference

All 45 tools with their requirements.