add_account

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuinely new behavior: the write is validated, backed up, and atomic, and cookie values are never passed through the tool call. It still omits the failure mode on a duplicate account_id, which matters given idempotentHint=false.

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?

Front-loads the destination file and the validated/backed-up/atomic guarantees in the first clause, then handles the two tricky parameters. Dense but every sentence carries information; no filler.

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?

Return values are covered by the output schema, and the description supplies the mutation semantics and the cookie-handling security model. Remaining gaps are the duplicate-account behavior and the unexplained target_keywords semantics.

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 carries the full burden for 6 parameters and only documents two (cookie_file, persona). It does cover the non-obvious ones well — cookie_file is clarified as an on-machine path that gets validated and copied to <account_id>_cookies.json, and persona has a 4000-char cap — but account_id, proxy, is_active, and especially target_keywords receive no explanation anywhere.

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+resource: 'Add an account to config/accounts.json', naming the concrete persisted artifact. It does not differentiate itself from the nearby update_account / set_account_active siblings, so an agent must infer that this is the create path rather than modify.

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?

There is no when-to-use guidance: no statement about prerequisites, what happens if the account_id already exists, or when to prefer this over update_account. The verb 'Add' implies creation, but nothing tells the agent when this tool is the right choice versus its siblings.

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