Skip to main content
Glama

plot_property_map

Creates an areal I–J map of a reservoir property for a selected K layer from simulation output. It plots dynamic results (PRESSURE, SWAT) from report steps or static properties (PORO, PERMX), blanking inactive cells for sweep/depletion QC.

Instructions

I–J areal map of a grid property for one K layer, rendered inline.

Dynamic (PRESSURE/SWAT/SGAS/SOIL from UNRST at a report step, default last) or static (PORO/PERMX/NTG/PORV from INIT). Inactive cells blank; axes are 1-based I/J. The no-GL alternative to a ResInsight view for sweep/depletion QC.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vmaxNo
vminNo
k_layerNo
keywordNoSWAT
case_pathYes
output_pathNo
report_stepNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses data source behavior (UNRST vs INIT), default report step behavior, inactive-cell rendering, 1-based axes, and inline output. This is substantial behavioral context beyond the schema.

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?

Three compact sentences with no redundancy. The core purpose is front-loaded, and each subsequent clause adds useful behavior or usage context.

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?

The description covers the main axes, layer selection, property families, default report step, inactive-cell handling, and rendering behavior. The main omissions are the roles of vmin/vmax and output_path, which matter for correct invocation but are not severe enough to undermine the tool's overall clarity.

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 0%, so the description must compensate. It explains keyword values (PRESSURE/SWAT/SGAS/SOIL and PORO/PERMX/NTG/PORV), the default report step behavior, and the role of k_layer. However, vmin, vmax, output_path, and case_path are not semantically explained, leaving gaps for several parameters.

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 states a specific verb and resource: 'I–J areal map of a grid property for one K layer, rendered inline.' It also distinguishes itself from ResInsight-based tools by calling itself 'the no-GL alternative to a ResInsight view,' so an agent can tell it apart from sibling plotting/visualization tools.

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

Usage Guidelines4/5

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

The description gives clear when-to-use context: dynamic properties from UNRST at a report step versus static properties from INIT, and identifies the QC use case for sweep/depletion. It points to ResInsight as an alternative but does not explicitly enumerate sibling tools or conditions for avoiding this tool.

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