Learn to build AI agents with Model Context Protocol - collection of example MCP servers for data analysis, file systems, task management, databases, web APIs, and data pipelines
Mixed quality across 31 tools. Strengths: most tools have descriptions and basic schemas present. Critical weaknesses: (1) Multiple tools lack parameter type definitions or have incomplete schemas (e.g., filter_data's 'conditions' array has no itemSchema), (2) Descriptions are often under the 50-200 char LLM-optimized range, (3) No output schemas documented for ANY tool, (4) No error handling guidance or recovery hints, (5) Security tools (delete_file, delete_task, delete_data) lack confirmation/dry-run patterns, (6) Parameter descriptions are sparse or missing detail about constraints, (7) No tool annotations (readOnlyHint, destructiveHint) visible. The toolkit reads as a tutorial starter rather than production-ready. File system tools are reasonable; data pipeline tools rely on undocumented session state.
Aggregate data by a column
Analyze a specific column (get stats, distributions, etc.)
Check inventory levels for a specific product
Mark a task as complete by ID
Continue pipeline from current stage to the next stage
Create a new task with title and optional description
Delete data from a table
filter_data tool has no itemSchema for 'conditions' array parameter, LLMs cannot validate what structure each condition object must have (e.g., required fields 'column', 'operator', 'value'). This invites malformed input and silent failures.
No output schemas documented for ANY of the 31 tools. LLMs cannot plan downstream calls or extract needed fields. E.g., list_data_files returns 'files' array, but LLM doesn't know field names (path? filepath? name?), making chaining brittle.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Delete a file
Delete a task by ID
Get schema and metadata for a specific table
Filter data based on conditions
Get analytics report for specified metric and date range
Get summary statistics and column info for a data file
Get details for a specific order by ID
Get current pipeline state and results
Get details for a specific product by ID
Get information about the workspace directory
Insert data into a table
Join two files and aggregate the result
List all available data files (CSV and JSON)
List files in a directory
List orders with optional filters
List products from the e-commerce API with optional filters
List all tables in the connected database
List all tasks, or only incomplete tasks
Execute a SQL SELECT query against the database
Read contents of a file
Run data pipeline (executes all stages from current position)
Search for files by name or content
Update data in a table
Write content to a file (creates if doesn't exist)
Destructive tools (delete_data, delete_file, delete_task) lack dry-run or confirmation step. No error guidance on recovery. LLM can accidentally delete without safeguards, violates pattern:confirmation-request.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot determine which tools are safe to retry or have side effects, required for robust multi-step planning.
join_and_aggregate and run_pipeline combine multiple responsibilities (join + aggregate, run + continue). Should split into separate tools per pattern:tool so agent can compose as needed.
Pipeline tools (run_pipeline, continue_pipeline, get_pipeline_state) use session_id state on server side. No documentation of how sessions are managed, timeouts, or cleanup. Violates stateless request handling (current spec).
Parameter descriptions often under 50 chars and lack constraint details. E.g., 'Filter by status' (20 chars) does not explain valid values or when to use it. Baseline: avg param description 72 chars.
No error handling or recovery guidance visible. Tools return no hints on what LLM should do on failure (e.g., 'Channel not found' does not suggest calling list_channels first). Violates pattern:recovery-guide.
query_database tool accepts raw SQL with no input validation visible. LLM could pass malicious SQL or unbounded queries. Lacks sanitization, timeouts, or rate limits per pattern:tool-gateway.
No pagination documented for list_* tools. list_products, list_orders, list_tables can return thousands of items. No limit defaults, no offset/cursor, no total count in response. Violates pattern:paginated-result.