send_chat_join_request_web_app

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the agent knows this is a non-idempotent outward-facing write. The description adds useful sequencing context (it precedes the answer step) but does not disclose what the side effect actually is from the server's perspective, whether calling it twice re-shows the Mini App, or whether the user must interact for the flow to proceed.

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 short sentences, with the action and timing front-loaded and the follow-up resolution step second. No filler, and the trailing '(v10.1)' version tag is the only questionable token.

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 two-parameter, no-output-schema tool, the description covers the workflow slot and the handoff sibling, which is the minimum an agent needs to sequence it. However, with 0% schema coverage and no output schema, the undefined parameters and the unknown result of showing the Mini App remain unexplained.

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% and there are two required parameters, neither of which the description explains. It never says what a 'chat_join_request_query_id' is, where it comes from, or what form 'web_app_url' must take (HTTPS requirement, hosted Mini App constraints). The description leaves the agent dependent on undocumented parameter names.

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?

Names a specific action and object ('Show a Mini App to a user') tied to a concrete workflow stage ('before deciding a join request'), which distinguishes it from the plain approve/decline siblings. It does not explicitly contrast with approve_chat_join_request or decline_chat_join_request, but the routing to answer_chat_join_request_query makes the intended position in the flow clear.

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 a clear when-to-use condition ('before deciding a join request') and an explicit next step naming the sibling that resolves the request ('answer_chat_join_request_query'). It lacks any when-not-to-use or prerequisite guidance (e.g., what to do if the user never opens the Mini App), so it stops short of a full 5.

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