Rewrite a browser tool's description so a coding agent that reads only that text uses two new filters correctly

Goal and context

Pumasi registers a small set of read-only tools on the page for a coding agent running in the user's browser (WebMCP). The agent never sees our documentation; it sees the tool's name, its input schema, and its description string. The description is therefore the whole contract from the agent's point of view: what the tool is for, what to do with the result, and where to stop and let the human decide. The tool is `find_offers`. Today its description is a single paragraph (quoted below in the reference context). It works, but it was written when the tool took one free-text input. The tool is gaining two optional filters and the response is gaining structured fields, and the description has to teach an agent to use them without trial and error. New inputs: `category`, one of `engineering`, `product`, `design`, `writing`, `research`, `marketing`, `career`, `business`; and `workType`, one of `review` (critique of something the user made), `create` (a new artefact from the user's input), `analyze` (a reasoned answer or comparison), `transform` (the same content in a different form, language, or structure), `plan` (the structure and order of what to do next). All inputs are optional and combined with AND; `query` remains a free-text substring match. New response fields per Offer: `category`, `categoryLabel`, `workType`, `workTypeLabel`, `whoItsFor` (one line describing the situation the Offer fits), `notFor` (a situation it does not fit, or null). Rules the rewritten description must keep, in substance if not in wording: the result lists active Offers only; each Offer returns owner, required text inputs, one-answer Result contract, Agent capability ceiling, expected time, fixed 500 Credits, and a browser URL; the agent must open that URL in the Pumasi browser and let the user review the exact inputs, data notice, Result, and Credits before submitting; the agent must not enter credentials, secrets, or material the user cannot share; Request creation and the live Agent run are browser-only; after completion the agent uses `get_request_result` to bring the same terminal Result back to the task. What we want the new description to add: when to use a filter versus free text (a filter narrows by kind of help; free text finds a topic); that the agent should prefer `workType` first because choosing `review` when the user wants something written is the most common wrong pick; that `whoItsFor` and `notFor` are for the agent to check against the user's situation before recommending; and that if nothing matches, the agent should say so and point to the Open Request path rather than picking the nearest Offer. Hard limits: one description string, at most 1,200 characters, plain text (no Markdown), no line breaks longer than a sentence. It will be read by many different models, so avoid idioms and avoid phrasing that presumes the agent can see the page.

Result you want

A Markdown document with these sections. 1. **The description.** The full rewritten string, in a code block, under 1,200 characters. Count it. 2. **Why it changed.** At most three lines: the three most important things the new text does that the old one did not. 3. **What was kept and why.** The sentences or ideas carried over from the old description, and the rule each one protects. 4. **Ordering rationale.** One paragraph on why the sentences are in the order they are, given that models weigh early sentences more. 5. **A negative test.** One realistic user request where a naive agent would pick the wrong `workType`, and the sentence in your description that prevents it. Do not change the tool's name or input schema. Do not write descriptions for the other tools.

Details

Response

One answer

Credits

500

The Request is public. Only the Member who asked and the Member who answers see the Result.