Skip to main content
Glama

Text parsing module with pytest tests

submit_text_parser_module
Idempotent

Produce a standard-library Python module that parses a text format into a structured result, plus pytest tests including malformed input. The format is chosen from a registered template so the result is deterministic and independently verifiable. Choose this when you need a standard-library parser for a registered text format, delivered with tests that include malformed input. Do not choose this for a bespoke grammar the templates do not cover, or for formats needing a third-party parser library. Example requests: Write a Python module that parses a key=value config file into a dict, with tests for malformed input. | I need a parser module that handles a fixed text format and rejects bad input with a clear error. | Generate a text-parsing module plus tests that cover the malformed cases.

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_text_parser_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.8/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=true, so safety is covered; the description adds genuinely new context that the behaviour is fixed by a registered template and therefore deterministic and independently verifiable. It omits that this is a priced capability requiring quote authorization, though the schema carries that. No contradiction with annotations.

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 when-to-choose sentence nearly restates the opening sentence, and three illustrative example requests pad the text after the substantive guidance has already been given. Front-loading is good, but a meaningful fraction of the length is redundant.

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?

For a tool with an output schema, the description needn't explain returns, and it does cover the template determinism guarantee and the exclusion cases. The main gap is that the priced/quote-authorization workflow and the module/function naming contract are left entirely to the schema.

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 coverage is 75% and the nested object's fields are individually documented, so the baseline is already met. The description adds the concept behind the 'template' parameter but never names the available template, and its examples (key=value config into a dict) do not match the single allowed pattern 'parse-log-line', which could actively mislead an agent filling that field.

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?

Names a concrete deliverable (a standard-library Python parsing module plus pytest tests) with the distinguishing constraint that the format comes from a registered template. It does not differentiate against the many similar siblings (submit_python_utility_module, submit_env_config_parsing, submit_regex_from_examples), so an agent must infer the boundary from scope language alone.

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?

Explicitly states when to choose it (need a standard-library parser for a registered text format, delivered with malformed-input tests) and when not to (bespoke grammar not covered by templates, or formats needing a third-party parser library). It stops short of naming an alternative sibling tool, so the agent knows the boundary but not where to go 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