Start /nanites-btw Chat

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

With no annotations present, the description carries the full burden and excels: it discloses the destructive effect ("replaces the active chat row and wipes its old transcript"), the async non-blocking guarantee ("returns immediately — it can never stall or eject a running job"), model pinning behavior, and the ~5s grace window for inline answers. This is exemplary behavioral disclosure with no contradiction.

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 front-loaded with the core verb and resource, and every clause earns its place — there is zero filler. It is structured as one long run-on sentence with multiple parenthetical asides, which could be split into separate sentences for readability, but the density is justified by the tool's complexity.

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 tool with no annotations, no output schema, and 0% parameter documentation, the description is remarkably complete: side effects, async semantics, timing bounds, and the return payload (dashboard deep link, job handle, status) are all covered. Minor gaps remain — error/failure behavior of the compaction job and what happens when initial_question misses the grace window — but nothing blocks a 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 coverage is 0%, so the description must compensate, and it largely does: profile is grounded as "for a profile," messages as "the given host-session transcript" that gets compacted, and initial_question as the prompt "answered inline" within the grace window. It falls short only by not flagging that all three parameters are optional and by not stating default behaviors for omitted values.

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-plus-resource statement — "Start a /nanites-btw working-memory chat for a profile" — and the follow-on behavioral list (row replacement, transcript wipe, compaction enqueue, context_qa pinning, grace window) makes it unmistakably distinct from siblings like chat or start_sub_agent_job. An agent can tell what this tool is for without opening the schema.

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 use context is clearly established: this is the operation for opening a /nanites-btw working-memory chat with transcript compaction and model pinning, which is a distinct scenario from the sibling chat tool. However, no explicit when-not-to-use or alternative routing is stated (e.g., a note that ordinary conversation should use chat), so it stops short of full guidance.

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