Index status

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add real behavioral context: a prior session's index is auto-attached at startup, and a stale index triggers an automatic background reindex. That auto-reindex disclosure is valuable because it explains why an agent should not panic over staleness. Points withheld because the enumerated return fields duplicate the existing output schema rather than adding new behavioral information.

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?

Purpose is front-loaded in the first sentence, followed by the when-to-use guidance and then return contents. Mostly tight, but the middle list of return fields (counts, engines, memory) is a partial restatement of the output schema and could be trimmed without loss.

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?

For a zero-parameter, read-only status tool with rich annotations and an output schema, the description supplies everything an agent needs: what it reports, when to call it, that it is not a prerequisite, and what to do on a false result.

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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly does not waste space inventing inputs.

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?

States a specific verb and resource: checks whether the project is indexed and whether the index is fresh. It is clearly distinguishable from siblings like `index`, `search`, and `map`, and an agent knows immediately this is a health/state check rather than a query.

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?

Explicitly says when NOT to call it ('You do not need it before other nexus tools: an index saved in an earlier session is attached when the server starts'), names the triggering condition ('Use it when a tool says "No codebase indexed"'), and routes to the alternative ('If `indexed` is false, call `index`'). This is the strongest form of routing guidance.

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