Skip to main content
Glama

validate_deck

Parse an ECLIPSE/Flow DATA deck to report keyword counts and identify parser issues, ensuring input validity before running simulations.

Instructions

Parse an ECLIPSE/Flow DATA deck and report keyword counts + parser issues.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deck_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.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 of behavioral disclosure. It does state the action and output, but it does not explicitly confirm the operation is read-only, explain how parser issues are surfaced, or describe behavior on invalid or missing deck paths.

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, front-loaded sentence with no filler. It efficiently conveys the action, the target resource, and the expected result.

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?

For a one-parameter tool with an output schema, the description covers the essential purpose and usage. It is not fully complete because it lacks guidance on choosing between this and similar tools, and it does not confirm side-effect-free behavior, but a capable agent could likely invoke it correctly.

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 single parameter, deck_path, is self-explanatory by name, and the description adds that it refers to an ECLIPSE/Flow DATA deck. However, with 0% schema description coverage, there is no further detail about path format, required extensions, or expected input types.

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?

The description uses a specific verb ('Parse') and identifies the resource ('ECLIPSE/Flow DATA deck') and output ('keyword counts + parser issues'). It clearly communicates what the tool does, though it does not explicitly contrast it with similar siblings like summarize_deck.

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 gives no guidance about when to use validate_deck instead of alternatives such as summarize_deck, deck_grep, or deck_text. There are no exclusions, prerequisites, or explicit context cues to help an agent pick this tool over its siblings.

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