Google Docs API 작업을 위한 결정론적 컴파일러입니다.
batchUpdate 요청을 직접 구성하여 Google 문서를 안전하게 수정하는 것은 불가능합니다. API는 계단식 인덱스 이동이 포함된 UTF-16 코드 단위를 사용합니다. 예를 들어 위치 50에 10자를 삽입하면, 그 이후의 모든 배치 인덱스가 틀어지게 됩니다. 단 한 번의 계산 착오만으로도 오류 메시지 없이 문서가 조용히 손상될 수 있습니다.
Arezzo는 의미론적 의도를 올바른 요청 시퀀스로 컴파일합니다. 수행하려는 작업을 알려주기만 하면 인덱스 산술은 Arezzo가 처리합니다.
Arezzo는 Model Context Protocol을 통해 세 가지 도구를 노출합니다.
read_document(document_id)
→ Returns the document's structural map: headings with hierarchy,
named ranges, tables, section boundaries. Call this before editing
so you know what addresses are available.
edit_document(document_id, operations)
→ Compiles operations into correct batchUpdate requests and executes
them. Handles UTF-16 arithmetic, cascading index shifts, and
OT-compatible request ordering. Supported operations: insert/delete/
replace text, formatting (bold, italic, headings, links), tables,
lists, images, headers/footers, footnotes, named ranges.
validate_operations(document_id, operations)
→ Compile-only dry run. Returns the compiled requests for inspection
without executing. Use before edit_document when uncertain.{
"type": "insert_text",
"address": {"heading": "Revenue Analysis"},
"params": {"text": "New paragraph content.\n"}
}주소 모드:
{"heading": "Section Name"} — 제목 텍스트 기준
{"named_range": "range_name"} — 명명된 범위 기준
{"bookmark": "bookmark_id"} — 책갈피 ID 기준
{"start": true} — 문서 시작
{"end": true} — 문서 끝
{"index": 42} — 절대 UTF-16 인덱스
작업 유형:
insert_text, delete_content, replace_all_text, replace_section,
update_text_style, update_paragraph_style, insert_bullet_list,
insert_table, insert_table_row, insert_table_column,
delete_table_row, delete_table_column, insert_image,
create_header, create_footer, create_footnote,
create_named_range, replace_named_range_content, insert_page_break
read_document → edit_document → (if structural changes) read_document → edit_document편집하기 전에 항상 읽기 작업을 수행하세요. 구조적 요소(표, 머리글, 바닥글)를 삽입한 후에는 그 안에 콘텐츠를 추가하기 전에 다시 읽어 새로운 요소 인덱스를 가져와야 합니다.
Related MCP server: google-docs-mcp
pip install arezzo
arezzo initarezzo init은 Google OAuth 설정을 안내하고 MCP 클라이언트를 위한 플랫폼 구성 파일을 작성합니다.
전제 조건: Google Docs API가 활성화된 Google Cloud 프로젝트와 OAuth 2.0 클라이언트 ID(데스크톱 애플리케이션 유형)가 필요합니다.
arezzo init마법사 기능:
credentials.json을 ~/.config/arezzo/로 복사합니다.
OAuth 동의 흐름을 실행합니다(브라우저가 한 번 열립니다).
Claude Code, Cursor 및 VS Code용 구성 파일을 생성합니다.
Claude Desktop의 경우, arezzo init이 수동으로 추가할 구성 블록을 출력합니다.
arezzo init 이후, 프로젝트 디렉토리에 구성 파일이 작성됩니다:
Claude Code / Cursor (.mcp.json):
{
"mcpServers": {
"arezzo": {
"command": "arezzo"
}
}
}VS Code (.vscode/mcp.json):
{
"servers": {
"arezzo": {
"type": "stdio",
"command": "arezzo"
}
}
}Claude Desktop (macOS의 경우 ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"arezzo": {
"command": "arezzo"
}
}
}Google Docs batchUpdate API는 절대 인덱스 위치를 가진 UTF-16 코드 단위에서 작동합니다. 문자 삽입이나 삭제가 발생할 때마다 이후의 모든 인덱스가 이동합니다. 여러 번의 변경이 포함된 배치 작업에서는 각 요청의 인덱스가 동일한 배치 내의 이전 모든 요청의 영향을 고려해야 합니다.
이를 올바르게 처리하려면 다음이 필요합니다:
UTF-16 길이 계산 (Python len()이 아님 — 서로게이트 쌍은 다르게 계산됨)
동일 유형 변경에 대한 역순 실행 (끝에서 시작 방향으로 삭제)
2단계 컴파일 (형식 변경 전 콘텐츠 변경)
다단계 작업 전반에 걸친 계단식 오프셋 추적
Arezzo는 이를 결정론적으로 처리합니다. 동일한 입력은 항상 동일한 출력을 생성합니다. 추론도, 추측도, "대체로 작동하는" 방식도 없습니다.
semantic operation
↓
arezzo.parser.parse_document() — build heading/range/bookmark indexes
↓
arezzo.address.resolve_address() — semantic reference → document index
↓
arezzo.operations.* — operation → batchUpdate request(s)
↓
arezzo.index.sort_requests() — OT-compatible mutation ordering
↓
correct batchUpdate request sequence엔진은 순수 함수입니다: compile_operations(doc, operations) → requests. 결정론적이며 부작용이 없고 API 호출이 없습니다.
MCP 서버(arezzo.server)는 Google Docs API I/O 및 동작 안내 필드(next_step, present_to_user, document_reality)를 사용하여 엔진을 래핑합니다.
MIT — Convergent Methods, LLC
Make changes to a Google Doc with correct index arithmetic.
You cannot safely modify a Google Doc by constructing batchUpdate
requests yourself. The API uses UTF-16 code units with cascading index
shifts — insert 10 characters at position 50, and every subsequent
index in your batch is wrong. A single miscalculation silently corrupts
the document with no error message. This tool compiles your semantic
intent into a correct request sequence.
**Recommended flow:** call read_document first, then describe your
changes using heading names or named ranges as addresses.
Valid operation types: insert_text, delete_content, replace_all_text,
replace_section, update_text_style, update_paragraph_style,
create_paragraph_bullets, convert_to_list, insert_table,
insert_table_row, insert_table_column, delete_table_row,
delete_table_column, insert_bullet_list, insert_numbered_list,
insert_page_break, insert_inline_image, create_header, create_footer,
create_footnote, create_named_range, delete_named_range,
replace_named_range_content.
Args:
document_id: The Google Docs document ID.
operations: List of operation dicts. Each has:
- type: one of the operation types listed above
- address: target location ({"heading": "Budget"}, {"start": true}, etc.)
- params: operation-specific parameters
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | ||
| operations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains critical behavioral traits: the tool prevents index miscalculation issues that could silently corrupt documents, compiles semantic intent into correct sequences, and lists all valid operation types. This goes well beyond basic functionality disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured with clear sections: problem context, recommended flow, operation types, and parameter documentation. While comprehensive, every sentence adds value, though the operation type list is lengthy but necessary for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides exceptional completeness. It covers the why (index arithmetic dangers), how (recommended flow), what (operation types), and parameter details. The only minor gap is lack of explicit error handling information, but this is compensated by the thorough behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters in detail. It defines document_id as 'The Google Docs document ID' and provides comprehensive documentation for the operations parameter structure, including the type field with all valid values, address field examples, and params field purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Make changes to a Google Doc' with specific details about handling index arithmetic and compiling semantic intent into correct request sequences. It distinguishes from sibling tools by mentioning read_document as part of the recommended flow and implicitly contrasting with validate_operations by focusing on execution rather than validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'call read_document first, then describe your changes using heading names or named ranges as addresses.' It also implicitly advises against manual batchUpdate construction by explaining the risks, effectively stating when not to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
See what the document contains before you edit it.
Returns the document's structural map — headings with hierarchy, named
ranges with boundaries, tables with dimensions, inline objects, and
section boundaries. Without this, you're editing blind: you don't know
what headings exist, where sections start, or what named ranges are
available for targeting.
**Call this before edit_document.** The structural map shows what
addresses are available (heading names, named range names) so your edit
operations target the right locations.
Args:
document_id: The Google Docs document ID (from the URL).
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes what the tool returns ('structural map — headings with hierarchy, named ranges with boundaries, tables with dimensions, inline objects, and section boundaries') and explains the operational context ('so your edit operations target the right locations'). However, it doesn't mention potential limitations like document size constraints or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficiently written. The first sentence states the core purpose, followed by specific details about the return value, then the operational guidance. Every sentence adds value, with no redundant information. The bold text effectively emphasizes the key usage instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description provides excellent context about what the tool does, when to use it, and what it returns. However, without an output schema, the description could benefit from more detail about the exact format of the structural map return value, though it does list the key components that will be included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation. It provides the single parameter 'document_id' with clear semantics ('The Google Docs document ID from the URL'), which fully covers the one required parameter. The description doesn't need to explain parameter format beyond what's already stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('see what the document contains', 'returns the document's structural map') and resources ('document', 'headings', 'named ranges', 'tables', 'inline objects', 'section boundaries'). It explicitly distinguishes from the sibling edit_document by explaining this is for viewing structure before editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Call this before edit_document' and explains why ('Without this, you're editing blind'). It also mentions the alternative edit_document by name and explains the relationship between the tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether edit operations would succeed without executing them.
Returns the compiled batchUpdate requests plus validation status. Use
this when you want to inspect the exact API calls before they execute,
or when debugging why an edit might fail. Catches address resolution
errors, ambiguous headings, out-of-bounds indices, and invalid
operation parameters.
**Use this before edit_document when uncertain.** Shows exactly what
Arezzo would send to the Google Docs API.
Args:
document_id: The Google Docs document ID.
operations: List of operation dicts (same format as edit_document).
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | ||
| operations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it's a validation-only tool that doesn't execute changes, returns compiled batchUpdate requests and validation status, and catches specific error types (address resolution errors, ambiguous headings, etc.). It could improve by mentioning rate limits or auth needs, but covers core behavior adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. Every sentence adds value: the second explains returns and use cases, the third details error types, and the fourth provides explicit usage guidance. The Args section efficiently clarifies parameters without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 0% schema coverage and no output schema, the description does an excellent job explaining inputs and behavior. It falls short of a 5 because it doesn't fully describe the return format (e.g., structure of validation status) or potential error responses, which would be helpful despite no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It adds significant meaning beyond the bare schema by explaining both parameters: 'document_id' is clarified as 'The Google Docs document ID' and 'operations' as 'List of operation dicts (same format as edit_document)', providing crucial context about format and relationship to sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('check whether edit operations would succeed without executing them') and distinguishes it from siblings by explicitly mentioning 'edit_document' as the alternative for actual execution. It specifies the resource (edit operations on Google Docs) and the unique validation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when you want to inspect the exact API calls before they execute, or when debugging why an edit might fail') and when not to use it (implied by suggesting use before 'edit_document when uncertain'). It clearly names the alternative sibling tool ('edit_document') for actual execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: read_document retrieves structure, edit_document applies changes, and validate_operations validates changes without execution. There is no overlap in functionality, and the descriptions explicitly differentiate their roles in the workflow.
All tool names follow a consistent verb_noun pattern (edit_document, read_document, validate_operations) with clear, descriptive verbs. The naming is uniform and predictable across the set, enhancing usability.
With 3 tools, the server is well-scoped for its purpose of safe Google Docs editing. Each tool earns its place by covering essential steps: reading, validating, and editing, with no redundancy or missing core functions.
The tool set provides complete coverage for the domain of safe document editing: read_document for inspection, edit_document for modifications, and validate_operations for pre-execution checks. There are no gaps, and the tools support a full workflow from start to finish.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Composable APIs for document extraction, image transformation, and document & sheet generation.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
Markdown in, any format out. PDFs merged, split, watermarked. Runs on our own doc engines.
Real .docx and .xlsx files from structured data, with automatic Hebrew/Arabic RTL.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ConvergentMethods/arezzo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
