Enterprise SSE-MCP Bridge exposing zero-shot time-series forecasting (TimesFM 3.0) and tabular classification/regression (TabFM v1.0.0) as MCP tools over HTTP/SSE
Zer0Fit has well-structured tool definitions with complete input schemas and detailed descriptions. All four tools follow verb_noun naming (upload, inspect, forecast, tabular). Descriptions are comprehensive (150-300 chars) and explain WHAT the tool does, WHEN to use it, and key prerequisites. Input schemas are properly typed with required fields marked. However, output schemas are not documented, LLMs cannot predict what fields to expect from responses. Error handling is minimal; no recovery guidance or actionable error messages visible in the code. The server uses HTTP+SSE (Streamable HTTP), which is current. Tool annotations (readOnlyHint, destructiveHint) are absent. Parameter descriptions are excellent but could benefit from explicit format constraints (e.g., base64 encoding rules, file size limits).
Zero-shot time-series forecasting via Google TimesFM 3.0. Provide EITHER file_path (for files on the server) or file_data (for files attached in the chat). When a file is attached, pass its raw CSV contents as file_data — the actual text you see in the conversation, not the file ID.
Inspect a data file to discover its column names, data types, and row count. Use this BEFORE calling zer0fit_forecast or zer0fit_tabular to find the correct target_column name. Provide EITHER file_path (for files already on the server) or file_data (for files attached in the chat). When a file is attached in the chat, pass its raw contents as file_data plus the original filename as file_name.
Zero-shot tabular classification or regression via Google TabFM v1.0.0. Provide EITHER file_path (for files on the server) or file_data (for files attached in the chat). When a file is attached, pass its raw CSV contents as file_data instead of file_path.
Upload a data file to the Zer0Fit server for processing. Supports CSV, XLS, XLSX, JSON, and JSONL formats. The content_base64 parameter must contain the ACTUAL FILE BYTES encoded as base64 (e.g. base64.b64encode(open(path,'rb').read())). Do NOT pass a file ID, URL, UUID, or filename as content_base64. NOTE: If the file was attached in Open WebUI, you can pass the file ID directly as file_path to zer0fit_forecast or zer0fit_tabular — no upload needed. This tool is only for files not already available as attachments. Uploaded files are auto-deleted after 6 hours.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Responses must include chaining IDs (file_path, target_column results) for downstream tool calls.
No error handling guidance. Code does not show recovery hints (e.g., 'File not found. Check file_path or call zer0fit_inspect first'). Errors should categorize as retryable vs user-fixable.
Tool annotations missing. zer0fit_upload_csv is destructive (WRITE risk); zer0fit_inspect, zer0fit_forecast, zer0fit_tabular are read-only. Annotations (readOnlyHint, destructiveHint, idempotentHint) enable agents to reason about side effects.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
Parameter constraints not formalized. 'content_base64' description mentions base64 encoding but no pattern/format constraint. 'horizon' and 'max_chunks' lack min/max bounds. Enums for 'task_type' are present but other constrained params should use JSON Schema patterns.
No pagination or result limits documented. If zer0fit_inspect returns many columns or zer0fit_forecast returns large time-series arrays, responses could exhaust context. Limit results and document in descriptions.