TweakThis

Submit resolution

submit_resolution

Idempotent

After you have changed the code, submits your fix for the item's current revision and moves it to ready_for_review for the developer to accept or reopen (your claim is released). Pass your claim_token (not needed if you did not claim and nobody else holds the item) and the revision and version from claim_feedback. Say what you changed (files, behaviour) and how you checked it, then always end with a "Context used" section in this format:

Context used:

Used: <captured fields you relied on, from: note, screenshot, element crop, selectors, attributes, outerHTML, computed styles, page URL/title>
Missing or rediscovered: <what the capture lacked or you had to find in the repository, or "none">
Asked the developer: <no, or yes and what>

Optionally add links (commit, pull request, preview) and test evidence; links are stored, never fetched. conflict_stale: the developer changed the item, read it again; conflict_state: it was accepted or dismissed.

Input Schema

Name	Required	Description
`links`	No	Commit, pull request or preview links: { kind, url, label }.
`summary`	Yes	What you changed and how you verified it, ending with the "Context used" section (at most 8000 characters).
`evidence`	No	Checks you ran: { kind: "test_run", command, result, output_excerpt } or { kind: "output", description, text }.
`claim_token`	No	The claim_token returned by claim_feedback.
`feedback_id`	Yes	Feedback item id from list_feedback.
`idempotency_key`	No	A key of your choosing (a UUID is ideal, 8-128 of A-Z a-z 0-9 _ . : -). Retrying with the same key and arguments replays the first outcome instead of repeating it.
`expected_version`	No	The latest version you saw (from claim_feedback or add_comment). Omitted: the current version.
`expected_revision`	No	The revision your fix addresses (from claim_feedback or get_feedback). Omitted: the current revision.

Output Schema

Name	Required	Description
`error`	No	Present only when isError is true: a stable error code (not_found, invalid, conflict_stale, conflict_claimed, conflict_state, quota_exhausted, rate_limited, internal_error) with details such as current_revision/current_version.
`status`	No
`version`	No
`replayed`	No
`resolution_id`	No
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the state machine outcome (ready_for_review, developer may accept or reopen), that the claim is released, that links are stored but never fetched, and the two failure modes (conflict_stale, conflict_state). The idempotentHint is reinforced by the schema's idempotency_key documentation.

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-loads the action and state transition in the first sentence, then details parameters and error codes. The embedded "Context used" template is verbose but genuinely required for correct invocation, so the length is mostly earned; a little tightening is possible.

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

Completeness5/5

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

Covers preconditions, required payload shape, optional evidence/links, idempotency implications, and both conflict outcomes. Since an output schema exists, return values need not be described, leaving no significant gap for an 8-parameter workflow tool.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds real meaning: the conditional requirement for claim_token, the source of revision and version (from claim_feedback), and a concrete template for the required "Context used" section of summary. It also explains the optional evidence and link fields' intent.

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?

Names a specific verb (submits your fix) plus the resource and the resulting state transition (moves it to ready_for_review, claim released). This is clearly distinguishable from siblings such as add_comment, release_feedback, and claim_feedback.

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?

Gives a clear precondition ("After you have changed the code") and clarifies when claim_token is and is not needed. It does not name alternative tools or say when NOT to submit, so it falls short of the explicit when/when-not/alternatives bar of a 5.

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

All TweakThis tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?