A fast, secure MCP server that extends its capabilities through WebAssembly plugins with support for multiple transport mechanisms and cognitive memory systems
SweetMCP exposes 17 tools with minimal definition structure. Most tools have basic descriptions (10-50 chars) falling well below the 194-char baseline for A+ tools. Input schemas are visible in the specification but severely underdeveloped: parameters lack type constraints, enums, ranges, and detailed descriptions. Several tools (eval_javascript, eval_python, eval_rust, eval_shell) present extreme security risks with no validation guidance or permission gates. No output schemas are documented. Error handling is absent, tools provide no recovery guidance. The server's plugin-based architecture prevents verification of actual tool registration code; tool definitions appear inferred rather than explicitly registered in the codebase provided.
Tools (17)
arxiv_searchread only50/100
Search arXiv for academic papers
browser_get_pageread only45/100
Fetch and return the content of a web page using a browser
No input schema documents result limits, pagination, or field constraints. Most tools accept freeform strings without enum constraints. The 'code' parameter in code execution tools accepts arbitrary payloads with no format specification or length limit.
Expand all tool descriptions to 80 - 200 characters, including WHAT the tool does, WHEN to use it, prerequisites, and side effects. Example: 'Execute Python code in an isolated environment. Use for calculations, data transformations, and script testing. Supports standard library only. WARNING: Code is executed with full filesystem access, use with trusted input only.'
Document output schemas for all tools. At minimum, specify the return type (string, object, array), key fields, and their types. For list-returning tools (arxiv_search, fs_list_directory, browser_get_page), add pagination fields (items[], total_count, next_cursor) and clarify result limits.
Add parameter descriptions and type constraints. For example: 'max_results' should specify 'Integer, 1 - 100 (default: 20).' For 'path' in file tools, add 'String, absolute path. Must be within /allowed/directory. Symlinks not followed.'
Implement input validation and error recovery. Add examples: 'eval_shell returns {status: exit_code, stdout, stderr}. Non-zero status is retryable; EACCES (permission denied) indicates missing permissions; ENOENT (file not found) means the command or script does not exist.'
Gate code execution tools with permission checks and sandboxing. Require explicit agent capability grants (e.g., 'code_execution' scope). Document resource limits (CPU time, memory, file size). Return timeout errors with clear guidance.
For file system tools, define allowed paths. Document whether paths are sandboxed to a specific directory, whether symlinks are followed, file size limits, and whether overwrite behavior is supported. Return clear errors: 'Path outside allowed root: /etc/passwd. Allowed root: /workspace'.
No output schemas documented. LLMs cannot predict response structure, required fields, or pagination details. This prevents chaining tools together reliably (e.g., if search returns results, what fields are included? Is there a next_cursor or total_count?).
Tool descriptions are uniformly short (20-50 chars) and lack WHEN-to-use context, prerequisites, or state-modification warnings. E.g., 'Write content to a file' does not explain: overwrites existing file? Supports atomic writes? Returns what?
File system tools (fs_read_file, fs_write_file, fs_list_directory) accept path parameters with no validation guidance (no allowed directories, no symlink traversal warnings, no size limits). Agents could read/write arbitrary files with no constraints.
No error handling guidance. Tools provide no recovery hints (e.g., 'User not found. Try search_users()' pattern). LLMs cannot distinguish retryable failures from fatal ones. No actionable error messages documented.
Tools with state-modifying side effects (fs_write_file, eval_*) lack dry-run or confirmation patterns. Agents cannot preview changes before committing irreversible operations. No idempotency guarantees documented.
Tool definitions appear inferred from plugin list rather than explicitly visible in source code. No actual tool registration code (with full schema, description, and handler) provided for verification. Cannot confirm schemas are complete or properly typed.
Add confirmation/dry-run patterns for destructive tools. E.g., eval_shell could accept a dry_run=true parameter that shows the command to be executed without running it. fs_write_file could return a preview of changes before committing.
Implement tool annotations (from MCP spec) to mark read-only, destructive, and idempotent operations. Use readOnlyHint for arxiv_search, hash_*, ip_lookup; destructiveHint for fs_write_file, eval_*; idempotentHint for browser_get_page, fetch_url.
Provide source code for at least one plugin (e.g., sweetmcp-plugins/arxiv/src/lib.rs, sweetmcp-plugins/fs/src/lib.rs) showing the actual tool registration, schema definition, and error handling logic. Current submission relies on inferred definitions.
Add rate limiting and timeout guidance to all tools. Specify: 'Max 10 requests per minute. Timeout: 30 seconds for network tools, 5 seconds for code execution.' Return clear timeout errors with retry guidance.
Document which parameters are mutually exclusive or dependent. E.g., if fetch_url's 'headers' parameter conflicts with a 'auth' parameter, state this explicitly in both descriptions.
For tools that chain (e.g., arxiv_search → fetch_url → reason), ensure output from one includes all IDs/references the next requires. E.g., arxiv_search should return paper IDs; fetch_url should accept those IDs; reason should accept URLs from fetch_url.