Skip to main content
Glama

aiworkhub_source_graph_refresh_now

Forces an immediate bounded incremental or initial full Source Graph build, separate from scheduled background refreshes, and returns the daemon health payload.

Instructions

Force one bounded incremental (or first-ever full) Source Graph build now, non-overlapping with the periodic background refresh.

The reply is the daemon health payload: detail="summary" (default) folds it exactly like aiworkhub_source_graph_health; detail="full" ("evidence" behaves the same) returns it unchanged. An unknown detail is refused before any refresh is requested.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aiworkhub_source_graph_refresh_now"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNosummary (default) folds nested blocks to identity plus their status facts; evidence and full both return the complete payload.summary

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.75
    • addedInput schema / properties / detail
      Added value: +{
      +  "default": "summary",
      +  "description": "summary (default) folds nested blocks to identity plus their status facts; evidence and full both return the complete payload.",
      +  "enum": [
      +    "summary",
      +    "evidence",
      +    "full"
      +  ],
      +  "title": "Detail",
      +  "type": "string"
      +}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Adds real context beyond the annotations: the build is bounded, it will not overlap the periodic background refresh, the first run may be a full build, and an invalid `detail` is rejected before any refresh is requested (side-effect ordering). Those are exactly the concerns an agent triggering a mutation needs.

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 short paragraphs, front-loaded with the action, then reply shape, then validation behavior. Slightly jargon-heavy ('daemon health payload', escaped backticks) but no filler sentences.

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?

An output schema exists, so return-value detail is a bonus rather than a requirement, and the mutation semantics and validation ordering are covered. The one real gap: it does not say whether a call made while a refresh is already in flight fails, waits, or is coalesced.

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?

Schema coverage is 100% and the enum descriptions already define summary vs evidence/full, so the baseline is 3. The description still adds value by tying 'summary' to the folding behavior of aiworkhub_source_graph_health, giving the agent a way to reason about the shape it will get.

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?

States a specific verb and resource — 'Force one bounded incremental (or first-ever full) Source Graph build now' — and implicitly distinguishes itself from aiworkhub_source_graph_health, whose payload it reuses. An agent can tell this mutates/refreshes graph state rather than reading it.

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?

Implied usage is clear (call to trigger an immediate refresh instead of waiting for the periodic cycle), but the description never says when not to call it, nor names aiworkhub_source_graph_ensure_started / aiworkhub_source_graph_health as the alternatives for 'start daemon' vs 'read state only'. Guidance is left to inference.

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