Loading ToolBench
An MCP server for analyzing academic papers in LaTeX format. Provides tools for classifying papers, scoring papers against criteria, parsing LaTeX documents, and generating review summaries with weakness identification and section matching.
The server has 4 tools with schemas present and descriptions, but significant quality gaps limit adoption readiness. Tool naming is reasonable (verb-prefixed), but descriptions are sparse and lack the context LLMs need for reliable selection. Parameter descriptions exist but are minimal. No documented output schemas. Critical gap: this is an HTTP-only custom server with no MCP protocol implementation, tools are exposed as REST endpoints, not via the MCP protocol. See src/app.ts for tool definitions.
Classify a paper into categories (Algorithm, System, BlogPost, Survey, etc.)
Score a paper and generate a score along with improvement suggestions. Automatically classifies the paper as part of the process.
Generate paper review comments with weakness identification and section matching. Takes a paper's LaTeX source and scoring results to produce actionable feedback with specific section anchors.
Parse paper and return title, abstract, and all sections with content
NOT AN MCP SERVER: This is a custom Express HTTP API, not an MCP-compliant server. No MCP protocol implementation detected. Tools are exposed as REST endpoints (/parse-paper, /classify-paper, etc.), not registered with the MCP server transport.
Tool descriptions are too brief and lack 'when to use' context. parse-paper (28 chars), classify-paper (29 chars), paper-score-comments (28 chars) fall well below the 50-200 char production baseline. LLMs cannot reliably distinguish between parse-paper and classify-paper, both operate on latex, but purpose is unclear from descriptions alone.
No output schemas documented. Callers cannot know what fields to expect from each tool's response. src/app.ts shows res.send(result) for parse-paper and res.send(parsed.sections.find(...)) for classify-paper, but response structure is not formally declared. This forces LLMs to infer response shape.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 23 | - | v1 |
paper-score-comments has a complex nested required parameter 'paperScoreResult' (type object with properties like score, percentile, details, suggestions) but only a one-line description. No documentation of what fields are mandatory in this object or what their types/ranges are. LLMs will struggle to construct valid requests.
Parameter description for 'latexSource' is identical across parse-paper, classify-paper, and paper-score: 'The LaTeX source code of the paper'. No hints about expected size, format constraints, or minimum LaTeX structure. A 1-byte string passes schema validation (minLength=1) but would fail at runtime.
No error handling documentation. src/middleware/error-handler.ts catches ZodError and generic errors, returning 'Invalid request data' or 'Internal Server Error', but tool descriptions do not tell LLMs what errors to expect or how to recover. Example: if LaTeX parsing fails, what error is returned? Can it be retried?
Naming ambiguity: 'paper-score' and 'paper-score-comments' both appear to score/review papers. No description clarifies the difference or when to call each. 'paper-score' generates 'score' + 'suggestions'; 'paper-score-comments' generates 'weaknesses' + 'section mappings'. LLMs will guess wrong.