Mundane

get_version_info

Read-onlyIdempotent

Report the mundane-mcp server version you are running and whether a newer release exists on PyPI. installed_version is read from the installed package metadata (null when running from a source checkout); latest_version is PyPI's current release (null when PyPI is unreachable, with the reason in error). update_available is true or false when both sides are known and comparable, otherwise null. When an update exists, install_hint is the exact command for your operator to run — upgrading is an operator action, not something to attempt yourself. Requires no arguments and never contacts the Mundane API.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`error`	No
`install_hint`	No
`latest_version`	No
`update_available`	No
`installed_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "error": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Error"
+    },
+    "install_hint": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Install Hint"
+    },
+    "installed_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Installed Version"
+    },
+    "latest_version": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Latest Version"
+    },
+    "note": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Note"
+    },
+    "update_available": {
+      "anyOf": [
+        {
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Update Available"
+    }
+  },
+  "title": "VersionInfoOut",
+  "type": "object"
+}

First observedSep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark this as read-only, idempotent, and non-destructive, so the description's extra context focuses on edge cases: null installed_version from source checkout, null latest_version with error reason when PyPI is unreachable, and update_available null when incomparable. It also discloses an install_hint and directs the agent not to perform the upgrade itself. This meaningfully exceeds the annotations and leaves no hidden side effects.

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 four sentences, each covering a distinct need: purpose, edge case semantics, operator-action warning, and invocation constraints. It is front-loaded with the headline behavior, and the longer field explanations are warranted by null-state complexity. No filler or repetition.

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 zero-argument, self-describing version check with an output schema, the description covers all necessary context: what is returned, when values can be null, what the agent should do with an update hint, and network behavior. The agent can invoke it correctly and interpret results without any external knowledge.

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 and the schema has no properties, and the description explicitly confirms 'Requires no arguments.' With no parameters to document, there is nothing missing; the baseline 4 applies because the description states the absence clearly.

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?

Description uses a specific verb ('Report') and concrete resource: the running mundane-mcp server version and whether a newer PyPI release exists. It goes beyond the title by naming the exact fields returned and the PyPI source, making it distinguishable from task/worker/spend siblings. No ambiguity about what the tool does.

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?

The description explicitly states invocation context: no arguments and no Mundane API contact, which tells the agent it's a cheap, safe version check. It also gives an exclusion for upgrades, saying upgrading is an operator action and not something for the agent to attempt. No explicit alternative tool is named, but no sibling offers version functionality, so the guidance is sufficient.

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

All Mundane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.