Leapfrog MCP

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

With no annotations provided, the description carries the full disclosure burden and succeeds well: it reveals pagination auto-detection behavior ('auto-detects next buttons'), discloses hard caps ('50 pages, 100K total chars') not explicitly calculated in schema constraints, and describes return values ('extracted content plus metadata') despite the absence of an output schema. It could improve by mentioning error handling for partial pagination failures.

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 consists of tightly packed sentences with zero waste: the first establishes purpose, the second covers capabilities, the third details auto-detection behavior, and the fourth covers returns, efficiency gains, and limits. Critical information (caps, auto-detection) is front-loaded and easily scannable.

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 complex 11-parameter multi-modal tool, the description adequately covers the essential behavioral contracts: pagination strategies, extraction types, stopping conditions (implied by 'cap'), and return characteristics. Given the rich schema coverage and lack of output schema, mentioning the metadata return provides sufficient completeness, though explicit error behavior for incomplete pagination would elevate this to a 5.

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?

Although schema description coverage is 100% (baseline 3), the description adds meaningful context beyond raw schema documentation: it explains the relationship between 'nextSelector=auto' and the auto-detection behavior, clarifies the three pagination modes in plain language, and contextualizes the caps (50 pages, 100K chars) that govern parameter interactions without repeating schema definitions.

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 ('Extract') and resource ('data across multiple pages'), clearly stating the tool's purpose. It distinguishes itself from sibling tools like 'extract' and 'navigate' by emphasizing multi-page handling and stating it 'Replaces 3-4 tool calls per page with one invocation', establishing its unique batch-processing value proposition.

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?

The description provides clear context for when to use the tool by enumerating specific pagination strategies ('click-next, infinite scroll, and URL-pattern') and mentioning efficiency benefits over manual extraction. However, it lacks explicit contrast with sibling alternatives (e.g., when to use 'extract' vs 'paginate') and doesn't mention prerequisites like requiring an active session.

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