Skip to main content
Glama

pn_get

Retrieve complete documentation and parameter details for a specific Panel component. Use when you need full information including docstring and initialization signature.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoComponent name to match (case-insensitive). If None, must specify other criteria. Examples: "Button", "TextInput", "Slider"
module_pathNoFull module path to match. If None, uses name and package to find component. Examples: "panel.widgets.Button", "panel_material_ui.Button"
packageNoPackage name to filter by. If None, searches all packages. Examples: "panel" or "panel_material_ui"

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
module_pathYesFull module path of the component, e.g., 'panel.widgets.Button' or 'panel_material_ui.Button'.
nameYesName of the component, e.g., 'Button' or 'TextInput'.
packageYesPackage name of the component, e.g., 'panel' or 'panel_material_ui'.
descriptionYesShort description of the component's purpose and functionality.
init_signatureYesSignature of the component's __init__ method.
docstringYesDocstring of the component, providing detailed information about its usage.
parametersYesDictionary of parameters for the component, where keys are parameter names and values are ParameterInfo objects.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals key behavioral traits: it returns exactly one component and errors if multiple matches, which is critical for an agent. However, it does not mention side effects, authorization, or read-only nature—though read-only is implied. With no annotations, the description carries the full burden and provides reasonable transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: it opens with a clear purpose statement, then adds usage guidelines, a tip, and an important note—all in a compact, front-loaded format. Every sentence adds value, and the formatting aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, no nested objects, output schema present), the description covers all essential aspects: purpose, usage, return behavior, and error conditions. The presence of an output schema relieves the need to document return fields, making the description complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides detailed descriptions for all 3 parameters (including examples), achieving 100% coverage. The description adds only a tip about using pn_params for lighter output, which does not enhance parameter meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves complete details of a single Panel component, including docstring and parameters. It is distinguished from siblings like pn_params (parametric details only) and pn_list (listing components). The verb 'Get' and resource 'Panel component' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to use this tool (full details needed) and when to use the lighter alternative pn_params. It also warns about the error condition when multiple components match, providing clear usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarcSkovMadsen/holoviz-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server