The madt_* tools reject the first natural call too often; the first reach should succeed #747

Open
opened 2026-10-09 20:56:17 +00:00 by hexajon · 0 comments
Owner

The madt_* tools reject the obvious first invocation far too often, so a task that should be one call becomes three or four. The schema and the help text are meant to steer the first reach so it lands; when they do not, the tool should accept the obvious synonym or do the obvious thing rather than emit a correction and make the caller try again.

Cases I keep hitting:

  • Listing a branch's action runs: action=runs accepts neither branch nor ref (ref is reported as "consumed by dispatch"), so there is no way to filter runs to one branch on the first try.
  • Closing a pull request with a note takes four calls: an update + state=closed + comment attempt is rejected for the arg name, update turns out not to be an accepted action at all, close refuses a comment field, comment then needs body, and finally close. "Close with a comment" should be a single call.
  • finish rejects message= (it wants title/summary); and finish files=... branch=<other-repo> refuses with "use commit then finish", two calls for what reads as one.
  • Argument names drift across sibling tools: branch vs ref vs name, comment vs content, message vs summary. The same concept should take the same name everywhere, and the obvious synonym should be accepted.

The principle: the first command a caller reaches for should succeed, because the schema and help already pointed them at the right shape. Where it cannot, accept the synonym and do the obvious thing instead of returning a help error.

Ask: audit the tool surface for first-call success - unify argument names across tools, accept common synonyms, let the list actions take the obvious filters (a branch/ref on runs), and collapse the frequent multi-call sequences (close-with-comment, commit-then-finish) into one.

The `madt_*` tools reject the obvious first invocation far too often, so a task that should be one call becomes three or four. The schema and the help text are meant to steer the first reach so it lands; when they do not, the tool should accept the obvious synonym or do the obvious thing rather than emit a correction and make the caller try again. Cases I keep hitting: - Listing a branch's action runs: `action=runs` accepts neither `branch` nor `ref` (ref is reported as "consumed by dispatch"), so there is no way to filter runs to one branch on the first try. - Closing a pull request with a note takes four calls: an `update` + `state=closed` + `comment` attempt is rejected for the arg name, `update` turns out not to be an accepted action at all, `close` refuses a comment field, `comment` then needs `body`, and finally `close`. "Close with a comment" should be a single call. - `finish` rejects `message=` (it wants `title`/`summary`); and `finish files=... branch=<other-repo>` refuses with "use commit then finish", two calls for what reads as one. - Argument names drift across sibling tools: `branch` vs `ref` vs `name`, `comment` vs `content`, `message` vs `summary`. The same concept should take the same name everywhere, and the obvious synonym should be accepted. The principle: the first command a caller reaches for should succeed, because the schema and help already pointed them at the right shape. Where it cannot, accept the synonym and do the obvious thing instead of returning a help error. Ask: audit the tool surface for first-call success - unify argument names across tools, accept common synonyms, let the list actions take the obvious filters (a branch/ref on `runs`), and collapse the frequent multi-call sequences (close-with-comment, commit-then-finish) into one.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
sixfold-space/madtea#747
No description provided.