mcp: the harness field is a hard award filter, not a recorded preference - #206
Open
orveth wants to merge 1 commit into
Open
mcp: the harness field is a hard award filter, not a recorded preference#206orveth wants to merge 1 commit into
orveth wants to merge 1 commit into
Conversation
The schema description still said harness was "not yet a hard filter (no claim wire field carries it)" after the multi-harness slice made it exactly that. This is the one string an LLM buyer reads to decide whether the field does anything, so it was telling the reader who acts on it the opposite of the truth — a buyer would reasonably drop the field as decorative. The sibling model field's identical caveat is left alone: it is still true. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One string, one file, no code paths touched — but it currently tells the reader who acts on it the opposite of the truth.
The defect
post_job'sharnessfield still advertises itself as inert:That was accurate before #201. It isn't now:
harnessis posted on the offer as["param","agent",<name>], a seller that cannot run the requested harness never claims, and the buyer's award filter refuses a claim that doesn't advertise it.Why it isn't cosmetic
This is a tool schema description — the one string an LLM buyer reads to decide whether passing the field accomplishes anything. A buyer that reads "not yet a hard filter" and drops the field as decorative is behaving correctly on the documentation it was given, and silently loses harness selection. The wiring is live and toothed underneath; only the sign-post is wrong, which is the failure mode that doesn't show up in any test.
Mine, from #201: I updated the Rust doc comment on
PostJobParamsand missed the user-facing schema text.Scope
crates/mobee/src/mcp.rs, theharnessdescription only.modelfield carries the identical "not yet a hard filter" caveat and is left alone — it is still true. No wire field carriesmodel.Evidence
No behaviour change; nothing to revert-test, because there is no assertion here to bite. The claim the text now makes is the one already toothed in #201 (
a_job_requesting_a_harness_is_never_awarded_to_a_claim_without_it, and the claim-gate tooth).