Skip to main content
Glama

topos_generate_depgraph

Generate the .gitnexus dependency graph via GitNexus (side-effecting). Ensures the graph by default: no-ops when current, otherwise runs gitnexus analyze. force=true always regenerates.

Instructions

Generate the .gitnexus dependency graph via GitNexus (side-effecting). Ensures the graph by default: no-ops when current, otherwise runs gitnexus analyze. force=true always regenerates.

Input Schema

NameRequiredDescriptionDefault
forceNoRegenerate even when current.
directoryNoRepo root to analyze (default: MCP file root / process project root).
gitnexus_dirNo`.gitnexus` store under the project root.

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
    • changedInput schema / properties / directory / description
      Previous value: -"Repo root to analyze (default: derived from `gitnexus_dir` when set,\notherwise the MCP file root). Explicit `directory` wins over derivation."New value: +"Repo root to analyze (default: MCP file root / process project root)."
    • changedInput schema / properties / gitnexus_dir / description
      Previous value: -"`.gitnexus` store under the MCP file root. When `directory` is omitted,\nthe analyze root is the parent of this path — same derivation\n`topos_depgraph_status` uses — so status → generate stay aligned."New value: +"`.gitnexus` store under the project root."
  3. Changed2 schema fields changedv0.4.4
    • changedInput schema / properties / directory / description
      Previous value: -"Repo root (default: MCP file root)."New value: +"Repo root to analyze (default: derived from `gitnexus_dir` when set,\notherwise the MCP file root). Explicit `directory` wins over derivation."
    • addedInput schema / properties / gitnexus_dir
      Added value: +{
      +  "default": null,
      +  "description": "`.gitnexus` store under the MCP file root. When `directory` is omitted,\nthe analyze root is the parent of this path — same derivation\n`topos_depgraph_status` uses — so status → generate stay aligned.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  4. Changed5 schema fields changedv0.4.0
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / directory
      Added value: +{
      +  "default": null,
      +  "description": "Repo root (default: MCP file root).",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / force
      Added value: +{
      +  "default": false,
      +  "description": "Regenerate even when current.",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / params
      Removed value: -{
      -  "additionalProperties": false,
      -  "description": "Arguments for ``topos_generate_depgraph`` (side-effecting).",
      -  "properties": {
      -    "directory": {
      -      "anyOf": [
      -        {
      -          "type": "string"
      -        },
      -        {
      -          "type": "null"
      -        }
      -      ],
      -      "default": null,
      -      "description": "Repo root (default: MCP file root)."
      -    },
      -    "force": {
      -      "default": false,
      -      "description": "Regenerate even when current.",
      -      "type": "boolean"
      -    }
      -  },
      -  "type": "object"
      -}
    • removedInput schema / required
      Removed value: -[
      -  "params"
      -]
  5. Changed2 schema fields changedv0.3.10
    • changedInput schema / properties / params / properties / directory / description
      Previous value: -"Repository root to analyze (default: the MCP file root)."New value: +"Repo root (default: MCP file root)."
    • addedInput schema / properties / params / properties / force
      Added value: +{
      +  "default": false,
      +  "description": "Regenerate even when current.",
      +  "type": "boolean"
      +}
  6. First observedv0.3.6

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false; the description adds the important context that the tool is side-effecting, that it no-ops when the graph is current, and that force=true always regenerates. That is genuine value beyond the structured hints. It stops short of describing failure behavior or what the graph write touches on disk.

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?

Three tight sentences with the side-effecting warning and the core action front-loaded, followed by the default and force semantics. No filler, though the parenthetical '(side-effecting)' is slightly awkwardly detached from the main clause.

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 mutating tool with no output schema, the description covers the key agent questions: what it writes, that it is side-effecting, when it skips work, and how to force a rebuild. Remaining gaps (failure modes, whether it modifies tracked repo files) are minor.

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%, so `force`, `directory`, and `gitnexus_dir` are already fully documented in the schema. The description's restatement of `force=true` behavior adds nothing beyond the schema's 'Regenerate even when current.' Baseline 3 is appropriate.

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 ('Generate the `.gitnexus` dependency graph') plus the underlying mechanism (`gitnexus analyze`), which is far more than a restatement of the name. It does not, however, mention the closely related sibling `topos_depgraph_status`, which an agent could easily confuse with this read/write pair.

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

Usage Guidelines3/5

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

The description explains the default call semantics ('no-ops when current, otherwise runs gitnexus analyze') and the force condition, which implicitly tells the agent it is safe to invoke without checking state first. But it never names an alternative tool (e.g. `topos_depgraph_status`) or states when-not to use this one, so usage guidance is implied rather than explicit.

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