Loading ToolBench
MCP server for interacting with the Jotform API.
The server exposes 15 tools for JotForm API interaction. While tool names follow verb_noun conventions (get_*, update_*, create_*) and descriptions are present, there are significant gaps: parameters across most tools lack type constraints (no enums for filter arrays or order_by fields); descriptions are present but often minimal (5-50 chars for many params); output schemas are not documented; error handling does not guide recovery; and security best practices around secret injection and permission gating are not evident in the visible code. The Dockerfile shows env-based config which is good, but the implementation does not validate or constrain inputs, and responses are passed through from the underlying API without refinement. This lands solidly in the 'fair' range, definitions are functional but leave much to LLM guesswork.
Create a new submission for a specific form.
Get a list of form folders for this account.
Get basic information about a form.
Get details about a question.
Get a list of all questions on a form.
List of a form submissions.
Get a list of forms for this account.
Filter and ordering parameters lack type constraints and enums. 'filter_array' and 'order_by' are described as freeform strings/objects with no valid values documented, forcing LLMs to guess valid syntax (e.g., 'status:eq', 'ENABLED'). Should provide enums or regex patterns in schema and description.
No output schema documentation. Tools return raw API responses (JSON dumps from jotform.py client) without documenting the structure, field types, or what the LLM should expect. create_form_submission, get_forms, get_submissions lack clarity on returned field names and nesting.
No error recovery guidance. The _execute_jotform_request() function catches exceptions and returns JSON-wrapped error messages, but does not categorize errors (retryable vs. fatal), provide context on why they occurred, or suggest next steps. An LLM receiving 'Jotform API Error: Invalid form ID' has no guidance on how to proceed.
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 | 0 | - | v1 |
Get user activity log.
List of URLS for reports in this account.
Get user's settings for this account.
Get a list of submissions for this account.
Get a list of sub users for this account.
Get number of form submissions received this month.
Get user account details for a JotForm user.
Update user's settings.
Pagination parameters (offset, limit) present but not bounded. No description specifies minimum/maximum values, recommended defaults, or total result counts. Large limit values could cause timeouts or context window overflow. Tools should cap results at reasonable defaults (20-50) and document pagination behavior.
Parameter descriptions are minimal and lack context. Examples: 'Start of each result set for form list' (get_forms.offset) does not explain the expected behavior if offset exceeds total results or if negative. 'Filters the query results' (get_forms.filter_array) provides no examples of valid filter syntax or which fields can be filtered.
No input validation or sanitization visible in tool implementations. Tools pass parameters directly to the underlying JotformAPIClient without checking for SQL injection, path traversal, or malformed input. LLMs can be tricked into passing malicious payloads that the tool does not sanitize.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools declare a 'Risk' in the metadata (e.g., 'READ_ONLY', 'WRITE'), but the MCP tool registration does not include structured annotations. Agents cannot infer which tools are safe to retry without explicit annotation.
JOTFORM_API_KEY exposed in environment variable (Dockerfile ENV) without explicit mention in tool descriptions of authentication requirements or secret handling. While the code correctly uses env vars for injection, there is no documentation that users must protect their API key, and the Dockerfile comment acknowledges this but tool descriptions do not warn agents of secret sensitivity.