MCP server for transfa — upload any file and get a signed link in one tool call
transfa-mcp has 5 tools with clearly defined purposes and a coherent domain (file sharing with provenance tracking). The `upload` tool is notably well-specified with 11 parameters including provenance fields (run_id, step, consumer, intent, upstream_ids) that enable multi-agent handoff, this is sophisticated. However, there are significant gaps: (1) Tool definitions appear inferred from package.json and CLI; the actual MCP server registration code (mcp/index.js) is not shown, so I cannot verify explicit schema registration. (2) Output schemas are completely absent, no documented return types for any tool. (3) Error handling is missing, no guidance on retryability, user-fixable vs. fatal errors, or recovery steps. (4) Parameter descriptions are inconsistent: upload's params are well-annotated (e.g., 'TTL: "1h", "24h", "7d", "30d"'), but file_info, list_uploads, delete_upload, run_artifacts have minimal descriptions. (5) Naming could be more parallel, `upload` vs. `file_info` vs. `delete_upload` mixes verb-object and verb-only patterns. Average tool description quality is 120 chars (below ideal 194), and several params lack actionable format guidance.
Delete an upload immediately. Requires ownership (API key must match the uploader).
Get metadata about an upload without downloading it. Returns filename, size, SHA-256, expiry, download count, active status, and whether the file is in a grace period.
List your recent uploads. Requires TRANSFA_API_KEY or a key saved by `tf auth`.
List all files uploaded under a run_id — the provenance manifest for a pipeline run or agent session. Returns every artifact with its id, filename, sha256, step, consumer, intent, and expiry.
Upload a file from the local filesystem and get a shareable, expiring link. Returns agent_link (direct download URL), human_link (browser share page), and sha256 for integrity. Supports provenance fields (run_id, step, consumer, intent) for multi-agent handoff — these travel with the file and are returned by file_info, so the receiving agent knows who produced it and why. Works without an API key (guest mode, 10 MB limit). Set TRANSFA_API_KEY for larger files and longer TTLs.
No output schemas documented for any tool. LLMs cannot know what fields to expect, forcing them to guess or make follow-up discovery calls.
Tool definitions inferred from package.json; actual MCP server registration code (mcp/index.js) not provided. Cannot verify explicit schema registration via @modelcontextprotocol/sdk.
No error handling guidance. Tools do not explain retryability, user-fixable errors, or recovery steps. E.g., delete_upload should state 'Ownership check fails if API key does not match uploader, try listing uploads to verify ownership.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Parameter descriptions are inconsistent and sparse. file_info's 'id' param is described but not file_info itself. list_uploads has no parameter description for 'limit'. delete_upload and run_artifacts lack actionable format guidance.
Naming inconsistency: 'upload' vs. 'delete_upload' vs. 'file_info'. Tool names lack consistent verb_noun pattern. Should be: 'upload_file', 'get_file_info', 'list_uploads', 'delete_upload', 'list_run_artifacts'.
Destructive operations (delete_upload) and security-sensitive operations (list_uploads requires API key) lack explicit permission or confirmation guidance in descriptions.
list_uploads description states 'Requires TRANSFA_API_KEY' but does not explain fallback or error if missing. Should state: 'Requires TRANSFA_API_KEY (set via environment variable or tf auth). Returns empty list if unauthenticated.'
upload's provenance fields (run_id, step, consumer, intent, upstream_ids) are sophisticated but lack examples or formatting guidance. Should specify: 'run_id: UUID or alphanumeric identifier for the pipeline run. step: descriptive name (e.g., "preprocess", "train"). consumer: agent name or service identifier.'