Skip to main content
Glama
NeuroBlockFoundation

ExtractorLead MCP Server

Estado del relleno de lista

get_list_enrichment
Read-only

Track list enrichment status by task ID, returning progress, a final summary, and a link to the edited Excel file; optionally include paginated rows with offset and limit.

Instructions

Estado del relleno de lista; al terminar, resumen y enlace al Excel editado.

include_rows=true añade las filas (paginadas con offset/limit, máx. 200).

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
task_idYes
include_rowsNo
wait_secondsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuine behavioral context: the terminal state yields a summary plus an Excel link, and row retrieval is paginated with a hard cap of 200. It omits what wait_seconds does (whether the call blocks/polls), which is the main remaining behavioral unknown.

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

Conciseness4/5

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

Two short sentences, front-loaded with the core purpose, then the pagination flag. Dense and waste-free, though the semicolon-chained phrasing and mixed language make it slightly harder to parse than it needs to be.

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

Completeness3/5

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

An output schema exists, so the return shape needn't be explained, and the description does note the summary/Excel-link payload. However, for a 5-parameter tool with zero schema descriptions, leaving wait_seconds and task_id semantics unstated is a real gap in an otherwise adequate definition.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry all parameter meaning, and it only clarifies include_rows and references offset/limit with a 200-row cap. task_id, the limit default of 50, and especially wait_seconds (default 30, likely a blocking wait) are left entirely undocumented.

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

Purpose4/5

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

States a specific resource and verb-equivalent ('Estado del relleno de lista') and adds what the caller gets at completion: a summary and a link to the edited Excel. It is clearly distinguishable from start_list_enrichment and preview_list_enrichment, though it never explicitly contrasts itself with get_bulk_status or get_task_result.

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

Usage Guidelines3/5

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

Usage is only implied as a status-polling call; there is no explicit statement of when to use this versus get_bulk_status or get_task_result. The one real guideline given is conditional: set include_rows=true if you want the actual rows back.

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