Skip to main content
Glama

Python utility module with pytest tests

submit_python_utility_module
Idempotent

Produce a small standard-library Python module from a registered, deterministic template, plus the pytest tests that verify it. Choose this when you need one small, importable standard-library Python module whose behaviour matches a registered template, delivered with a passing pytest suite you can re-run yourself. Do not choose this for a multi-file package (use python-multifile-package), for code needing third-party packages, or when you cannot name a registered template: the behaviour is fixed by the template and an unregistered request is rejected rather than guessed. Example requests: Write me a small Python function that turns a title into a URL slug, with tests. | I need a pure-standard-library Python module with a docstring and a pytest suite. | Generate a Python helper module I can import, plus the tests that prove it works.

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_python_utility_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

A4.5/5.0
Behavior4/5

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

Adds real context beyond the annotations: behaviour is fixed by the template, unregistered templates are rejected rather than inferred, delivery includes a re-runnable passing pytest suite, and the pipeline is deterministic (consistent with idempotentHint=true and destructiveHint=false). It does not mention the priced-capability/quote authorization flow that the job is gated on, leaving that entirely to 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.

Conciseness4/5

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

Front-loaded with the deliverable, then the selection criteria, then the exclusions — a sensible order. The three example requests are somewhat repetitive (all restate the same slugify/helper scenario) and add length without much new routing signal.

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?

With an output schema present, the description needn't explain return values, and annotations cover the mutation/idempotency profile. Scope, exclusions, and determinism are all covered; the only material omission is the quote/pricing authorization requirement, which the agent must discover from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the baseline is 3; the description earns an extra point by explaining what 'template' actually means — a finite set of registered behaviours that fixes the output — which is more than the pattern string conveys. It still does not enumerate the three allowed templates or clarify module_name/function_name roles, though the schema does.

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?

States a specific verb and resource: produce a small standard-library Python module from a registered deterministic template, plus its pytest tests. It explicitly contrasts with python-multifile-package, so an agent can separate it from the nearest sibling without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit positive condition ('one small, importable standard-library module whose behaviour matches a registered template') and three exclusions: multi-file packages (with the alternative tool named), third-party dependencies, and requests that cannot name a registered template. The rejection-without-guessing rule removes any ambiguity about how to handle off-template asks.

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