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

Beyond the annotations, the description discloses meaningful behavioral details: which route is used with user auth, the fallback to the app-token route, the required bot instance precondition, auth requirements, and specific 404/403 error conditions. It also names the side effects it sets on the app record. These details add real value beyond the structured fields.

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 longer than average, but it is front-loaded with the core purpose and follows with preconditions, auth, errors, and related tools. The main redundancy is that the invite precondition is stated twice in the 'Preconditions' and 'Requires' paragraphs, which prevents a perfect score.

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 output schema, the description still covers the essential invocation context: prerequisites, required setup chain, auth mode, fallback behavior, and error cases. Combined with complete parameter documentation in the schema, an agent has enough information to select and call this tool correctly.

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%, so the parameters are already well documented in the input schema. The description does not add parameter-level meaning beyond what the schema provides, such as details about `chatJid` or the alias relationship, so the baseline score of 3 is appropriate.

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 starts with a specific verb and resource: making an agent the app's ACTIVE widget bot, and names the concrete setting `App.defaultBotInstanceId` with `botStatus: on`. It also explains the downstream effect on `POST /v2/widget/sessions`, which cleanly distinguishes this activation tool from sibling tools like `ethora-agent-create` or `ethora-agent-invite`.

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 strong context for when the tool is needed: it is required before an embedded widget can answer on an API-created app. It also gives preconditions and a related-tool sequence (`ethora-agent-create` -> `ethora-chat-create` -> `ethora-agent-invite`), plus next steps. It lacks an explicit 'when not to use' statement, so it is just short of a perfect score.

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