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

Beyond the sparse readOnlyHint, the description discloses validation against Meow's accounts endpoint, the storage-only-if open-deposit-account-exists condition, that invalid keys store nothing and return an error, the read-only scope, and key secrecy. It also explicitly states the operation cannot move money, which is important behavioral context.

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?

Four dense, purposeful sentences with no filler. The main purpose is front-loaded, and each sentence adds a distinct fact: auth model, validation/storage, access scope, and security handling.

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 schema covers org_id and actor_id defaults/constraints and an output schema exists, the description covers the remaining operational essentials: prerequisites, validation behavior, failure mode, security, and access limitations. An agent has everything needed to call it 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?

The schema already documents all three parameters thoroughly, so the baseline is 3. The description adds meaningful semantics for api_key beyond the schema: it must expose at least one open deposit account and is validated before being stored, plus the security guarantee that it is never logged or echoed.

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 and resource: 'Connects the org to Meow from a read-only API key'. It clearly identifies the integration target and the access mode, which distinguishes it from siblings like connect_mercury without needing to inspect 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?

It gives clear context on when this applies: a Meow dashboard key, not OAuth, no redirect, and no IP allowlist needed. It does not explicitly name alternatives or exclusion conditions, but the Meow-specific prerequisite is strong enough guidance for a model to choose this over connect_mercury.

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