Get app deep link

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered externally. The description adds genuinely new behavior: the link only resolves after sign-in, it targets modals vs. navigation, and the agent must hand the URL back to the user rather than expecting an inline effect.

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?

Two sentences, front-loaded with the core purpose before the usage guidance. The parenthetical action list is somewhat redundant with the enum but it efficiently conveys scope in one clause rather than bloating the text.

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?

With 8 parameters, 1 required, an output schema present, and annotations covering safety, the definition supplies what an agent needs: what the tool produces, when to prefer it, and what to do with the result. Remaining gaps (per-action parameter requirements) are already handled by the 100%-covered schema.

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% and each parameter (including the action enum, provider, articleSlug, destination) is already documented in the schema. The description restates the action family in prose (upgrade, buy credits, top-ups, invites, feedback, integrations, settings, NAVIGATE) but adds no format, constraint, or conditional detail beyond the schema, so the baseline 3 applies.

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 and artifact ('Build a VideoGen app URL') plus the outcome ('opens a modal or navigates after the user signs in'), and enumerates the concrete destinations. This is clearly distinguishable from the generation/entity-management siblings, which operate on assets rather than producing in-app links.

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?

Gives an explicit selection condition: 'Prefer this when the user needs to complete something in the VideoGen UI that MCP tools cannot do inline — especially credits or plan gates,' and states the follow-through ('Return the url to the user'). It doesn't name a specific alternative sibling, but the condition is unambiguous enough to route the agent.

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