# Your content, in an AI assistant

The Model Context Protocol server exposes this API as tools, so an assistant can read and write your content directly.

## Install

It speaks stdio, so it runs as a subprocess of the client rather than as a service you host.

## Configure a client

> The key in this file is a secret key with real write authority. Scope it to what the assistant actually needs, and prefer a key created for the assistant alone so you can revoke it without affecting anything else.

## What it can do

The tools are generated from the same `openapi.yaml` this reference is, so the assistant sees exactly the operations documented here, with the same scopes and the same gates. Nothing is available to an assistant that is not available to your own code.

- The Site is resolved from the key, so an assistant cannot reach a Site you did not give it a key for.
- `POST /articles` still only creates drafts. An assistant cannot publish anything without an explicit publish call.
- Pipeline runs still cost credits and still respect your spend cap.
- Anything that publishes, deletes or spends asks you first, and does nothing until you say yes.

| Tool | Calls | Scope | Asks first |
|---|---|---|---|
| verify_api_key | GET | none |  |
| get_site_info | GET | meta:read |  |
| get_content_types | GET | meta:read |  |
| get_usage | GET | meta:read |  |
| list_articles | GET | articles:read |  |
| create_article | POST | articles:write |  |
| get_article | GET | articles:read |  |
| update_article | PATCH | articles:write |  |
| delete_article | DELETE | articles:write | yes |
| publish_article | POST | articles:write | yes |
| unpublish_article | POST | articles:write |  |
| schedule_article | POST | articles:write | yes |
| cancel_article_schedule | POST | articles:write |  |
| list_categories | GET | taxonomy:read |  |
| create_category | POST | taxonomy:write |  |
| get_category | GET | taxonomy:read |  |
| update_category | PATCH | taxonomy:write |  |
| delete_category | DELETE | taxonomy:write | yes |
| list_tags | GET | taxonomy:read |  |
| create_tag | POST | taxonomy:write |  |
| get_tag | GET | taxonomy:read |  |
| update_tag | PATCH | taxonomy:write |  |
| delete_tag | DELETE | taxonomy:write | yes |
| list_authors | GET | authors:read |  |
| create_author | POST | authors:write |  |
| get_author | GET | authors:read |  |
| update_author | PATCH | authors:write |  |
| delete_author | DELETE | authors:write | yes |
| list_media | GET | media:read |  |
| get_media | GET | media:read |  |
| update_media | PATCH | media:write |  |
| delete_media | DELETE | media:write | yes |
| list_pipeline_runs | GET | pipeline:read |  |
| trigger_pipeline_run | POST | pipeline:run | yes |
| get_pipeline_status | GET | pipeline:read |  |
| get_pipeline_queue | GET | pipeline:read |  |
| upload_media |  | media:write |  |
| get_api_docs |  | none |  |

## What it deliberately cannot do

Two parts of the API are not reachable from an assistant at all, whatever scopes the key carries.

## What it never writes down

- Your key is sent to `api.writavo.com` as a bearer header and nowhere else. There is no telemetry and no third-party host.
- The key is masked out of every reply, every log line and every error, including one where the API itself echoed it back.
- The server speaks stdio, so it writes nothing to standard output except protocol messages.