Loading ToolBench
A Model Context Protocol (MCP) server for the HoloViz ecosystem providing tools, resources and prompts for working with Panel, hvPlot, HoloViews and other HoloViz libraries
HoloViz MCP presents a domain-specific knowledge interface (skills, reference guides, visualization libraries) with 15 tools covering discovery, retrieval, and parameter inspection across Panel, HoloViews, and hvPlot. Tool naming is verb-noun action-based (skill_get, skill_list, ref_get, hvplot_list, pn_get, pn_search) which is strong. Descriptions are present and contextual for most tools (150-250 chars typical), guiding LLM selection. However, critical gaps emerge: (1) Parameters lack detailed type constraints (enums, min/max, format rules); (2) No explicit output schemas documented, responses are inferred from docstrings; (3) Error handling is absent, no recovery guidance or categorization; (4) Some parameter descriptions are sparse (e.g., 'path' in skill_file_get only says 'Relative path within the skill directory'); (5) Mutually exclusive parameter relationships undocumented (e.g., pn_get accepts name OR module_path OR package, but descriptions don't state exclusivity). Tools are READ_ONLY (safe), but composition is weak, no guidance on which discovery tool to call first when intent is ambiguous. Schema validation appears to rely on fastmcp defaults rather than explicit constraint declarations. Overall, the server solves a real problem (surfacing HoloViz docs to LLMs) but falls short of production-grade tool patterns for robustness and error recovery.
Get the HoloViews docstring for a specific element, including available options and usage details. Use this tool to retrieve the full docstring for an element, including generic and style options.
Get the hvPlot docstring or signature for a specific plot type. Returns only the plot-specific parameters by default (compact output). Set generic=True and/or style=True for the full docstring including all shared options. Equivalent to `hvplot.help(plot_type)` in the hvPlot API. Pass signature=True to get the function signature instead of the docstring.
List all available hvPlot plot types (~28 types) supported in the current environment. Use this tool to discover what plot types you can generate with hvPlot. Note: The plot types are also called "kinds".
List all available HoloViews visualization elements (~60 elements). Use this tool to discover what visualizations you can generate with HoloViews.
Get complete details about a single Panel component including docstring and parameters. Use this tool when you need full information about a specific Panel component, including its docstring, parameter specifications, and initialization signature. Tip: If you only need parameter details and already know the component exists, use params instead for a lighter response without the docstring. IMPORTANT: This tool returns exactly one component. If your criteria match multiple components, you'll get an error asking you to be more specific.
Output schemas not documented in tool definitions. Tool descriptions explain what is returned (e.g., 'Returns the HoloViews docstring...'), but formal response schemas are missing. LLMs cannot predict downstream data structure, forcing trial-and-error field access.
Parameter type constraints missing or underspecified. Examples: (1) pn_list 'name' parameter has no min/max length or regex, LLM may pass 10000+ char strings; (2) hvplot_get 'style' parameter accepts string|boolean but no enum of valid backend names ('matplotlib', 'bokeh', 'plotly'), LLM may invent backends; (3) limit parameters lack bounds (e.g., pn_search limit=10 default, but no max stated, LLM might request limit=999999).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-11 | B | 72 | - | v1 |
Get a summary list of Panel components without detailed docstring and parameter information. Use this tool to get an overview of available Panel components when you want to browse or discover components without needing full parameter details. This is faster than get_component and provides just the essential information.
List all installed packages that provide Panel UI components. Use this tool to discover what Panel-related packages are available in your environment. The returned package names can be used in the 'package' parameter of: list, search, get, and params.
Get detailed parameter information for a single Panel component (without the docstring). Use this tool when you only need parameter details (types, defaults, constraints) and already know the component exists. This is lighter than get which also includes the full docstring. IMPORTANT: This tool returns parameters for exactly one component. If your criteria match multiple components, you'll get an error asking you to be more specific.
Search for Panel components by search query and optional package filter. Use this tool to find components when you don't know the exact name but have keywords. The search looks through component names, module paths, and documentation to find matches.
List all HoloViz and user-defined projects with indexed documentation (~20 projects). This includes both built-in HoloViz projects (panel, hvplot, etc.) and any custom/internal documentation projects you have configured.
Find reference guides for specific components in HoloViz or user-defined projects. Use this when you know the exact component name and want its reference guide directly. For fuzzy or semantic search, use the search tool instead.
Read a supporting file from a skill directory. Use skill_files tool first to discover available files, then use this tool to read them.
List supporting files in a skill directory (excludes SKILL.md). Use this to discover additional resources (examples, references, templates) bundled with a skill beyond its main SKILL.md content.
Get the specified skill for usage with LLMs. Use list_skills tool to see available skills.
List all available skills with descriptions (~8 skills). Use skill_get to retrieve the full content of a specific skill.
Mutually exclusive parameter relationships undocumented. Tools pn_get and pn_params accept 'name' OR 'module_path' OR 'package', but descriptions do not state: (a) that only one should be provided; (b) what happens if multiple are provided; (c) which is the preferred lookup path. LLMs may pass all three, causing ambiguity or tool errors.
No error handling guidance or recovery hints. All tools are READ_ONLY (safe), but when a lookup fails (e.g., 'component 'BadName' not found'), there is no indication of what the LLM should do next: retry with a search tool, ask the user, or give up. Error responses likely contain raw exceptions rather than actionable recovery steps.
Tool names for generic operations are ambiguous. 'list' and 'get' (in holoviews_mcp) lack context, are these for Elements? Annotations? LLM must read description; names alone do not convey scope. Better: 'holoviews_element_list', 'holoviews_element_get'.
Pagination not implemented. Tools like skill_list and project_list are capped by design (~8 and ~20 items), but no offset/limit parameters are exposed. If HoloViz ecosystem grows, LLM cannot paginate results. For discovery tools, consider exposing limit and offset as optional parameters.
Parameter descriptions are sometimes vague or minimal. Examples: (1) skill_file_get 'path' description is only 'Relative path within the skill directory (e.g., \"references/example.md\")', no mention of what extensions are expected or if directories are supported; (2) ref_get 'content' parameter description lacks detail on what 'full content' includes (docstring + examples + source code?).
No guidance on tool composition or discovery order. When an LLM wants to 'find a Panel component by keyword', should it call pn_search directly or pn_list first? When it wants 'details about a HoloViews plot', should it start with list then get, or jump straight to ref_get? Descriptions hint at workflows (e.g., 'Use skill_files first, then skill_file_get'), but composition is not systematic.