Skip to main content
Glama
hubertino-app

Hubertino MCP Server

Official

List scrapes

list_scrapes
Read-only

Retrieve recent scrapes to find a scrape ID or reuse a finished search, avoiding duplicate charges.

Instructions

List this account's most recent scrapes, newest first (the API keeps the latest 200): id, title, status, resultCount, credits charged and dates. Use it to find a scrape id or to reuse a finished scrape instead of paying for the same search again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many scrapes to return (1-200, default 20).
statusNoOnly return scrapes with this status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already signal readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond annotations: account scoping, newest-first ordering, the 200-item retention cap, and the specific fields returned. This is meaningful disclosure for a read-only list tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The first sentence front-loads the resource, ordering, bound, and returned fields; the second gives practical use cases. Every clause adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with no output schema, the description covers the essential return fields and the account/retention context. Combined with fully documented parameters and safety annotations, an agent has enough to invoke it correctly. It could mention pagination edges, but the 200 cap makes this a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both `limit` and `status` are already documented. The description adds little parameter-specific detail beyond reinforcing the 200 cap and status relevance. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List this account's most recent scrapes.' It adds ordering ('newest first'), a retention bound ('latest 200'), and names the exact fields returned. This clearly distinguishes it from sibling tools like start_scrape, get_results, and download_export.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly gives two use cases: finding a scrape id and reusing a finished scrape 'instead of paying for the same search again,' which points to when listing is preferable to starting a new scrape. It does not enumerate all sibling alternatives, but the guidance is concrete and actionable.

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