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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond that — requests outside the /v1/instagram/ namespace are refused — but says nothing about how failures on an unknown path surface or how the response is shaped for arbitrary endpoints. With annotations carrying most of the load, this is adequate rather than rich.

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?

Three tight sentences, front-loaded with the verb, resource, and path constraint. The platform-refusal boundary and the parameter rule each earn their place; there is no restatement of the title or filler.

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 an output schema present, annotations covering safety, and full parameter documentation, the description only needs to explain the discovery path, the namespace boundary, and the parameter contract — all of which it does. The remaining gap is that it never says what happens when a path is valid but the caller omits a required parameter for that endpoint, which is the most likely failure mode for a generic proxy.

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 100% and the per-parameter descriptions are already detailed (credit costs on limit, cache behavior on fresh, handle_is caveat on handle), so the baseline is 3. The description earns the bump by explaining the polymorphic contract: only pass parameters the target endpoint accepts, and list_endpoints reports which one it needs. That is a real usage rule the schema cannot express, since every parameter is optional except path.

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 resource ('Call any Instagram endpoint ... by its path under /v1/instagram/') and pins the scope to a single platform namespace. It distinguishes itself from the sibling capability tools by explicitly framing itself as the escape hatch for 'what the capability tools above do not wrap', so an agent can tell it apart from get_profile, search_hashtag, etc. without opening any 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?

Gives clear when-to-use context (endpoints not covered by the wrapping capability tools) and a hard boundary (a path on another platform is refused). It also routes discovery to list_endpoints for parameter requirements. It stops short of saying 'prefer the dedicated capability tool when one exists', which is the main routing decision an agent faces here.

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