Docswrite MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DOCSWRITE_TOKEN | Yes | Your Docswrite org API key (dw_live_...) or per-site token (JWT). Required to authenticate with the Docswrite API. | |
| GOOGLE_TOKEN_PATH | No | Path to override where the Google OAuth token is stored (used with the optional Google Docs tools). | |
| DOCSWRITE_API_BASE | No | Overrides the Docswrite API host. Default is https://api.docswrite.com | https://api.docswrite.com |
| GOOGLE_CREDENTIALS_PATH | No | Path to your Google OAuth client credentials JSON file. Required to enable the optional Google Docs tools. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| docswrite-list-connectionsA | List every publishing connection (WordPress, Webflow, Contentful, Shopify, GitHub, Dev.to, Hashnode, Medium, Ghost, hosted blog, X, LinkedIn) of the Docswrite organization this API key belongs to. Returns id, platform, name, status, capabilities, and 'api' (whether it can be published to through this server, which states, and which basic options it takes). Use the ids with docswrite-publish-post. |
| docswrite-publish-postA | Publish a Google Doc to one or more connections of the organization (ids from docswrite-list-connections). Docswrite converts the doc (headings, images, links, tables) and publishes it; one request per connection. state: draft (default), published, or scheduled (with publish_date, optionally timezone). Basic options (tags, categories, canonical_url, excerpt, slug, featured_image_url, author, post_type) apply where the platform supports them; a connection that does not support a given option is skipped with an explanation instead of being published without it. Waits up to wait_seconds for the results and returns each connection's status and live URL (or error). The Google Doc must be readable by the Docswrite user who created the API key. X and LinkedIn cannot be published to through the API. |
| docswrite-list-postsB | List the organization's posts across all connections, newest first: published, scheduled, drafts, in-flight and failed publishes. Each item has id, title, connection {id, platform, name}, status, dates, url and error. |
| docswrite-get-post-statusA | Check a publish started by docswrite-publish-post (job_id) or look up a post (post_id, or an id from docswrite-list-posts). Returns its status (publishing, completed/published, draft, scheduled, failed), live URL and error. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct resource+action: list connections vs. list posts, publish a post vs. check a single post's status. The descriptions explicitly clarify the boundary between docswrite-list-posts (all posts) and docswrite-get-post-status (single job/post lookup), so misselection is unlikely.
All four tools follow a uniform docswrite-<verb>_<noun> pattern (list_connections, publish_post, list_posts, get_post_status) with consistent kebab/underscore convention and verb-first style.
Four tools form a tight, well-scoped set covering discovery, publish, listing, and status polling without redundancy. It is slightly thin—no tools for managing or editing posts after publication—but nothing feels unearned.
The core publish lifecycle is covered: discover connections, publish (with draft/scheduled options), list posts, and poll status. Gaps exist around post lifecycle management (updating, deleting, or unpublishing an existing post), but agents can work around these for the primary publishing workflow.