Skip to main content
Proposed — not available yet. These pages describe a design under review. They are unlisted: reachable by link, but not in the navigation or search. The live API is documented under API Reference.
Today the Wordsmith API lets you ask an agent a question, manage tasks, and upload files. This proposal opens up the rest of Wordsmith: playbook reviews, counterparty edits, redlines and comparisons, reports, repositories and knowledge search, legal research, drafting, and usage and value.

What you will be able to build

Review a contract

Run a playbook against an NDA, read the findings, and download a tracked-changes DOCX.

Answer the other side's markup

Triage every tracked change as accept, reject or counter, and get back a response draft.

Transform documents

Compare, redline by instruction, translate, redact, convert, accept changes and merge.

Review hundreds of documents

Extract the same fields from every lease in a repository and export the grid to Excel.

Search your knowledge

Search by meaning across the repositories you can read.

Research the law

Search case law and legislation across jurisdictions, and read the documents.

Draft a document

Fill a blueprint from a term sheet and get a DOCX back.

Administer your organisation

Keep members, roles and teams in sync with your HR or practice systems, and maintain the company profile agents use.

Connect an AI assistant

Use all of this from ChatGPT, Claude or any MCP host, with about two dozen tools.

Three ideas run through the whole design

1

Long work returns an operation

Reviews, redlines, translations and reports take minutes. Every request still has to finish within 29 seconds. So anything that can take longer returns an operation straight away. You poll it, wait on it, or get a callback when it finishes. There is one pattern for every long-running endpoint.
2

Files are the currency

Every input document is a file_id from the files API. Every document Wordsmith produces, such as a redline, a translation or an export, is a new file_id you download the same way. No endpoint takes or returns document bytes inline.
3

The REST API is broad; the MCP server is small

REST has an endpoint for every action, so integrations can do exactly what they need. The MCP server has about two dozen tools shaped around jobs, such as review_document and transform_document. Assistants pick the right tool more reliably from a short list, and every tool calls the same code as its REST endpoints.

A review in three calls

What stays the same

  • Authentication. API keys and OAuth tokens work as today. New areas get new scopes.
  • Existing endpoints. Questions, tasks, files, playbooks and directory routes keep their paths and responses. /templates becomes /blueprints, and the old path keeps working with a deprecation header. Everything new is additive under /api/v1.
  • Errors, pagination and rate limits. The error envelope, {items, cursor} pages and rate limits carry over. Starting an operation has its own limit, described in Long-running operations.

Delivery order

Each phase moves into the API Reference when it is live.