Loading ToolBench
MCP HTTP Streamable Server for NexusOne API integration, supporting file uploads, data ingestion from files and databases, job status monitoring, and job triggering
The NexusOne MCP server exhibits mediocre definition quality with significant gaps in schema completeness, parameter documentation, and error handling. While tool names follow verb_noun convention reasonably well, descriptions vary in quality (some are detailed, others generic). Critical issues: (1) upload_file has empty 'required' array despite needing at least one of file_path or source_url; (2) ingest_from_file and ingest_from_database lack enum constraints for critical 'mode' and 'file_format' parameters in descriptions; (3) no documented output schemas for any tool, LLMs cannot plan downstream operations; (4) error handling is not visible in tool definitions; (5) parameters like 'jdbc_password' expose credentials as parameters, violating secret-injection pattern. The server acknowledges streaming support in descriptions but does not provide structured guidance on how streaming responses differ from standard responses.
Check the status of an ingestion or processing job
Ingest data from a database connection (JDBC). Server supports progressive streaming via /mcp/stream.
Ingest data from an uploaded file. Note: owner_id (user email) may be required by the API. Server supports progressive streaming via /mcp/stream.
Trigger a processing job to run immediately
Upload a file to NexusOne API. Supports two methods: 1) Local file upload via file_path, 2) URL-based upload via source_url (public URL)
No output schemas documented for any tool. LLMs cannot determine what fields are returned, preventing effective downstream tool chaining and response parsing.
jdbc_password exposed as a tool parameter. Credentials must never appear in tool parameters, they will be logged in traces and agent histories, creating a security breach. Use server-side secret injection via environment variables or vault.
upload_file has 'required: []' (empty required array) despite needing at least one of file_path or source_url. This creates ambiguity, LLMs will not know which parameter is mandatory. Declare mutual exclusivity or require one parameter explicitly.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | 2024-11-05+ | v1 |
ingest_from_file and ingest_from_database parameters 'mode' and 'file_format' use enums in schema but lack clear descriptions of what each enum value does. Parameter descriptions should state consequences: 'mode=append adds to existing data; mode=overwrite replaces all data; mode=merge matches on specified columns'.
trigger_job and check_job_status descriptions are minimal (45-50 chars) and lack context. When should an agent call trigger_job vs waiting for a scheduled job? What does check_job_status return, a status enum, timestamps, progress %, error messages? Add 50-150 character descriptions with concrete details.
ingest_from_database requires 8 parameters, many without defaults (name, jdbc_url, jdbc_username, jdbc_password, jdbc_type, schema_name, table, mode). No guidance on optional parameters or dependencies (e.g., 'jdbc_query is required only when jdbc_type=query'). Complex parameter interactions need explicit documentation.
No error handling guidance visible in tool definitions. If a file upload fails, what should the agent do? Retry? Call check_job_status? Ask the user? Missing recovery patterns force trial-and-error behavior.
ingest_from_file description mentions 'owner_id (user email) may be required by the API' but does not clarify when or why. This creates uncertainty, will the tool fail without it? Should the agent always pass a user email? Provide clear guidance: 'Required when…', 'Defaults to…', or 'Optional for…'.