Loading ToolBench
An MCP server that leverages DeepSeek R1's advanced reasoning capabilities through the Infini API, formatting reasoning output for integration with DeepSeek V3 or Claude.
This server has a single tool 'reason' with significant quality gaps. The tool name lacks a proper action verb (should be 'run_reasoning' or 'get_deepseek_reasoning'). The description, while lengthy (271 chars), is verbose and marketing-focused rather than actionable for LLM tool selection. The input schema shows structural definition but lacks proper parameter descriptions, 'query' is described as an object 'Contains the following keys' but the actual properties (context, question) have only bare descriptions ('Optional background information', 'The specific question'). The schema structure is malformed: 'query' is marked as type 'object' with properties nested under it, but LLMs expect flattened parameters (context, question as sibling params, not nested under query). The implementation has critical bugs: the code references undefined variable 'r1_reasoning' in string slicing operations (line with r1_reasoning[:150]), which will crash at runtime. Error handling is present but returns unstructured XML-like output that won't help LLMs recover. No pagination, no output schema documentation, no validation of input constraints. The tool is READ_ONLY per risk declaration, but this is not reflected in the description or parameter guidance.
Process a query using DeepSeek's R1 reasoning engine and prepare it for integration with DeepSeek V3 or claude. DeepSeek R1 leverages advanced reasoning capabilities that naturally evolved from large-scale reinforcement learning, enabling sophisticated reasoning behaviors. The output is enclosed within `<ant_thinking>` tags to align with V3 or Claude's thought processing framework.
Tool name 'reason' does not start with an action verb. Per Arcade pattern:tool, tool names must start with verbs (get_, create_, update_, delete_, search_, list_, send_, run_). 'reason' is a noun; should be 'run_reasoning' or 'get_deepseek_reasoning'.
Input parameter descriptions are incomplete and vague. 'context' has description 'Optional background information for the query' (42 chars) and 'question' has 'The specific question to be analyzed' (35 chars). These are too generic and don't explain format/constraints. Example: missing guidance on max length, encoding, or content type expectations.
Input schema structure is malformed. The schema defines 'query' as type 'object' with nested properties (context, question). LLM tools expect flattened parameters at the tool root level. This nesting forces LLMs to construct a nested dict, increasing chance of format errors. Correct structure: two sibling parameters 'context' and 'question' at tool input level, both strings, context optional.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 30 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
No output schema documented. The tool returns a string, but LLMs need to know the structure: is it XML? markdown? plain text? Will it contain thinking tags? Per pattern:response-shaper, tools must document output shape. Currently LLMs have no guidance on parsing the response.
Runtime crash: Code at line 'structured_reasoning = f"""<ant_thinking>\n[DEEPSEEK R1 INITIAL ANALYSIS]\n• First Principles: {r1_reasoning[:150]}' references undefined variable 'r1_reasoning'. The function receives 'reasoning' from get_infini_reasoning() but tries to use 'r1_reasoning'. This will raise NameError on every call.
Error handling returns unstructured XML templates that don't guide LLM recovery. Per pattern:recovery-guide, errors must tell LLMs what to do next (retry? ask user? fetch logs?). Current error response is opaque marketing copy with no actionable guidance or error classification.
No input validation or constraints. 'context' and 'question' are unrestricted strings, no max length, no encoding spec, no null-byte protection. Per pattern:tool-gateway, all agent input must be treated as untrusted and sanitized. Unvalidated strings passed to external APIs (Infini) can cause injection attacks or service errors.
API key 'INFINI_API_KEY' is injected via environment variable, which is correct (pattern:secret-injection). However, no validation that the key is present at startup. If missing, the tool will fail cryptically at runtime rather than reporting 'API key not configured' at server init.