mazarbul

Overview Schema Source Related Servers Discussions Admin

waitForIdle

Blocks until background extraction, resolution, and embedding finish or the timeout expires. Use it after bursts of remember() calls before benchmark recall() so latency measures retrieval only.

Instructions

Block until the kernel finishes all background extraction, resolution, and embedding work (or the timeout expires). Use between a burst of remember() calls and a benchmark recall() so the recall measures retrieval latency only, not the tail of ingestion. Cheap when the kernel is already idle.

Input Schema

Name	Required	Description	Default
`timeoutSeconds`	No	Maximum seconds to wait. Defaults to 300. The tool returns timedOut:true rather than erroring when the budget expires.

Output Schema

Name	Required	Description
`isIdle`	Yes	True when both enrichment and vec drained within the budget; false if timedOut.
`timedOut`	Yes	True when the timeoutSeconds budget expired before the kernel went idle.
`elapsedMs`	Yes	Wall-clock spent waiting, in milliseconds.
`vecInflight`	Yes	Vec depth observed at return time (0 unless timedOut).
`enrichmentInflight`	Yes	Enrichment depth observed at return time (0 unless timedOut).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 31, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and discloses that the call blocks until background work completes or the timeout expires, and that it is cheap when already idle. It does not explicitly declare side-effect-free/read-only behavior, but the blocking and cost traits are well covered.

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 three concise sentences with the core blocking behavior front-loaded, followed by the intended usage pattern and a cost note. Every sentence adds useful information without redundancy.

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 simple one-parameter waiting tool with full schema coverage and an output schema, the description provides enough context to invoke it correctly and understand its purpose. Return-value details are covered by the output schema rather than needing repetition here.

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%, and the single timeoutSeconds parameter is already fully documented in the schema, including its default and timedOut return behavior. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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?

The description states a specific blocking verb and the resource it waits on: all background extraction, resolution, and embedding work. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling idleStatus tool, which likely also reports kernel idleness.

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?

It gives a clear usage scenario: between a burst of remember() calls and a benchmark recall() so the recall measures retrieval latency only. It does not mention when not to use it or name idleStatus as a non-blocking alternative.

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