Skip to main content
Glama

plot_contour

Generate contour plots to visualize 3D data in 2D space, showing variable relationships across x-y coordinates for scientific analysis and publication-quality figures.

Instructions

Create a contour plot for 3D data visualization in 2D.

This tool generates contour lines (or filled contours) showing levels of a third variable (z) across x-y coordinates.

Args: x: X coordinates. Column name or list of values. y: Y coordinates. Column name or list of values. z: Z values (2D array). Column name or 2D list. data_input: Optional. {"file_path": "path/to/file.csv"} or {"data": {...}} levels: Number of contour levels (default: 10) filled: If True, create filled contours (contourf), else lines only style: Optional. {"title": "...", "xlabel": "...", "ylabel": "...", "colormap": "viridis"} output: Optional. {"format": "png/pdf/svg", "width": 15, "height": 10, "dpi": 300}

Returns: PIL Image object or bytes containing the plot

Examples: Filled contour plot: >>> x = [1, 2, 3, 4, 5] >>> y = [1, 2, 3, 4, 5] >>> z = [[i+j for j in range(5)] for i in range(5)] >>> plot_contour(x=x, y=y, z=z, levels=15, filled=True)

Line contours only:
>>> plot_contour(
...     x="longitude",
...     y="latitude",
...     z="temperature",
...     data_input={"file_path": "climate_data.csv"},
...     filled=False,
...     levels=20
... )

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYes
yYes
zYes
data_inputNo
levelsNo
filledNo
styleNo
outputNo
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by explaining the tool's behavior: it generates contour plots, can produce either lines or filled contours, returns PIL Image or bytes, and shows default behaviors (levels default to 10, filled defaults to true). It doesn't mention performance characteristics, memory usage, or error conditions, but provides substantial behavioral context 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.

Conciseness4/5

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

Well-structured with clear sections (purpose, args, returns, examples) and front-loaded core functionality. The examples are detailed but necessary for a complex visualization tool. Some redundancy exists (e.g., 'contour plot for 3D data visualization in 2D' and 'generates contour lines...'), but overall efficient for an 8-parameter tool with comprehensive documentation needs.

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

Completeness4/5

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

For a complex visualization tool with 8 parameters, 0% schema coverage, no output schema, and no annotations, the description provides substantial context: clear purpose, detailed parameter explanations, return type specification, and comprehensive examples. It doesn't cover all edge cases or error scenarios, but gives enough information for effective tool selection and invocation given the complexity.

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

Parameters5/5

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

With 0% schema description coverage and 8 parameters, the description provides excellent parameter semantics: it explains what each parameter represents (x/y coordinates, z values, data_input options, levels meaning, filled behavior, style components, output format options), includes examples showing different usage patterns, and clarifies data types (column names vs lists, 2D arrays). This fully compensates for the schema coverage gap.

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's purpose: 'Create a contour plot for 3D data visualization in 2D' with specific details about generating contour lines/filled contours showing levels of a third variable across x-y coordinates. It distinguishes this from sibling tools like plot_heatmap or plot_scatter by specifying the unique contour visualization approach.

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

Usage Guidelines3/5

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

The description implies usage context through examples showing different scenarios (filled vs line contours, direct data vs file input), but doesn't explicitly state when to choose this tool over alternatives like plot_heatmap or plot_pcolormesh for similar 2D visualizations of 3D data. No explicit guidance on when-not-to-use or comparison with siblings is provided.

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/nishide-dev/ml-research-mcp'

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