Loading ToolBench
Stateless tool suite for markdown processing and Agent Skill packaging. Every tool is a thin typed wrapper over the same `src/lib` cores the editor uses, so MCP output is identical to in-app output.
MarkSight provides 5 well-structured tools with clear naming, solid descriptions (avg ~180 chars), and complete JSON Schema inputs with type definitions and constraints. However, output schemas are not explicitly documented in the code, parameter descriptions lack depth regarding constraints and validation rules, and there is no evidence of error handling guidance or recovery patterns. The tools follow verb_noun naming (create_skill, validate_skill, etc.) and serve focused purposes. Most descriptions adequately explain the tool's function but fall short of the 'prompt-engineering' standard (WHAT/WHEN/prerequisites). Per-tool scores range 65-72, averaging 68.
Package a markdown document as an Agent Skill: derives (or accepts) name/description, builds a validated SKILL.md, and returns a base64 .skill zip bundle namespaced as <name>/SKILL.md.
Compute word, character, line, heading, link, and image counts for a markdown document.
Extract the heading outline of a markdown document: level, text, rehype-slug-compatible anchor id, and 1-based source line. Skips headings inside code fences.
Render GitHub-flavored markdown to HTML using MarkSight's export pipeline. styled=true wraps it in a standalone printable document.
Validate Agent Skill metadata against the official spec (allowed keys, kebab-case name ≤64 chars, description ≤1024 chars without angle brackets, compatibility ≤500 chars). Pass the frontmatter as a JSON object.
No output schemas documented for any tool. Tools declare input schemas but do not document what fields, types, and structure the response contains. LLMs cannot plan downstream tool calls or extract required fields without explicit output schema guidance.
Parameter descriptions are minimal and lack constraint documentation. Descriptions like 'markdown must not be empty' and 'optional skill name' do not explain format, range, or validation rules. Per the rubric, descriptions should state 'expected format, range, and allowed values directly in the parameter description.'
No error handling or recovery guidance. Tools lack error responses that tell the LLM what to do next. For example, create_skill does not document what error is returned if markdown parsing fails, or suggest recovery steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
Tool descriptions are inconsistent in depth. document_metrics description is ~50 chars (critically short); document_outline is ~90 chars. Several tools lack context for when to use them vs alternatives.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. create_skill declares Risk=WRITE but the tool definition itself contains no annotations. Per current MCP spec (2026-07-28), tools should declare intent via tool.annotations.
No documentation of tool composition or chaining. If create_skill returns a .skill bundle structure, that structure and its fields should be documented so the LLM can understand what data is available for chaining. Currently, output format is opaque.