Skip to main content
Glama
surfer-mcp

surfer-mcp

by office31

create_contour_map

Create a contour map from a .grd grid in Surfer with color, line, or filled styles; optionally add a title and export an image or save a .srf plot.

Instructions

Create a map from a .grd grid in a new Surfer plot document.

Args: grid_file: Input .grd grid. title: Optional map title. style: "color" renders a coloured raster with contour lines, "lines" draws plain contours, "filled" fills contours (grayscale in Surfer 13). output_image: Optional export path; format inferred from extension (png, jpg, pdf, tif, svg, emf). save_plot: Optional .srf plot path.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "grid_file": "<grid_file>"
    },
    "name": "create_contour_map"
  }
}

Input Schema

NameRequiredDescriptionDefault
styleNocolor
titleNo
grid_fileYes
save_plotNo
output_imageNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose real behavior: a new plot document is created, save_plot persists a .srf, and output_image infers format from the extension with the supported list enumerated. It omits whether an active Surfer session is required, whether the new document stays open as a side effect, and what happens when both output paths are omitted.

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?

The lead sentence front-loads the action and resource, followed by a compact Args list that maps one-to-one onto the parameters. Wording is efficient, with only mild redundancy between the lead sentence and the grid_file arg line.

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

Completeness3/5

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

An output schema exists, so return values needn't be explained, and all five parameters are covered with useful detail. However, for a tool that creates a new application document with no annotations, the missing prerequisites (Surfer must be running, grid must exist) and the persistence side effect on the document list leave a real gap.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate, and it largely does: each style enum value is explained with a visual outcome ("color" = coloured raster with contour lines, "lines" = plain contours, "filled" = grayscale in Surfer 13), and output_image documents extension-based format inference. Minor gap: it does not say what is returned or exported when both output_image and save_plot are omitted.

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

Purpose4/5

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

States a specific verb and resource ("Create a map from a .grd grid in a new Surfer plot document") and pins the input format to .grd. It is clear on its own, but it never contrasts itself with siblings like create_surface_map or create_cross_section, which also consume grids, leaving the agent to infer the difference.

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?

There is no explicit when-to-use or when-not-to-use guidance and no mention of prerequisites such as an active Surfer instance or an existing grid. The only implicit routing hint is that the input must be a .grd grid.

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