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

With no annotations provided, the description carries full behavioral burden and succeeds: it discloses that this is a WRITE, that it is immediate and synchronous (~5-15s), that the token is forwarded to Meta over loopback and never persisted, and that the connection appears in mmp_get_state on the next call. It also notes the lack of mutation-receipt capability.

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 dense but front-loaded with the core purpose, and every additional sentence earns its place by covering side effects, security handling, timing, and prerequisites. The REQUIRED and EXAMPLE sections make the parameters unambiguous without bloat.

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 mutating tool with no annotations and no output schema, the description is remarkably complete: it explains when to call, what happens, how long it takes, where the result is observed, what token format is required, and the limitation on mutation receipts. The agent can invoke it correctly with no external inference.

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 fully compensates: it specifies that provider currently supports only 'appsflyer', defines api_token as the AppsFlyer Personal API Token v2, and provides a concrete JSON example. This gives the agent more meaning than the bare string properties in the schema.

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: 'Create one new MMP connection' plus the initial metadata sync. It is clearly differentiated from siblings by the explicit 'new connection' wording and by naming the outcome in mmp_get_state, so it cannot be confused with mmp_refresh_connection or mmp_delete_connection.

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 explicit call conditions, 'Call only after the user explicitly requests the connection and supplies the token,' and explains the synchronous nature and lack of mutation receipt. It does not name an alternative tool explicitly, but the prerequisite and scope are clearly stated.

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