brain_portability

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns config snippets for 7 clients, a Brain ID, and a model-neutrality proof table. It also states that all clients connect to the same Brain for shared data. This covers core behavioral traits, though it does not mention any side effects, required permissions, or performance implications.

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: the first sentence captures the core value proposition. The rest provides specific, actionable details (list of clients, autopilot option, example output). Every sentence earns its place without redundancy.

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 tool's complexity (one parameter, no output schema), the description is largely complete. It explains the return value sufficiently for agent understanding. However, it could be slightly improved by noting the output format (e.g., JSON) or any prerequisites (e.g., a running instance). The presence of 7 sibling tools with similar names is mitigated by the distinctive purpose stated.

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 100% (instance_id is described in the schema). The description adds value by explaining what the tool does with that instance_id (generate configs for the associated Brain). It goes beyond the schema by detailing the output content (config blocks, model-neutrality table). The baseline credit is met, and the description provides meaningful additional context.

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 clearly states the tool's purpose: exporting memory configuration for portability across AI editors. It specifies the verb ('Bring your own model, keep your brain') and the resource ('returns Brain ID and config snippets for 7 clients'). It distinguishes this from sibling tools like 'syndicate' and 'brain_share', which focus on sharing or federating data rather than generating client configs.

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 gives clear context for when to use this tool: when you want to connect multiple editors to the same Brain. It mentions an alternative ('autopilot to configure all detected editors in one command'). However, it does not explicitly state when NOT to use this tool (e.g., if you only need a single editor config, or if you lack an instance_id).

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