Skip to main content
Glama

pl_violin

Create violin plots to visualize distribution patterns of single-cell RNA sequencing variables, enabling comparison across groups with customizable aesthetics and statistical insights.

Instructions

Plot violin plot of one or more variables.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
figsizeNoFigure size. Format is (width, height).
color_mapNoColor map to use for continuous variables.
paletteNoColors to use for plotting categorical annotation groups.
vmaxNoThe value representing the upper limit of the color scale.
vminNoThe value representing the lower limit of the color scale.
vcenterNoThe value representing the center of the color scale.
legend_fontsizeNoNumeric size in pt or string describing the size.
legend_fontweightNoLegend font weight. A numeric value in range 0-1000 or a string.bold
legend_locNoLocation of legend, either 'on data', 'right margin' or a valid keyword for the loc parameter.right margin
legend_fontoutlineNoLine width of the legend font outline in pt.
groupbyNoThe key of the observation grouping to consider.
logNoPlot on logarithmic axis.
use_rawNoUse raw attribute of adata if present.
var_namesNovar_names should be a valid subset of adata.var_names.
layerNoName of the AnnData object layer that wants to be plotted.
gene_symbolsNoColumn name in .var DataFrame that stores gene symbols.
stripplotNoAdd a stripplot on top of the violin plot.
jitterNoAdd jitter to the stripplot (only when stripplot is True).
sizeNoSize of the jitter points.
orderNoOrder in which to show the categories.
scaleNoThe method used to scale the width of each violin.width
keysYesKeys for accessing variables of .var_names or fields of .obs.
multi_panelNoDisplay keys in multiple panels also when groupby is not None.
xlabelNoLabel of the x axis. Defaults to groupby if rotation is None, otherwise, no label is shown.
ylabelNoLabel of the y axis.
rotationNoRotation of xtick labels.

Implementation Reference

  • Handler function that executes the pl_violin tool by dispatching to sc.pl.violin with processed arguments, handles figure saving and logging.
    def run_pl_func(ads, func, arguments):
        """
        Execute a Scanpy plotting function with the given arguments.
        
        Parameters
        ----------
        adata : AnnData
            Annotated data matrix.
        func : str
            Name of the plotting function to execute.
        arguments : dict
            Arguments to pass to the plotting function.
            
        Returns
        -------
        The result of the plotting function.
        """
        adata = ads.adata_dic[ads.active]
        if func not in pl_func:
            raise ValueError(f"Unsupported function: {func}")
    
        run_func = pl_func[func]
        parameters = inspect.signature(run_func).parameters
        kwargs = {k: arguments.get(k) for k in parameters if k in arguments}    
    
        if "title" not in parameters:
            kwargs.pop("title", False)    
        kwargs.pop("return_fig", True)
        kwargs["show"] = False
        kwargs["save"] = ".png"
        try:
            fig = run_func(adata, **kwargs)
            fig_path = set_fig_path(func, **kwargs)
            add_op_log(adata, run_func, kwargs)
            return fig_path 
        except Exception as e:
            raise e
        return fig_path
  • Pydantic model defining the input schema and validation for the pl_violin tool.
    class ViolinModel(BaseStatPlotModel):
        """Input schema for the violin plotting tool."""
        
        keys: Union[str, List[str]] = Field(
            ...,  # Required field
            description="Keys for accessing variables of .var_names or fields of .obs."
        )
        stripplot: bool = Field(
            default=True,
            description="Add a stripplot on top of the violin plot."
        )
        jitter: Union[float, bool] = Field(
            default=True,
            description="Add jitter to the stripplot (only when stripplot is True)."
        )
        size: int = Field(
            default=1,
            description="Size of the jitter points.",
            gt=0
        )
        scale: Literal['area', 'count', 'width'] = Field(
            default='width',
            description="The method used to scale the width of each violin."
        )
        order: Optional[List[str]] = Field(
            default=None,
            description="Order in which to show the categories."
        )
        multi_panel: Optional[bool] = Field(
            default=None,
            description="Display keys in multiple panels also when groupby is not None."
        )
        xlabel: str = Field(
            default='',
            description="Label of the x axis. Defaults to groupby if rotation is None, otherwise, no label is shown."
        )    
        ylabel: Optional[Union[str, List[str]]] = Field(
            default=None,
            description="Label of the y axis."
        )
        
        rotation: Optional[float] = Field(
            default=None,
            description="Rotation of xtick labels."
        )
        
        @field_validator('size')
        def validate_size(cls, v: int) -> int:
            """Validate size is positive"""
            if v <= 0:
                raise ValueError("size must be a positive integer")
            return v
  • Definition of the pl_violin Tool object, including attachment of the input schema.
    pl_violin = types.Tool(
        name="pl_violin",
        description="Plot violin plot of one or more variables.",
        inputSchema=ViolinModel.model_json_schema(),
    )
  • Mapping of 'pl_violin' to the underlying Scanpy function sc.pl.violin in the pl_func dispatch dictionary.
    "pl_violin": sc.pl.violin,
  • Registration of the pl_violin tool in the pl_tools dictionary, used by server.list_tools().
    "pl_violin": pl_violin,
  • MCP server call_tool handler dispatches pl_violin (and other pl_tools) to run_pl_func.
    elif name in pl_tools.keys():
        res = run_pl_func(ads, name, arguments)
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions plotting but doesn't disclose behavioral traits like whether it modifies data, requires specific data formats (e.g., AnnData), outputs a plot vs. data, handles errors, or has performance considerations. The description is too minimal to inform the agent about how the tool behaves beyond basic functionality.

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 a single, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It's appropriately sized for a plotting tool, though it could benefit from more detail given the complexity.

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

Completeness2/5

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

Given the tool's complexity (26 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the data context (e.g., works with AnnData objects), output format (e.g., returns a plot image or modifies an object), or how to interpret results. The schema covers parameters, but the description fails to provide necessary operational context.

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?

Schema description coverage is 100%, so the schema fully documents all 26 parameters. The description adds no meaning beyond the schema—it doesn't explain key parameters like 'keys' (required) or how parameters interact. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with additional context.

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

Purpose3/5

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

The description 'Plot violin plot of one or more variables' clearly states the verb ('Plot') and resource ('violin plot'), but it's vague about what 'variables' refers to (e.g., genes, observations) and doesn't distinguish this tool from sibling visualization tools like pl_dotplot or pl_scatter. It specifies the plot type but lacks context about the data domain (e.g., single-cell RNA-seq).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like pl_stacked_violin or other plotting tools. It doesn't mention prerequisites (e.g., requires AnnData object), typical use cases, or exclusions. Usage is implied only by the tool name and generic description.

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/huang-sh/scmcp'

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