doc-control

Overview Schema Source Related Servers Discussions Admin

text_normalize

Read-onlyIdempotent

Normalize text (NFC, strip soft hyphens/zero-width, collapse whitespace) and return a two-way offset map to original code points for robust search and mapping offsets back to addresses.

Instructions

Normalise text (NFC, soft hyphens and zero-width characters removed, whitespace collapsed) and return a two-way offset map to the original code points, for the whole document, one paragraph or range (at, p142#a7b2a7b2:10-15), or a text string (give doc or text). Use it to compare or search text robustly and map found offsets back to addresses for text.replace; para.list normalized adds just the text. Read-only; paged at about 8,000 bytes with cursor; a very long paragraph comes in parts.

Input Schema

TableJSON Schema

Name	Required	Description
`at`	No	Paragraph address or range, e.g. p142#a7b2a7b2:10-15.
`doc`	No	Path to a .docx.
`text`	No	Text to normalise instead of `doc`.
`limit`	No	Most items to return; a response is also capped at about 8,000 bytes.
`cursor`	No	The `next` value of the previous response, to continue the list.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Always true on success.
`op`	Yes	The operation that ran.
`api`	Yes	API version (1.0).
`doc`	No	The document read or written: path, sha256 and paragraph count.
`next`	Yes	Cursor for the next page (pass as cursor), or null.
`result`	Yes	What the operation returns.
`warnings`	Yes	Things to know about the result.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.2Oct 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "api": {
+      "description": "API version (1.0).",
+      "type": "string"
+    },
+    "doc": {
+      "description": "The document read or written: path, sha256 and paragraph count.",
+      "properties": {
+        "characters": {
+          "description": "text.normalize of a text string: its length.",
+          "type": "integer"
+        },
+        "paragraphs": {
+          "description": "Body paragraphs.",
+          "type": "integer"
+        },
+        "path": {
+          "description": "Path of the document.",
+          "type": "string"
+        },
+        "sha256": {
+          "description": "sha256 of the file (pass as expect.sha256 to a write).",
+          "type": "string"
+        },
+        "source": {
+          "description": "A .txt/.md/.odt source's format, encoding and split mode; \"text\" for a text string (text.normalize).",
+          "type": [
+            "object",
+            "string"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "next": {
+      "description": "Cursor for the next page (pass as cursor), or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ok": {
+      "description": "Always true on success.",
+      "type": "boolean"
+    },
+    "op": {
+      "description": "The operation that ran.",
+      "type": "string"
+    },
+    "result": {
+      "description": "What the operation returns.",
+      "properties": {
+        "paragraphs": {
+          "description": "This page of entries.",
+          "items": {
+            "description": "One paragraph, or one part of a very long one.",
+            "properties": {
+              "at": {
+                "description": "Paragraph address (absent for `text`).",
+                "type": "string"
+              },
+              "from": {
+                "description": "Normalised offset where this entry's text begins.",
+                "type": "integer"
+              },
+              "offset_map": {
+                "description": "Two-way offset map, as runs [index, value, count] or [index, value, count, 0].",
+                "properties": {
+                  "to_normalized": {
+                    "description": "Original -> normalised offsets.",
+                    "items": {
+                      "type": "array"
+                    },
+                    "type": "array"
+                  },
+                  "to_original": {
+                    "description": "Normalised -> original offsets.",
+                    "items": {
+                      "type": "array"
+                    },
+                    "type": "array"
+                  }
+                },
+                "type": "object"
+              },
+              "part": {
+                "description": "Part k of a split paragraph.",
+                "type": "integer"
+              },
+              "parts": {
+                "description": "Parts the paragraph was split into.",
+                "type": "integer"
+              },
+              "start": {
+                "description": "Where the entry's text begins in the paragraph's visible text.",
+                "type": "integer"
+              },
+              "text": {
+                "description": "Normalised text.",
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "total": {
+          "description": "Paragraphs (or text strings) in the selection.",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "total",
+        "paragraphs"
+      ],
+      "type": "object"
+    },
+    "warnings": {
+      "description": "Things to know about the result.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "api",
+    "ok",
+    "op",
+    "result",
+    "warnings",
+    "next"
+  ],
+  "type": "object"
+}

Addedv0.1.3Oct 15, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/closed-world, but the description adds real operational detail: paging at ~8,000 bytes with `cursor`, and that long paragraphs are returned in parts on CLI/MCP. It doesn't detail failure modes or limits interaction, so it's strong but not complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and effect, then consumer guidance, then paging. It is dense and somewhat run-on in the middle section, but nearly every clause carries needed information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with complex offset-map semantics and paging, the description covers inputs, output shape, paging, and the two-way offset mapping need (with the result detail carried in the schema). Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by stating the mutual-exclusivity constraint ("give `doc` or `text`") and illustrating the `at` address form, adding genuine selection guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (normalise text) and enumerates the exact transformations (NFC, soft hyphens, zero-width removal, whitespace collapse) plus the returned offset map. It also distinguishes itself from siblings by naming text.replace and para.list as downstream/alternative consumers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use it to compare or search text robustly and map found offsets back to addresses for text.replace" gives clear context for when this tool applies. It lacks an explicit when-not or a named alternative tool, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server