I’m using the Document360 MCP to retrieve and update Knowledge Base articles, and I’m running into an issue where long article bodies are not always returned in complete, usable form. I’m not sure whether the content is being truncated by the MCP server itself or collapsed somewhere between the MCP response and the client, but the practical effect is the same: I request an article, and the body I receive may be incomplete. This creates a problem for write workflows because article updates appear to require sending back the complete article body, rather than applying a small targeted patch. A typical flow looks like this: I call get_article for an article. The response includes metadata and body content, but a long middle section of the body may be omitted or collapsed. I need to make a targeted edit to one section. To save the update, I need to call update_article with the revised article body. Because I don’t have the complete original body, I either have to reconstruct the missing section or risk unintentionally changing/removing content outside the intended edit. After saving, I call get_article again to verify, but if the readback is also incomplete, I still can’t fully confirm that the article body was preserved. So the core issue is not just that long articles are harder to review. It’s that incomplete readback makes full-body replacement updates risky. If update_article requires replacing the full body, then get_article needs to provide the full body reliably. A few improvements would help a lot: Return the complete article body from get_article . If full bodies are too large, provide paginated or chunked body retrieval. Include an explicit is_truncated flag when content has been shortened. Support targeted patch-style updates for smaller edits. Preserve and expose the article’s content/editor type consistently during read and update operations. The MCP is very useful for documentation maintenance, but safe editing depends on being able to retrieve, modify, save, and verify the complete article content.
