Skip to main content
Glama
Sign In
Krv-Labs

topos-mcp

by Krv-Labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

topos_depgraph_status

Read-onlyIdempotent

Report .gitnexus availability and freshness (read-only). Distinguishes a missing graph from a stale one and from a load/schema failure, so an agent knows whether COMPOSABLE can be trusted and what to do next.

Instructions

Report .gitnexus availability and freshness (read-only). Distinguishes a missing graph from a stale one and from a load/schema failure, so an agent knows whether COMPOSABLE can be trusted and what to do next. Never shells out and never mutates state.

Input Schema

NameRequiredDescriptionDefault
directoryNoRepo root to inspect (default: MCP file root / process project root).
gitnexus_dirNo`.gitnexus` store under the project root (default: `<project root>/.gitnexus`).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.11.0
    • addedInput schema / properties / directory / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / directory / type
      Removed value: -[
-  "string",
-  "null"
-]
    • addedInput schema / properties / gitnexus_dir / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • removedInput schema / properties / gitnexus_dir / type
      Removed value: -[
-  "string",
-  "null"
-]
  2. Changed2 schema fields changedv0.5.0
    • addedInput schema / properties / directory
      Added value: +{
+  "default": null,
+  "description": "Repo root to inspect (default: MCP file root / process project root).",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedInput schema / properties / gitnexus_dir / description
      Previous value: -"`.gitnexus` store under the MCP file root (default:\n`<file root>/.gitnexus`). Does not change the file root."New value: +"`.gitnexus` store under the project root (default:\n`<project root>/.gitnexus`)."
  3. Changed1 schema field changedv0.4.4
    • changedInput schema / properties / gitnexus_dir / description
      Previous value: -"Override .gitnexus directory (default: <root>/.gitnexus)."New value: +"`.gitnexus` store under the MCP file root (default:\n`<file root>/.gitnexus`). Does not change the file root."
  4. Changed4 schema fields changedv0.4.0
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / gitnexus_dir
      Added value: +{
+  "default": null,
+  "description": "Override .gitnexus directory (default: <root>/.gitnexus).",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • removedInput schema / properties / params
      Removed value: -{
-  "additionalProperties": false,
-  "description": "Arguments for ``topos_depgraph_status``.",
-  "properties": {
-    "gitnexus_dir": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Override .gitnexus directory (default: <root>/.gitnexus)."
-    }
-  },
-  "type": "object"
-}
    • removedInput schema / required
      Removed value: -[
-  "params"
-]
  5. First observedv0.3.6

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds value by enumerating the diagnostic outcomes it can report (missing vs stale vs load/schema failure) and confirming it "never shells out," which tells the agent there are no external side effects or shell dependencies.

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 action and kept to three short sentences with no filler. The closing "never shells out and never mutates state" is partly redundant with readOnlyHint, but it is brief and reinforces an important guarantee.

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?

There is no output schema, so the description must convey what the agent learns from the call; it does so by naming the three diagnostic states it distinguishes. Coverage is good for a two-optional-parameter read-only probe, though the actual response shape and any remediation steps remain unspecified.

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 100%: both `directory` and `gitnexus_dir` are documented with their defaults and fallback behavior. The description adds no parameter-level detail, which is the expected baseline when the schema carries the full burden.

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

Purpose4/5

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

States a specific verb and resource ("Report `.gitnexus` availability and freshness") and enumerates the states it distinguishes (missing, stale, load/schema failure), so the agent knows exactly what it inspects. It does not explicitly name the sibling `topos_generate_depgraph` as the counterpart action, so sibling differentiation is only implied.

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?

Gives a clear usage context: run it to determine "whether COMPOSABLE can be trusted and what to do next." There are no explicit exclusions or named alternative tools, and "what to do next" is left unstated, which keeps it 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

Other Tools