Loading ToolBench
A Next.js application for resume optimization with AI-powered document editing, keyword analysis, and LaTeX compilation. Features quick optimization mode and manual studio mode with chat-based document manipulation.
This server defines 5 tools for document editing operations (doc_analyze, doc_section, doc_search, doc_read, doc_edit). All tools have descriptions and input schemas. However, there are significant gaps: (1) tool names do not follow verb_noun conventions consistently (e.g., 'doc_analyze' should be 'analyze_document' or 'get_document_analysis'); (2) output schemas are NOT documented anywhere in the visible code, the source shows input parameter definitions but NO output type definitions; (3) parameter descriptions are verbose and contain example values, which violates the pattern that LLMs latch onto examples; (4) no error handling guidance is visible, tools return success/failure booleans but do not describe what errors mean or how to recover; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY vs WRITE). The tools do follow a logical sequence (search → read → edit), but composition could be tighter. None of the tools accept natural identifiers (usernames, section names are parameterized but not truly human-friendly). Overall, this is a D-grade implementation: functional schemas, weak naming, no output documentation, missing annotations, and generic error responses.
Get the FULL document content to analyze and identify which lines to edit. Use this when: 1) doc_search returns 0 results, 2) user requests multiple changes at once, 3) you need to understand document structure. This returns the entire document with line numbers so you can see everything and decide what to edit.
ACTUALLY edit and modify lines in the document. Use this whenever the user asks to change, update, add, or delete content. Operations: replace (change existing line text), insert (add new lines), delete (remove lines). This tool makes real changes to the document that will be saved and visible to the user. Cannot edit locked lines.
Read specific lines from the document by their line numbers. Use this to verify the current content of lines before editing them, or when the user references specific lines with @line notation.
Search for WHERE to edit by finding lines with specific field names. Use 1-2 WORD keywords ONLY - just the field name you're looking for (e.g., "investor", "purchase", "date", "company"). Do NOT include values (NOT "investor Sebastian Grol", NOT "date Oct 30"). You're searching for the LOCATION to edit, not the VALUE to set. Returns up to 5 most relevant lines with their line numbers.
Output schemas completely missing. No visible documentation of what any tool returns. Callers cannot plan downstream chaining or extract required fields.
Tool names do not follow verb_noun convention (doc_* prefix is non-standard). LLMs rely on action verbs to infer intent, 'analyze_document', 'search_document', 'read_document', 'edit_document', 'get_document_section' are clearer.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. doc_read, doc_analyze, doc_section, doc_search are read-only; doc_edit is destructive. Agents cannot determine retry safety without annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Find and read a specific section of the resume by name (e.g., "experience", "skills", "education", "projects"). Returns the section content with line numbers. IMPORTANT: After calling this, you MUST call doc_edit to make changes - do NOT call doc_section again. Use this when the user mentions editing a specific section like "add Docker to my experience" or "update my skills section".
Descriptions contain example values that LLMs may reuse literally. doc_search describes 'investor', 'date', 'company' as examples; doc_analyze says 'search returned no results'; doc_section says 'add Docker to my experience'. These should be in parameter enums or replaced with formal constraints.
No error handling guidance. Tools return {success: boolean, content: string} but do not document what errors mean, why they occurred, or how to recover. For example, doc_section returning success=false with content='Section name is required' is a bare validation error, no guidance on retry or fallback.
Parameter 'newText' in doc_edit is conditionally required (needed for replace/insert, not delete) but schema marks it as optional without constraints. Schema should enforce required/conditional logic or description should be explicit.
doc_section parameter 'sectionName' has no enum constraint. Valid sections (experience, skills, education, projects, summary, certifications, awards) are defined in SECTION_ALIASES object in code but NOT exposed in tool schema, forcing LLMs to guess.
Descriptions are overly verbose (200-250 chars average, well above 194 baseline). Use positive constraints (enums, format rules) instead of prescriptive language ('you MUST', 'do NOT').