hebbrix_graph_status

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

The description goes well beyond the readOnlyHint and idempotentHint annotations by explaining that ready requires durable enrichment plus a successful graph read, that related_memory_count counts neighboring memories rather than extracted relationships, and that a zero count does not imply missing edges. It also discloses that the tool never fabricates edges from spelling conventions and that wait_seconds is capped at 30 seconds. This is substantial behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. Every subsequent sentence adds decision-relevant clarification: the definition of ready, the polling bound, the count semantics, and the fabrication caveat. There is no filler or redundant restatement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists and annotations already declare the operation read-only, idempotent, and non-destructive, the description supplies the remaining context an agent needs: async readiness semantics, polling behavior, and the meaning of a potentially confusing count field. Nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains wait_seconds as optional bounded polling up to 30 seconds, which is not inferable from the schema alone. memory_id is not elaborated, but its role as the target memory identifier is clear from the opening sentence and parameter name.

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

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

The description opens with a specific verb and resource: "Check whether one memory's asynchronous graph enrichment is ready." This clearly distinguishes the tool from siblings like extraction_status by targeting graph enrichment readiness rather than extraction progress. It further defines what "ready" means, so an agent knows exactly what state is being tested.

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

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

The description implies a clear usage context: poll or check the status of asynchronous graph enrichment for a single memory. It also documents bounded polling via wait_seconds. However, it does not explicitly explain when to prefer this tool over similar siblings such as hebbrix_extraction_status or hebbrix_graph_query, leaving some routing to inference.

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