Skip to main content
Glama
Sign In
Kanysh Basic

Kanysh Basic

by almukhanomr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

seismic_generate

Generate reproducible synthetic seismic cubes for a project using configurable shape, sample interval, constant velocity, and random seed to support subsurface modeling and testing.

Instructions

seismic_generate

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": {
      "request": "<request>"
    },
    "name": "seismic_generate"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYesTool arguments object (all fields documented; Z is positive upward).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

D1.4/5.0
Behavior1/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=false and no idempotency, so the agent knows only the safety class. The description adds nothing about what is produced (a new job? a dataset?), whether generation is asynchronous, what the idempotency_key actually does, or where output lands.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

Zero sentences, no front-loading, no structure — the single token is under-specification rather than conciseness. Nothing is wasted because nothing is said.

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

Completeness1/5

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

This is a nested-object tool with an execution policy, device/GPU semantics, and idempotency behavior, and it has no output schema. A one-word description leaves the agent unable to judge whether the call creates a job, runs synchronously, or returns a dataset reference.

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% — every nested field (seed, shape, dt_seconds, velocity_m_s, execution policy, idempotency_key) is documented in the schema itself. With one top-level parameter the baseline of 3 applies; the description contributes no parameter meaning of its own.

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

Purpose1/5

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

Tautological: description restates name/title.

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

Usage Guidelines1/5

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

There is no guidance on when to use this versus seismic_import, seismic_slice, seismic_attribute, or the simulation tools. No prerequisites (e.g. an existing project_id from project_create/project_list) are mentioned.

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

Deploy Server

Other Tools