Skip to main content
Glama

Data validation module with pytest tests

submit_data_validation_module
Idempotent

Produce a standard-library Python module that validates a record and returns structured errors, plus pytest tests. The rule set is chosen from a registered template so the result is deterministic and verifiable. Choose this when a record must be checked against a registered rule set and the result is a list of human-readable errors, with tests. Do not choose this for rules outside the registered template, or when you need a schema-validation library rather than a self-contained module. Example requests: Write a Python module that validates a record against a fixed rule set and returns a list of error strings. | I need a validation function that returns an empty list for valid input, with tests. | Generate a data-validation module and its pytest suite.

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": {
      "inputs": "<inputs>",
      "authorized_by": "<authorized_by>"
    },
    "name": "submit_data_validation_module"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputsYes
quote_idNoThe quote_id returned by POST /v1/jobs. Required to authorize a priced capability; the service rejects a priced job that does not name the quote it issued.
authorized_byYesIdentifier of the human or agent authorizing this job.
accepted_priceNoThe amount accepted, exactly as quoted (for example "5.00" or 5). Checked against the stored quote, so a price that moved between quote and authorize is refused rather than silently absorbed. Optional, but sent to make the acceptance explicit.

Output Schema

NameRequiredDescriptionDefault
quoteNo
stateYes
job_idYes
artifactsNo
access_tokenNoPer-job credential. Present it as the X-Job-Token header to read the job or list it. Keep it; it is the only credential for this job.
verificationNoIndependent verification. verification.ok = false means the job failed, not a partial success.
capability_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, openWorld=false. The description reinforces this by explaining that output is deterministic and verified by the template's own tests, which is genuine added context. It says nothing about the priced-job workflow (quote_id/authorized_by acceptance) or about failure modes, even though this is a priced, authorized job.

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

Conciseness3/5

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

The first two sentences and the when/when-not clauses are front-loaded and earn their place. The three 'Example requests' are near-duplicates of the body text and add length without new information, diluting an otherwise tight definition.

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?

An output schema exists, so return shape needn't be explained, and the description covers scope, exclusions and determinism. The remaining gap is the authorization/pricing flow, which lives only in the schema and is not surfaced in the description despite being a required calling precondition.

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 75% and the schema already documents module_name, function_name, template, quote_id, authorized_by and accepted_price. The description adds only the notion that 'template' selects a registered rule set; it does not explain the naming constraints or the quote/price authorization parameters.

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 artifact: produce a standard-library Python module that validates a record, returns structured errors, plus a pytest suite. The deterministic-template framing makes the output concrete. It does not name the closest siblings (e.g. submit_json_schema_validation, submit_webhook_payload_validation) explicitly, so the differentiation is descriptive rather than direct.

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?

Contains explicit 'Choose this when...' and 'Do not choose this for...' clauses covering the main exclusion (rules outside the registered template, schema-validation libraries). No sibling tool is named as the alternative, so the agent must infer which tool to route to instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources