Skip to main content
Glama
Sign In
Unilytics MCP Server

Unilytics MCP Server

Official
by TeamUnilytics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

kb_update_document

Destructive

Refresh a document's content in place while preserving its document_id so existing references stay valid; pass a URL to re-fetch or content for a text document.

Instructions

Refresh a document's content in place, keeping the SAME document_id (so references stay valid). Pass a url to re-fetch a URL doc, or content for a text doc. Status goes ready→pending→ready. A resync rebuilds the index; metadata set earlier with kb_update_document_metadata isn't carried over.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "document_id": "<document_id>"
    },
    "name": "kb_update_document"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNo
nameNo
contentNo
project_idYes
document_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • removedInput schema / properties / config
      Removed value: -{
-  "default": null,
-  "title": "config",
-  "type": "string"
-}
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

The description adds substantial behavior beyond the annotations: status transitions ready→pending→ready, index rebuilding during resync, and loss of previously set metadata. Those details make the destructiveHint more understandable. It does not describe authorization requirements or return behavior, but the annotations plus description give a strong operational picture.

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

Conciseness5/5

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

The description is three compact sentences with no wasted wording. The key identity-preservation guarantee is front-loaded, followed by parameter selection, lifecycle status, and side-effect warnings.

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

Completeness4/5

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

For a destructive, non-idempotent resync operation with no output schema, the description covers the important side effects, status lifecycle, input-mode choice, and sibling relationship. The main remaining gap is that the optional `name` and required `project_id` parameters are not described, but the core behavior is otherwise complete.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains `url`, `content`, and implicitly `document_id`, but leaves the optional `name` parameter and `project_id` unaddressed, so coverage of the five parameters is only partial.

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?

The description states a specific verb and resource: refresh a document's content in place while preserving the same document_id. It also distinguishes this operation from metadata updates by explicitly naming kb_update_document_metadata, so an agent can differentiate it from that sibling without opening the schema.

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?

It gives clear guidance for choosing the input mode: pass `url` to re-fetch a URL document or `content` for a text document. It also implies that metadata changes belong to kb_update_document_metadata rather than this tool, though it does not explicitly state when not to use this tool or what happens if both `url` and `content` are supplied.

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

Deploy Server

Other Tools