Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_source_graph_health

Read-only

Check Source Graph indexing daemon health for the active repo: indexing, ready, or degraded status with last report, error, and time. Use when Source Graph answers are stale or fail.

Instructions

READ-ONLY: Source Graph indexing daemon health for the active repository -- indexing/ready/degraded status, last report/error/time. Use this when Source Graph answers look stale or fail; use aiworkhub_dispatcher_health when callbacks stop arriving, and for a cross-subsystem verdict run the one-call doctor check.

detail="summary" (default) keeps every top-level scalar exact and folds each top-level dict/list to {summarized, bytes, sha256} plus its own status/state/degraded/ok and degraded_reasons; detail="full" ("evidence" behaves the same) returns the daemon payload unchanged.

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_health"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNosummary (default) folds nested blocks to identity plus their status facts; evidence and full both return the complete health 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 health payload.",
+  "enum": [
+    "summary",
+    "evidence",
+    "full"
+  ],
+  "title": "Detail",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the 'READ-ONLY' prefix is confirmatory rather than new. The real added value is the disclosure of how detail='summary' reshapes the payload (top-level scalars preserved exactly, nested blocks folded to identity plus status facts and degraded_reasons) versus 'full'/'evidence' returning the daemon payload unchanged. It does not say what a degraded status implies for remediation beyond pointing at the doctor tool.

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 correctly: read-only scope, then status contents, then routing, then the detail-mode contract. Dense but every clause carries information; the heavy inline-code formatting and the redundant 'READ-ONLY' label against an existing readOnlyHint cost it a point.

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 single optional enum parameter with an output schema present, the description covers scope (active repository), the diagnostic question it answers, alternates to use instead, and the output-shaping trade-off. Nothing an agent needs in order to call it correctly is missing.

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 is already documented, so the baseline is 3. The description goes further by specifying the exact folding contract ({summarized, bytes, sha256} plus status/state/degraded/ok and degraded_reasons) and by noting that 'evidence' behaves identically to 'full' — a behavioral equivalence the schema text only gestures at.

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 first sentence names a specific verb+resource with scope: indexing daemon health for the active repository, enumerating the returned facts (indexing/ready/degraded status, last report/error/time). It is immediately distinguishable from aiworkhub_dispatcher_health and aiworkhub_doctor_diagnose, which are named explicitly.

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?

It states exactly when to reach for it (Source Graph answers look stale or fail) and routes two adjacent cases elsewhere: callbacks not arriving -> dispatcher_health, cross-subsystem verdict -> one-call doctor check. When-to-use, when-not, and the alternatives are all present.

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