Skip to main content
Glama

Check finished work with Sternly

submit_claim_bundle

Hand finished work to Sternly for an independent check after the fact. Send the final text exactly as the person received it, what the person asked for in their own words, and the files, sources and programs you already used, with what each program printed. Send the work as it is: do not rewrite, shorten or add to it for Sternly, and do not mark which part came from where; Sternly reads the work itself. When the work is someone else's (the other side's brief, a filing before the court), say so in policy.mode, and name a producer only if you know who made it. Returns a check id and a link to give the person; get_check returns the result. With wait set to false, Sternly answers at once with the status running, and the check goes on.

Input Schema

NameRequiredDescriptionDefault
textYes
waitNoWhen the answer comes. false: at once, with the check id and the status running, while the check goes on; get_check then returns the status and, once the check is done, its result. true: when the check is done.
filesNo
notesNo
layoutNo
policyNoThe only part of a bundle that chooses what runs: closed enums and bounded numbers. `mode` is one of the enums and chooses nothing that runs: it names whose work this is, for the result's words (`capture/modes.py`).
captureNoHow the work reached Sternly, and what the channel could not see (recorded in the package; it lowers grades).
requestNo
sourcesNo
producerNoWho made the work. `vendor` decides independence: the judges are never from the producer's vendor. It is the maker of the producer's model (the lab), never where it was served.
programsNo
tool_logNo
bundle_versionNo
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, it discloses the return contract (a check id and a link to give the person), the async behavior with wait=false, and the integrity rules ('do not rewrite, shorten or add to it', 'do not mark which part came from where'). That is meaningful behavior an agent cannot read off readOnlyHint/destructiveHint. It does not mention idempotency_key, which matters given idempotentHint=false.

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 core action, then integrity rules, then mode/producer, then return and wait semantics — a sensible ordering. A few clauses are dense ('do not mark which part came from where; Sternly reads the work itself'), but nothing is filler.

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 14-parameter tool with no output schema and 29% coverage, the description covers the required path and the return value but leaves several nested structures (layout, capture, tool_log, notes) unaddressed. An agent can make a valid minimal call, but the richer bundle fields require reading 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?

With only 29% schema coverage across 14 parameters, the description carries real weight: it maps text, request ('what the person asked for in their own words'), files, sources, programs with printed output, policy.mode and producer to their purpose. It also constrains producer ('name a producer only if you know who made it'). notes, layout, capture, tool_log and idempotency_key remain unexplained.

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?

The description states a specific verb and resource: hand finished work to Sternly for an independent check. It also distinguishes itself from the sibling by saying 'get_check returns the result', so an agent knows this is the submission step, not the retrieval step.

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?

'after the fact' and 'finished work' bound when to call it, and get_check is named as the follow-up. It also tells the agent when to set wait=false. It stops short of explicit exclusions (e.g. not for work in progress), so it is clear context rather than full when/when-not guidance.

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