Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Iterator MCP Server Load my customers.jsonl and get the next record."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for processing large datasets record by record. This server provides tools for loading datasets in JSON format and iterating through them with stateful progress tracking.
Multiple Dataset Formats: Support for JSON Lines and JSON with jq expressions
Stateful Processing: Maintains progress across requests
Flexible Navigation: Jump to specific records, reset, or continue processing
Result Tracking: Save processing results for each record
Progress Monitoring: Track processing status and completion
Export Capabilities: Export all results to a file
Related MCP server: Large File MCP Server
Install dependencies:
npm installBuild the TypeScript:
npm run buildConfigure in your MCP client (like Claude Desktop). Add to your config:
{
"mcpServers": {
"iterator-mcp": {
"command": "node",
"args": ["/path/to/iterator-mcp/build/index.js"]
}
}
}load_datasetLoad a dataset in JSON Lines format (one JSON object per line).
Parameters:
file_path (string): Path to the dataset file
Example:
# dataset.jsonl content:
{"id": 1, "name": "Alice", "email": "alice@example.com"}
{"id": 2, "name": "Bob", "email": "bob@example.com"}load_json_datasetLoad a JSON dataset using a jq expression that returns an array of records.
Parameters:
file_path (string): Path to the JSON file
jq_expression (string): jq expression that returns an array
Examples:
# For a JSON file like:
{
"users": [
{"id": 1, "name": "Alice"},
{"id": 2, "name": "Bob"}
]
}
# Use jq expression: ".users"
# Or for nested data: ".data.users[]"
# Or with filtering: ".users | map(select(.active == true))"get_next_recordGet the next record from the currently loaded dataset.
Returns:
Record number and progress information
The actual record data
Total dataset size
save_resultSave a processing result for the current record.
Parameters:
result (string): The processing result to save
reset_to_startReset the iterator to the beginning of the dataset.
jump_to_recordJump to a specific record number in the dataset.
Parameters:
record_number (number): The record number to jump to (0-based index)
get_statusGet current processing status and progress information.
Returns:
Current dataset path
Current record position
Total records
Completed processing count
Remaining records
export_resultsExport all processing results to a file.
Parameters:
output_path (string): Path where to save the results
Example dataset (customer_data.jsonl):
{"id": 1, "name": "Alice Johnson", "email": "alice@example.com", "purchases": 15}
{"id": 2, "name": "Bob Smith", "email": "bob@example.com", "purchases": 3}
{"id": 3, "name": "Carol Brown", "email": "carol@example.com", "purchases": 22}Example conversation:
Load the dataset:
👤 "Load my customer data from /home/user/customer_data.jsonl"
🤖 [Uses load_dataset tool]
"Successfully loaded dataset with 3 records from /home/user/customer_data.jsonl"Start processing records:
👤 "Get the next customer record for analysis"
🤖 [Uses get_next_record tool]
"Record 1/3:
{
"id": 1,
"name": "Alice Johnson",
"email": "alice@example.com",
"purchases": 15
}"
👤 "Analyze this customer's purchase behavior and categorize them"
🤖 "Based on Alice Johnson's 15 purchases, I would categorize her as a 'Regular Customer'
with moderate engagement. She shows consistent purchasing behavior that suggests
loyalty but isn't in the high-value segment yet."
👤 "Save that analysis"
🤖 [Uses save_result tool]
"Result saved for record 1. Processing progress: 1/3"Continue with next records:
👤 "Get the next record"
🤖 [Uses get_next_record tool and continues the process]Check progress anytime:
👤 "What's my current processing status?"
🤖 [Uses get_status tool]
"Currently processing customer_data.jsonl: record 2 of 3 total records.
Completed analysis for 1 record, 1 remaining."Example dataset (company_data.json):
{
"employees": [
{"id": 1, "name": "John Doe", "department": "Engineering", "active": true, "salary": 75000},
{"id": 2, "name": "Jane Smith", "department": "Marketing", "active": false, "salary": 65000},
{"id": 3, "name": "Mike Wilson", "department": "Engineering", "active": true, "salary": 80000}
],
"projects": [
{"id": "P001", "name": "Website Redesign", "status": "active", "budget": 50000},
{"id": "P002", "name": "Mobile App", "status": "planning", "budget": 120000}
],
"sales": {
"2024": {
"Q1": [
{"month": "January", "amount": 15000, "client": "TechCorp"},
{"month": "February", "amount": 22000, "client": "StartupInc"},
{"month": "March", "amount": 18500, "client": "Enterprise Ltd"}
]
}
},
"metadata": {
"last_updated": "2024-09-16",
"total_employees": 3
}
}Basic JSON Processing Examples:
Load all employees:
👤 "Load the employee data from /home/user/company_data.json, I want to process all employees"
🤖 [Uses load_json_dataset with jq_expression: ".employees"]
"Successfully loaded JSON dataset with 3 records from /home/user/company_data.json
using jq expression: .employees"
👤 "Get the first employee"
🤖 [Uses get_next_record tool]
"Record 1/3:
{
"id": 1,
"name": "John Doe",
"department": "Engineering",
"active": true,
"salary": 75000
}"Load and filter active employees only:
👤 "Actually, let me reload and only process active employees"
🤖 [Uses load_json_dataset with jq_expression: ".employees | map(select(.active == true))"]
"Successfully loaded JSON dataset with 2 records from /home/user/company_data.json
using jq expression: .employees | map(select(.active == true))"
👤 "Perfect! Now I only have active employees to analyze."Load projects data:
👤 "Now load the projects from that same file"
🤖 [Uses load_json_dataset with jq_expression: ".projects"]
"Successfully loaded JSON dataset with 2 records using jq expression: .projects"
👤 "Get the next project"
🤖 [Uses get_next_record tool]
"Record 1/2:
{
"id": "P001",
"name": "Website Redesign",
"status": "active",
"budget": 50000
}"Load nested sales data:
👤 "Load the Q1 sales data from the same JSON file"
🤖 [Uses load_json_dataset with jq_expression: ".sales.\"2024\".Q1"]
"Successfully loaded JSON dataset with 3 records using jq expression: .sales.\"2024\".Q1"
👤 "Show me the first Q1 sale"
🤖 [Uses get_next_record tool]
"Record 1/3:
{
"month": "January",
"amount": 15000,
"client": "TechCorp"
}"Advanced JSON Processing with Filtering:
Filter by salary range:
👤 "Load only employees with salary above 70000 from /home/user/company_data.json"
🤖 [Uses load_json_dataset with jq_expression: ".employees | map(select(.salary > 70000))"]
"Successfully loaded JSON dataset with 2 records using filter for high-salary employees"Filter by department:
👤 "Load only Engineering employees from that same file"
🤖 [Uses load_json_dataset with jq_expression: ".employees | map(select(.department == \"Engineering\"))"]
"Successfully loaded JSON dataset with 2 records using jq expression:
.employees | map(select(.department == \"Engineering\"))"Complex filtering with multiple conditions:
👤 "Load active Engineering employees with salary above 75000"
🤖 [Uses load_json_dataset with jq_expression: ".employees | map(select(.department == \"Engineering\" and .active == true and .salary > 75000))"]
"Successfully loaded JSON dataset with 1 record matching your criteria"Load and transform data structure:
👤 "Load employee names and departments only from the JSON file"
🤖 [Uses load_json_dataset with jq_expression: ".employees | map({name: .name, dept: .department})"]
"Successfully loaded JSON dataset with 3 transformed records"
👤 "Show the first transformed record"
🤖 [Uses get_next_record tool]
"Record 1/3:
{
"name": "John Doe",
"dept": "Engineering"
}"Example conversations:
Load all employees:
👤 "Load the employee data from /home/user/company_data.json, I want to process all employees"
🤖 [Uses load_json_dataset with jq_expression: ".employees"]
"Successfully loaded JSON dataset with 3 records from /home/user/company_data.json
using jq expression: .employees"Load only active employees:
👤 "Actually, let me reload and only process active employees"
🤖 [Uses load_json_dataset with jq_expression: ".employees | map(select(.active == true))"]
"Successfully loaded JSON dataset with 2 records from /home/user/company_data.json
using jq expression: .employees | map(select(.active == true))"
👤 "Get the first active employee"
🤖 [Uses get_next_record tool]
"Record 1/2:
{
"id": 1,
"name": "John Doe",
"department": "Engineering",
"active": true,
"salary": 75000
}"Load and filter by department:
👤 "Load only Engineering employees from that same file"
🤖 [Uses load_json_dataset with jq_expression: ".employees | map(select(.department == \"Engineering\"))"]
"Successfully loaded JSON dataset with 2 records using jq expression:
.employees | map(select(.department == \"Engineering\"))"Complex dataset processing example:
👤 "Load sales data from /data/quarterly_sales.json, but only get Q3 sales where amount > 1000"
🤖 [Uses load_json_dataset with jq_expression: ".quarters.Q3.sales | map(select(.amount > 1000))"]
👤 "Perfect! Now analyze each high-value Q3 sale for trends"
🤖 [Uses get_next_record, provides analysis]
👤 "That's interesting. Save this analysis: 'High-value enterprise client, shows seasonal purchasing pattern, recommend Q4 follow-up'"
🤖 [Uses save_result tool]
👤 "Continue to the next record"
🤖 [Continues processing...]
👤 "Actually, let me jump back to record 1 to compare"
🤖 [Uses jump_to_record with record_number: 0]
👤 "When I'm done, export all my analysis to /results/q3_analysis.json"
🤖 [Uses export_results tool]👤 "Reset back to the beginning of the dataset"
🤖 [Uses reset_to_start tool]
👤 "Jump to record number 5"
🤖 [Uses jump_to_record tool]
👤 "How many records are left to process?"
🤖 [Uses get_status tool]
👤 "Export all my results so far to /backup/partial_results.json"
🤖 [Uses export_results tool]Scenario 1: Employee Performance Review
// hr_data.json
{
"employees": [...],
"performance_reviews": [...],
"departments": {...}
}👤 "Load employees from hr_data.json for performance review analysis"
🤖 [Uses load_json_dataset with ".employees"]
👤 "Get the next employee for review"
🤖 [Shows employee record]
👤 "Analyze their performance metrics and provide recommendations"
🤖 [Analysis] "Save this review: 'Strong performer, recommend for senior role'"
🤖 [Uses save_result]Scenario 2: Sales Data Analysis
// quarterly_sales.json
{
"2024": {
"Q1": [...],
"Q2": [...],
"Q3": [...]
}
}👤 "Load high-value Q3 sales over $5000 from quarterly_sales.json"
🤖 [Uses load_json_dataset with ".\"2024\".Q3 | map(select(.amount > 5000))"]
👤 "Analyze each sale for client retention patterns"
🤖 [Processes each high-value sale individually]Scenario 3: Product Inventory Management
// inventory.json
{
"products": [...],
"categories": [...],
"suppliers": [...]
}👤 "Load low-stock products (quantity < 50) from inventory.json"
🤖 [Uses load_json_dataset with ".products | map(select(.quantity < 50))"]
👤 "For each product, determine reorder priority and supplier contact"
🤖 [Processes each low-stock item with business logic]JSON Format Advantages:
Single file with multiple related datasets
Supports complex nested structures
Rich metadata and context in same file
Flexible data organization (arrays, objects, nested data)
JSONL Format Advantages:
Simpler, one record per line
Easy to append new records
Streaming-friendly for large datasets
Direct processing without jq expressions
Choosing the Right Format:
Use JSON when you have structured data with multiple related arrays or need to filter/transform data
Use JSONL when you have simple records and want straightforward line-by-line processing
Basic Array Extraction:
Extract all items from an array: ".items"
Extract users: ".users"
Extract projects: ".projects"
Nested Data Access:
Get nested arrays: ".sales.\"2024\".Q1"
Multiple levels: ".departments.engineering.employees"
Filtering Examples:
Filter by condition: ".users | map(select(.status == \"active\"))"
Salary range: ".employees | map(select(.salary > 70000))"
Department filter: ".employees | map(select(.department == \"Engineering\"))"
Multiple conditions: ".employees | map(select(.active == true and .salary > 75000))"
Date filtering: ".sales.\"2024\".Q1 | map(select(.amount > 20000))"
Data Transformation:
Transform structure: ".items | map({id: .id, name: .properties.name})"
Rename fields: ".employees | map({emp_id: .id, full_name: .name, dept: .department})"
Calculate values: ".sales.\"2024\".Q1 | map({client: .client, amount: .amount, tax: (.amount * 0.1)})"
Complex jq Expressions:
Sort by field: ".employees | sort_by(.salary) | reverse"
Group by department: ".employees | group_by(.department)"
Count active users: ".users | map(select(.active == true)) | length"
Sum values: ".sales.\"2024\".Q1 | map(.amount) | add"
@modelcontextprotocol/sdk: MCP server framework
node-jq: JSON processing with jq expressions
typescript: TypeScript compiler
No API Keys Required: Works through your MCP-compatible chat interface
Stateful Processing: Maintains progress between requests
Flexible Data Access: Support for complex JSON structures with jq
Error Recovery: Resume processing from where you left off
Result Persistence: Save and export processing results
Progress Tracking: Always know where you are in the dataset
This approach combines the power of programmatic dataset iteration with the convenience of a conversational interface.
No API Keys Required: The MCP server acts as middleware, and you interact through your regular chat interface
Stateful Processing: The server maintains state between requests, tracking your progress
Flexible Navigation: You can jump to specific records, reset, or continue where you left off
Error Recovery: If something goes wrong, your progress is maintained
Export Capabilities: Save your processing results at any time
Export all processing results to a file
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes | Path where to save the results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It fails to disclose critical behaviors: file format, overwrite behavior, idempotency, or side effects. This lack of transparency could lead to misuse.
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 is a single, front-loaded sentence that wastes no words. It is appropriately concise for a simple tool, earning the highest score.
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?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic purpose. However, it omits important context like export format, behavior on existing files, and integration with other tools.
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% with a description for 'output_path', providing clear parameter meaning. The tool description adds no additional semantics beyond what the schema already provides, so baseline score of 3 is appropriate.
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 clearly states the verb 'Export' and resource 'processing results', indicating the tool's purpose. However, it lacks explicit differentiation from the sibling tool 'save_result', which could cause confusion about when to use each.
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 guidance is provided on when to use this tool vs alternatives like 'save_result'. The description does not mention prerequisites, such as requiring prior processing, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the next record from the dataset for processing
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It reveals 'get' indicating a read operation, but fails to clarify whether calling this tool is destructive (e.g., consumes the record) or if it can be repeated. The stateful nature is implied but not explained.
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?
Single sentence, front-loaded with purpose, no redundant words. Could be improved by adding a brief usage note, but overall efficient.
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?
Incomplete for the task complexity. Lacks prerequisites (e.g., dataset must be loaded), behavior details (e.g., iterative nature, what happens at end), and interaction with sibling tools. Sibling names hint at context but description does not connect them.
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?
No parameters (0 params, 100% schema coverage). The description adds no parameter details, which is acceptable per baseline for high coverage. However, it misses implicit requirements like the need for a loaded dataset, which would be expected from the name.
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 clearly states the action ('Get') and the resource ('next record from the dataset for processing'). It implies sequential access, loosely distinguishing it from siblings like 'jump_to_record' or 'reset_to_start', but does not explicitly differentiate.
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 guidance on when to use this tool versus alternatives. Lacks context such as requiring a prior dataset load or that it advances an internal pointer. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current processing status and progress
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the tool gets status but does not note that it is read-only, whether it has side effects, or what the response looks like. This is insufficient for a simple tool.
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?
A single sentence that is front-loaded and contains no extra words. It is appropriately concise for a simple, parameterless tool.
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?
Despite zero parameters, the description lacks explanation of the return value or output format. Since there is no output schema, the agent cannot infer what 'status and progress' actually includes. Completeness is low.
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?
There are no parameters, and schema description coverage is 100%, so baseline is 3. The description does not need to add parameter info, but also does not clarify the absence or imply additional context.
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 clearly states the tool retrieves 'current processing status and progress', which is a distinct resource from sibling tools like export_results or get_next_record. The verb 'get' and resource are specific and unambiguous.
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 guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical use case scenarios, or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Jump to a specific record number in the dataset
| Name | Required | Description | Default |
|---|---|---|---|
| record_number | Yes | The record number to jump to (0-based index) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action but does not mention side effects (e.g., updates current pointer), error handling for out-of-range numbers, or whether the operation is destructive. This is a significant gap.
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 is a single sentence, concise and front-loaded. However, it could be slightly more structured (e.g., mentioning the index base), but still efficient for its length.
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?
Given the tool has no output schema and no annotations, the description should explain the return behavior or state change. It lacks information on what happens after the jump (e.g., returns the record, moves pointer) and error scenarios, making it incomplete for an agent.
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% with an explicit description for the parameter. The tool description adds 'specific' but does not provide additional meaning beyond the schema. Baseline of 3 is appropriate.
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 uses a clear verb ('Jump to') and resource ('specific record number in the dataset'), making the tool's purpose immediately understandable. It is distinct from sibling tools like 'get_next_record' which implies sequential access.
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 guidance is given on when to use this tool versus alternatives like 'get_next_record' or 'reset_to_start'. The description provides no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a dataset file for processing (supports JSON Lines format)
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the dataset file (JSON lines format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not mention side effects, error handling, or what happens after loading (e.g., state changes). The simple verb 'load' is insufficient for full transparency.
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 is a single sentence with no filler words. It efficiently conveys the core action and format constraint.
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?
Given no output schema and no annotations, the description should cover return behavior, error cases, or differentiation from load_json_dataset. It lacks this context, making it incomplete for an agent to use confidently.
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%, with the param description already explaining the file path. The tool description adds 'supports JSON Lines format', which reinforces but does not significantly extend semantic meaning beyond the schema.
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 states the verb 'Load' and the resource 'dataset file', and specifies format support (JSON Lines). However, it does not differentiate from the sibling tool 'load_json_dataset', which likely has a similar purpose.
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 guidance is provided on when to use this tool versus alternatives like load_json_dataset or other siblings. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a JSON dataset using a jq expression that returns an array of records
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the JSON file | |
| jq_expression | Yes | jq expression that returns an array (e.g., '.data[]', '.items', '.[].records') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention error handling (e.g., file not found, invalid jq), side effects, or performance implications. The description is too brief for full transparency.
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 is a single sentence with no wasted words. It is concise and front-loaded, but lacks any structural elements like sections, which could enhance readability for longer descriptions.
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?
Given the absence of an output schema, the description should explain what the tool returns. It does not describe the output format or behavior (e.g., whether it returns the array directly or a wrapper). This is a significant gap for a tool with no output schema.
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 description coverage is 100% for both parameters. The description adds value by clarifying the jq_expression parameter's expected output type ('returns an array of records'), which goes beyond the schema's generic description. This offsets the high coverage baseline.
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 clearly states it loads a JSON dataset using a jq expression returning an array of records. The verb 'Load' and resource 'JSON dataset' are specific, and the mention of jq distinguishes it from siblings like 'load_dataset'.
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 gives context for when to use (load JSON with jq) but does not explicitly state when not to use or recommend alternative tools. Implicit usage guidance is present but not exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset the iterator to the beginning of the dataset
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Merely states the action without disclosing side effects, prerequisites (e.g., dataset must be loaded), or return behavior. Incomplete for a mutation tool.
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?
Single sentence with 8 words, no redundancy. Efficiently communicates the core action.
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?
Lacks context on prerequisites (e.g., dataset must be loaded), return value, and side effects. For a simple tool, missing critical details for correct invocation.
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?
No parameters in schema, baseline 4. Description does not add parameter info because none exist.
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?
Describes a specific action: resetting an iterator to the beginning of the dataset. Verb+resource clearly defined. Distinguishes from siblings like get_next_record and jump_to_record.
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?
Implied usage: when you need to start iteration over. No explicit when-not-to-use or alternatives mentioned, leaving some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the processing result for the current record
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | The processing result to save |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'save', implying a mutation, but gives no details about side effects (e.g., overwrite behavior, confirmation requirements, or storage limits).
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 is a single sentence with no wasted words. For a simple tool, this is efficient, though it lacks any structured formatting.
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?
Given the low complexity (1 param, no output schema), the description is minimally adequate but fails to explain the concept of 'current record' or how results are persisted, which could be important for an agent new to the workflow.
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% (one parameter with description). The tool description adds no additional meaning beyond what the schema already provides; it merely restates the parameter's purpose. Baseline score of 3 is appropriate.
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 clearly specifies the action ('save'), the resource ('processing result'), and the context ('for the current record'). It is a specific verb+resource combination that distinguishes from siblings like 'export_results' or 'load_dataset'.
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 guidance is given on when to use this tool versus alternatives, such as 'export_results'. The description provides no context about prerequisites, workflow position, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0export_resultsget_next_recordget_statusjump_to_recordload_datasetload_json_datasetreset_to_startsave_resultEach tool has a clearly distinct purpose: loading datasets (two separate tools for different formats), navigating records (next, jump, reset), obtaining status, and saving/exporting results. No overlaps or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case, using appropriate verbs like get, load, save, export, jump, and reset. The naming convention is uniform and predictable.
With 8 tools, the server covers the essential operations for an iterator: dataset loading, record navigation, processing, status tracking, and result export. The count is balanced—neither sparse nor bloated.
The tool set covers the full lifecycle of iterative processing: loading data (including a variant for jq expressions), navigating (next, jump, reset), saving per-record results, and exporting all results. Missing features like batch operations or record deletion are minor gaps given the server's focused scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Validate and convert JSONL fine-tuning data across 11 AI providers. 13 tools.
Turn documents into structured, AI-ready data by parsing, enriching, chunking, and embedding.
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Run SOQL queries to explore and retrieve Salesforce data. Inspect records, fields, and relationshi…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bmordue/iterator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
