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

Annotations already declare readOnlyHint and openWorldHint, so safety profile is covered and the bar is lower. The description adds genuine value by disclosing the return shape (path, summary, params, credits) even though no output schema exists. It stops short of saying whether searching is free, whether returned "credits" are the cost of executing via call_endpoint, or whether results are paginated.

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, no filler, and the platform enumeration is front-loaded to establish scope immediately. The trailing list is long but each entry differentiates coverage from the sibling tools, so it earns its place. Slightly list-heavy relative to the amount of actionable guidance, but nothing is wasteful.

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 simple two-optional-param discovery tool with no output schema, covering the return fields is the right move and it is done. What is missing is the connective tissue: how this tool relates to call_endpoint and to the dedicated platform siblings. Adequate but not complete for a meta/discovery tool whose whole purpose is routing.

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%, so both `search` and `platform` are already documented in the input schema. The description adds nothing about how the two interact (e.g., whether platform restricts search, whether either is required, what format platform names take). Baseline 3 is appropriate when the schema does the heavy lifting.

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?

"Find more endpoints" is a soft verb-plus-resource statement; on its own it is close to tautological with the tool name. The parenthetical list (Reddit, LinkedIn, Threads, Pinterest, ad libraries, TikTok Shop, Spotify, GitHub) is what actually earns the score, since it signals this is a catalog/discovery tool covering platforms that have no dedicated sibling. An agent can infer the distinction from the siblings list, but the description never states outright that this is a catalog lookup rather than a data-fetch.

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?

No when-to-use or when-not-to-use guidance beyond the implied "more" in the first word. Crucially, it never links to the obvious workflow: this tool surfaces a path, and call_endpoint executes it. Without that pairing stated, the agent must infer the two-step pattern from tool names alone. No mention of alternatives or of what to do when a dedicated platform tool already exists.

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