Strunk
Strunk publishes a draft you wrote in Claude, ChatGPT, or Codex out to Google Docs, then brings your reviewers' comments back with the exact spans they…
Что умеет
- Get Writing Rules: Writing rules, style guardrails and voice settings for drafting, writing, authoring, editing, revising or publishing any document, blog post, memo or comment through Strunk. Returns
- Get Review Workflow: The workflow for handling reviewer comments on a published doc: the triage tiers (mechanical / judgment call / needs context), the reply-first → apply → resolve ordering, the plac
- Publish Doc: Publish a new or author-drafted document to Google Docs for human review. The author's own voice rules govern the body you are about to publish; they come back in `voiceRules` on every re
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Strunk publishes a draft you wrote in Claude, ChatGPT, or Codex out to Google Docs, then brings your reviewers' comments back with the exact spans they anchored to. You triage and revise inside the AI tool that already holds your repo and data context, while your reviewers keep commenting in Google Docs. There is no copy and paste, no pull request, and nobody has to adopt a new tool to leave feedback.
Existing comments and their anchors survive a re-publish. Revisions land as targeted edits instead of a full replace, so a thread your reviewer opened last week still points at the text it was about. Google Docs stays the source of truth, and its version history is the revert path.
The tools: publish_doc sends a draft out and re-publishes a revised version. pull_comments brings threads back with their quoted spans and the tab each one sits in. apply_revisions writes approved edits to specific spans. reply_comment and resolve_comment answer and close threads in place. inspect_doc reads the published document back, and pick_google_doc opens a picker to attach a doc you already have.
Your writing rules travel with it. get_writing_rules carries the rules you saved, so the agent has them before it drafts a word. Strunk checks every publish, revision and reply on the way out and hands you the findings: em and en dashes, contrastive antithesis, transition scaffolding, three sentences opening on the same word, one-sentence paragraphs, and hedge words. Switch on Strunk's own guidelines for flabby phrasing, passive voice, intensifiers, and the fancy word where a plain one works. Your spelling variant, serial comma, number style and contractions stay the way you write them.
Strunk never rewrites your text and never blocks a write. It reports what it found and you decide, since the draft goes out under your name. Detection is partial by design, so an empty findings list means it caught nothing rather than that nothing is there.
Hosted, so there is nothing to install and no keys to manage. Connect your Google account, then publish a draft your agent just wrote or attach a Google Doc that already exists, and the round trip runs from there.
Список инструментов сервера (13)
Технические названия из tools/list. Нужны только разработчикам.
| get_writing_rules | Writing rules, style guardrails and voice settings for drafting, writing, authoring, editing, revising or publishing any document, blog post, memo or comment through Strunk. Returns this author's own saved rules and nothing else, so it is short. **Read it before drafting or publishing, not only before reviewing.** The rules are per-author and exist nowhere else: skipping this call means drafting without them. For handling reviewer comments, call get_review_workflow instead. No arguments; returns markdown. |
| get_review_workflow | The workflow for handling reviewer comments on a published doc: the triage tiers (mechanical / judgment call / needs context), the reply-first → apply → resolve ordering, the placeability policy, and what to do with a span that cannot be found. Call it once at the start of a review session, after pull_comments. For the author's writing rules, call get_writing_rules. Served by the connector so every AI tool gets the same judgment with nothing extra to install. No arguments; returns markdown. |
| publish_doc | Publish a new or author-drafted document to Google Docs for human review. The author's own voice rules govern the body you are about to publish; they come back in `voiceRules` on every response, and get_writing_rules returns them before you draft (load that tool if it is not in your list — a search for publishing will not have surfaced it). Use this when the user has drafted content in this AI tool, asks to publish/share/send that draft for review, or clearly wants to create a new review doc. If the user only says they want to work on a doc and it is unclear whether it is new or existing, ask whether they want to draft a new doc or pick an existing Google Doc first. Reusing the same localId re-publishes with a targeted diff that preserves existing reviewer comments. Renders via the Google Docs API (https://developers.google.com/docs/api/reference/rest) — the body is converted from markdown to native Docs formatting, not pasted as raw text. |
| pick_google_doc | Connect an existing Google Doc so its comments can be pulled and revised under a localId. Use when the user says they want to load, open, pick, connect, work on, or pull comments from an existing Google Doc by name, title, URL, or description instead of an explicit Strunk localId. Do not infer the Google Doc from repo filenames; use Picker so the user chooses the exact doc. If the user only says they want to work on a doc and it is unclear whether it is new or existing, ask whether they want to draft a new doc or pick an existing Google Doc first. If no URL is supplied, return a secure Google Picker link. The picker uses the Google Picker API (https://developers.google.com/workspace/drive/picker) so the user chooses the exact doc under the drive.file scope, rather than Strunk being handed a broad Drive listing. |
| pull_comments | Pull reviewer comments back with quoted spans, resolved status, threaded replies, placeability, occurrence, and — on a doc with tabs — which tab the span is in, plus `candidates` (tab + occurrence per copy) for a span that appears in more than one tab, so the author picks a placement instead of the agent guessing one. Use when the user asks what came back, asks to pull comments, or wants to address review feedback for a doc already connected by explicit localId. If the user gives a Google Doc name/title/description, do not guess a localId from repo files; call pick_google_doc first, then pull_comments with that same localId. |
| inspect_doc | Read back the current Google Doc paragraph text, indexes, list state, and named paragraph styles. On a doc with tabs, pass the tabId the edit targeted (apply_revisions reports it) to read back just that tab: indexes are tab-local and repeat across tabs, so checking the first tab confirms nothing about an edit made elsewhere. Without a tabId, every tab is reported under `tabs`. Use after publish_doc or apply_revisions to verify the document landed cleanly before resolving comments or telling the author the revision is done. |
| apply_revisions | Apply author-approved revisions to the doc as direct edits on quoted spans. Unique spans apply directly; ambiguous or not-found results are returned for the author to resolve rather than guessed. See get_review_workflow for the reply → apply → resolve ordering and the post-apply inspection step. |
| reply_comment | Reply to a comment thread in the author's voice, kept short and specific about what changed or what decision is needed. Replying before an edit keeps the acknowledgment anchored to the reviewer's span; get_review_workflow covers the full ordering. |
| resolve_comment | Resolve a comment thread once the author-approved issue has been addressed. Resolving is reserved for comments the author has dispositioned; see get_review_workflow for when to close a thread. |
| get_preferences | Read the author's Strunk preferences before triaging comments. Honor postReplies and autoResolve throughout the review session. |
| set_preferences | Update the author's Strunk preferences. Only fields you pass change. |
| get_account | Report which Strunk account this connector is acting as (email and name) and whether Google Docs is connected. Call it when the author asks who they are signed in as, when a doc or comment unexpectedly isn't visible, or before publishing anything from a connector whose owner is unclear — you only hold an opaque token, so a connector authorized as someone else is otherwise invisible. |
| get_version | Report the running remote MCP backend version. |