DataCraftsmanAU/vineverse-mcp

Bundle log and generation time

get_changelog

Read-onlyIdempotent

Retrieve the ingestion log and bundle-generated timestamps to determine how current the data is and cite exact versions.

Instructions

The knowledge base's own log file, plus when the data was actually ingested. Use bundleGenerated to answer "how current is this" or to cite a version — the generated field on get_stats is when this server built its in-memory index and changes on every restart, which is a fact about the process rather than the data.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`log`	Yes
`url`	Yes
`note`	No
`licence`	No
`indexBuilt`	Yes
`okfVersion`	No
`bundleGenerated`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.3Aug 23, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "bundleGenerated": {
+      "type": "string"
+    },
+    "indexBuilt": {
+      "type": "string"
+    },
+    "licence": {
+      "additionalProperties": {},
+      "properties": {
+        "attribution": {
+          "type": "string"
+        },
+        "data": {
+          "type": "string"
+        },
+        "shareAlike": {
+          "type": "string"
+        },
+        "text": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "text",
+        "data",
+        "shareAlike",
+        "attribution"
+      ],
+      "type": "object"
+    },
+    "log": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "note": {
+      "type": "string"
+    },
+    "okfVersion": {
+      "type": "string"
+    },
+    "url": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "indexBuilt",
+    "log",
+    "url"
+  ],
+  "type": "object"
+}

First observedv1.0.1Aug 23, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining that `generated` in get_stats changes on every restart and reflects the process rather than the data, which helps the agent avoid misinterpreting the values. It could go further by describing the exact shape of the returned log, but the output schema already covers that.

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 entire description is one tight, information-dense sentence. It front-loads the resource, then provides a concrete use case, then a precise contrast with get_stats. Every clause earns its place: no filler, no repetition, and the crucial disambiguation appears before the sentence ends.

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?

With no parameters, full schema coverage, robust annotations, and an output schema, the description has a narrow job: telling the agent what the result means and when to use it. It explains the purpose, the key field `bundleGenerated`, and the distinction from get_stats' `generated` field. There is no critical missing guidance for someone deciding whether to call this tool or how to interpret its output.

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?

The tool has zero parameters, so baseline 4 applies. The input schema covers 100% of parameter documentation and there is nothing for the description to add. The description focuses instead on output semantics, which is the appropriate place to provide value.

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 clearly states that this tool returns the knowledge base's own log file plus the actual data ingest time, and introduces the `bundleGenerated` field by name. It explicitly differentiates from get_stats' `generated` field, which describes a process fact rather than data freshness.

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

Usage Guidelines5/5

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

The description explicitly says when to use this tool: when the agent needs to answer how current the data is or cite a version, use `bundleGenerated`. It also directly contrasts get_stats' `generated` field, providing a clear decision rule between this tool and a sibling alternative.

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

Deploy Server