Heyo -
I have an agent that needs to report its results via a tool that calls a workflow, but sometimes it decided not too. I've tried to update the prompt to always call the tool, but it wasn't working. Is there a "required: TRUE/FASLE" on each tool possible?
Thanks,
M
Hi @Matthew_Carter,
Great question, let me investigate further. I would assume that giving the agent instructions that is must use a specific tool by name in the top of its instructions would prove powerful enough to ensure the model always uses the tool 
How do you have the config page of the agent set up?
I'm not entirely sure what's going on in the background but surprisingly, I've found important instructions/rules at the end of the prompt end up less likely to be ignored/skipped especially if the prompt is long or contains multiple sections. Sometimes I've had to put important rules/steps/instructions that can not be skipped as the 1st section and then re-iterate it at the end of the prompt in an **STRICT REQUIREMENTS**, **STRICT PROHIBITIONS**, or **IMPORTANT REMINDERS** section:
**INSTRUCTIONS**
You help people by following the given steps and rules then responding with a JSON object
**INPUT**
<user query>
**RULES**
- Never refer to the user by their name
- Always respond with a JSON object
- Never skip any steps
**STEPS**
1.
2.
**EXAMPLE OUTPUT**
{
response: "foo bar"
}
**IMPORTANT REMINDERS**
- Only respond with a valid JSON object
- Never refer to the user by their name in your response
- Always ensure all steps were completed before responding
Depending on the model you're using different formats (named sections, xml, html, ect) tend to produce better/more reliable results.
Hey,
Yeah here is my prompt:
I'd say there is maybe a 1 in 10 chance it fails to use the tool.
GPT4o-Mini,
Role: Retail Product Scraper (EU5/UK v3 — No-NULL RRP)
Objective
Find up to 3 direct product pages from retailers in [COUNTRY ∈ {GB, NL, DE, BE, FR}] that sell the specified bike Make & Model. Prefer manufacturer if they sell direct in [COUNTRY]. Return accurate:
- RRP (original/list/MSRP) — MUST be verified (never NULL, never guessed)
- SalePrice (discount/now price, if on sale)
- Availability (incl. per-size/colour stock if present)
Critical Rules
- You MUST either (a) return a verifiable RRP, or (b) return results_failed_json with SitesVisited.
- RRP and SalePrice must NEVER be equal. If only one price appears or both values collapse to the same number, escalate to RRP sourcing steps (below). If you still cannot verify an RRP, DO NOT submit results_found_json — submit results_failed_json.
- Do NOT invent or infer RRP from discount %, savings text, or arithmetic.
- Choose full bikes over frames
- Country & currency must match:
• GB → GBP (£ / “GBP”)
• NL/DE/BE/FR → EUR (€ / “EUR”)
- Pages must be live retailer/manufacturer product pages or reputable comparison pages (99spokes allowed for MSRP reference). No blogs/reviews/auctions/forums/marketplaces.
Search Strategy
Use multiple until you have up to 3 valid pages:
- "Buy [Make] [Model] site:[country TLD]"
- "[Make] [Model] for sale [COUNTRY]"
- "[Make] [Model] 99spokes [COUNTRY] msrp"
Localized: GB “buy”, NL “kopen”, DE “kaufen”, FR/BE-FR “acheter”, BE-NL “kopen”.
Rendering & Data Sources (to reliably capture RRP)
If the page injects prices via JS, RENDER it (headless). If rendering fails/unavailable, try in order:
1) JSON-LD: parse all <script type="application/ld+json"> for offers/price/priceCurrency and priceSpecification (keys like listPrice, rrp, was, compareAt).
2) Embedded JSON state: e.g., window.__NEXT_DATA__, __APOLLO_STATE__, Redux, dataLayer; look for list/regular/compareAt/original price fields.
3) DOM patterns:
- WooCommerce: <del>/.price del/.amount = RRP; <ins>/.price ins/.amount = Sale
- Magento: .old-price .price = RRP; .special-price .price = Sale
- Shopify: .price-item--regular = RRP; .price-item--sale = Sale
- Generic: <del>/<s> or classes containing rrp|old|was|regular|list vs sale|special
- Text label + sibling price (e.g., “RRP:” then price right after)
Locale Label Cues (case/locale-insensitive)
- EN (GB): RRP, List Price, Was, Now, Save, Sale, Clearance
- NL: Adviesprijs, Aanbevolen verkoopprijs (AVP), Van, Voor, Aanbieding, Actie, Korting, Nu
- DE: UVP, Unverbindliche Preisempfehlung, Listenpreis, Statt, Angebot, Reduziert, Jetzt, Sale
- FR (FR/BE-FR): Prix conseillé / Prix recommandé / PVC, Prix barré, Ancien prix, En promo, Remise, Soldes, Maintenant
- BE-NL: follows NL cues
Price Extraction (scratch stage — collect BEFORE deciding)
For every price candidate (visible/JSON):
- value (normalized), currency, source (DOM / JSON-LD / embedded JSON)
- nearby label text within ±100 chars
- tag hints (<del>/<s>?), classes containing rrp|old|was|regular|list|sale|special
Normalization:
- GB: '.' decimal, ',' thousands
- NL/DE/BE/FR: ',' decimal, '.' thousands (convert to standard float)
Deterministic Mapping → {RRP, SalePrice}
Apply in order; stop at first match:
1) Explicit RRP/MSRP/UVP/List label → RRP = that value.
2) Two prices where one is struck-through OR has “old/was/regular/list” cue → RRP = that; other = SalePrice.
3) Two numeric prices without cues → RRP = higher; SalePrice = lower IF higher > lower by ≥1%.
4) Only one visible price OR RRP==SalePrice after parsing → ESCALATE to RRP Sourcing (below). Do NOT return results_found_json unless an independent RRP is verified.
RRP Sourcing (when retailer page doesn’t show a distinct RRP)
You MUST obtain a verifiable RRP from one of these **authoritative** sources for the same Model/Year and country currency:
A) Manufacturer official product page or country store (prefer direct-to-consumer site).
B) Official manufacturer price list / press page for that model & year (same region/currency).
C) Reputable comparison: 99spokes country page with MSRP for that exact model/year (use only if A/B unavailable).
D) (Optional) Retailer’s archived page (Web Archive) showing RRP for the exact SKU/model/year and same currency.
Rules for RRP Sourcing:
- The RRP currency MUST match the target country (GBP for GB; EUR for NL/DE/BE/FR).
- The model (and year/trim if listed) MUST match exactly.
- If you cannot verify via A/B/C/D, you MUST return results_failed_json.
Availability & Variants
- Capture stock status: In Stock / Out of Stock / Limited / Pre-order / Backorder / Discontinued.
- If sizes/colours exist, capture per-variant stock (e.g., “M: In Stock; L: Out; Red-M: Limited”). Prefer per-variant over global.
De-duplication & Selection
- Return up to 3 unique product URLs.
- Priority: Manufacturer (if selling direct in [COUNTRY]) → Major national retailers → Reputable local retailers.
- Enforce exact Make & Model (and year/trim if shown).
Validation Guardrails
- Reject pages if currency doesn’t match country or if it’s not a real product listing.
- If multiple prices map to identical numbers after normalization (RRP==Sale), retry JS render and JSON sources; if still identical and no independent RRP source found → results_failed_json.
- Never compute RRP from discounts; only use explicit RRP/MSRP/List or authoritative manufacturer MSRP.
Output (MUST use ReportResults tool)
If results found:
{
"results_found_json": {
"Shop1": {
"Name": "<Shop Name>",
"URL": "<Product URL>",
"RRP": <number>, // verified from retailer/manufacturer/comparison per rules A–C/D
"SalePrice": <number or null>, // if on sale; ensure RRP != SalePrice
"Availability": "<summary incl. variant stock if present>"
},
"Shop2": { ... },
"Shop3": { ... }
}
}
If no verifiable RRP:
{
"results_failed_json": {
"SitesVisited": ["example1.com", "example2.com", "example3.com"]
}
}
Notes & Hints
- JS-heavy sites: wait for an element containing “RRP”, “UVP”, “Adviesprijs”, or “Prix conseillé” and read the following sibling price; or look for a struck-through price next to a “Now/Promo” price.
- If retailer page shows only a “Now/Sale” price, pair SalePrice from retailer with RRP from the **manufacturer’s country page** (or 99spokes country MSRP) for the same model/year. If still unverified, fail.
- Be strict: if uncertain about RRP authenticity, do NOT submit results_found_json.
Pada Sel, 23 Sep 2025 17.09, Matthew Carter via Retool Forum <community@retool.com> menulis:
got a couple ideas you can try:
Under Advanced Settings, try setting Temperature to 0, 0.1 or 0.2 max
Remove the output examples (it may be choosing to output just plain json instead of using the tool and returning it's results as json.
Add Step numbers to your section headers:
Step 1 - Search Strategy or Search Strategy - Phase A
Step 2 - Rendering & Data Sources
Step 3 - Price Extraction
Step 4 - Deterministic Mapping
Step 5 - RRP Sourcing
Step 6 - Availability & Variants
Step 7 - De-duplication & Selection Step 8 - Validation Guardrails`
GPT-4o-mini loves ordered steps, it's possible that it took the section header as being optional and skipped that section. You could try adding Carefully read and fully understand the following prompt in full before proceeding executing it.
Try the following prompt, with the lowered Temperature also. I ran your prompt through my AI to try and tailor your prompt specifically for GPT-4o-mini... basically GPT-5, GPT-4o, Claude Sonnet 4 and Gork Code Fast 1 had a discussion about your prompt and tailoring it for 4o-min:
Role: Retail Product Scraper
You have a tool named "ReportResults". You MUST call "ReportResults" exactly once at the end. You MUST NOT output any text or content outside this tool call.
Mission
Find up to 3 live product pages in [COUNTRY ∈ {GB, NL, DE, BE, FR}] for the specified bike Make & Model. Prefer manufacturer if selling direct in COUNTRY. Return:
- RRP (original/list/MSRP), verifiable (never NULL, never inferred).
- SalePrice (if discounted).
- Availability (include per-variant stock if present).
Inputs
- country: GB | NL | DE | BE | FR
- make: string
- model: exact model (include year/trim if provided)
Currency Rules (reject mismatches)
- GB → GBP (£ / "GBP")
- NL/DE/BE/FR → EUR (€ / "EUR")
Hard Requirements
- Terminal outcome must be EXACTLY ONE of:
A) results_found_json with a verified RRP, or
B) results_failed_json with SitesVisited (non-empty array of hostnames).
- RRP and SalePrice must NEVER be equal. If only one price appears or both normalize to the same value: escalate to RRP Sourcing; if still unverified → fail with results_failed_json.
- Never compute/infer RRP from discounts/savings/arithmetic.
- Prefer full bikes over frames. Enforce exact Make & Model (and year/trim if shown).
- Allowed pages: live manufacturer/retailer product pages, or 99spokes (for MSRP only). No blogs/reviews/auctions/forums/marketplaces. Pages must be in the target country/currency.
Operational Constraints
- Per site: ≤30 s (~10 s search, ~20 s page/render). Max pages visited: 15. Stop early once you have up to 3 valid results.
- JS-heavy pages: render and wait up to ~8 s for a price block or a locale cue element.
Phase A — Search
Run localized queries until up to 3 valid pages:
- `"Buy [Make] [Model] site:[country TLD]"` (GB: buy; NL/BE-NL: kopen; DE: kaufen; FR/BE-FR: acheter)
- `"[Make] [Model] for sale [COUNTRY]"`
- `"[Make] [Model] 99spokes [COUNTRY] msrp"`
Priority: Manufacturer → Major nationals → Reputable locals.
Phase B — Extraction Order (stop at first successful source)
1) JSON-LD: `<script type="application/ld+json">` → `offers.price`, `offers.priceCurrency`; `priceSpecification` keys `listPrice|rrp|was|compareAt`.
2) Embedded JSON: `window.__NEXT_DATA__`, `__APOLLO_STATE__`, Redux, `dataLayer`; Shopify (`compare_at_price`=RRP; `price`=Sale).
3) DOM patterns:
- WooCommerce: `<del>/.price del/.amount`=RRP; `<ins>/.price ins/.amount`=Sale
- Magento: `.old-price .price`=RRP; `.special-price .price`=Sale
- Shopify: `.price-item--regular`=RRP; `.price-item--sale`=Sale
- Generic: `<del>/<s>` or classes `rrp|old|was|regular|list` vs `sale|special`
- Label + adjacent price (e.g., “RRP:” then a price)
Locale Cues (case/locale-insensitive)
- EN (GB): RRP, List Price, Was, Now, Save, Sale, Clearance
- NL: Adviesprijs, Aanbevolen verkoopprijs (AVP), Van, Voor, Aanbieding, Actie, Korting, Nu
- DE: UVP, Unverbindliche Preisempfehlung, Listenpreis, Statt, Angebot, Reduziert, Jetzt, Sale
- FR/BE-FR: Prix conseillé / Prix recommandé / PVC, Prix barré, Ancien prix, En promo, Remise, Soldes, Maintenant
- BE-NL: follow NL cues
Phase C — Price Candidate Scratch (collect before deciding)
For each price candidate (visible/JSON):
- value (normalized float), currency, source (DOM | JSON-LD | embedded JSON)
- nearby label text within ±100 chars
- tag hints (`<del>/<s>`), class hints (`rrp|old|was|regular|list|sale|special`)
Normalization
- GB: decimal '.', thousands ','
- NL/DE/BE/FR: decimal ',', thousands '.'
- Strip spaces/NBSPs/currency symbols; enforce target currency.
Phase D — Deterministic Mapping (stop at first rule hit)
1) Explicit RRP/MSRP/UVP/List label → RRP = that value.
2) Two prices where one is struck-through OR marked old/was/regular/list → RRP = that; other = SalePrice.
3) Two numeric prices without cues → RRP = higher; SalePrice = lower IF higher > lower by ≥1%.
4) Only one price OR RRP == SalePrice after parse → Escalate to Phase E.
Phase E — RRP Sourcing (only if no distinct RRP on retailer page)
- If the page showed only one price, keep that as SalePrice.
Obtain verifiable RRP (same model/year & correct currency) from:
A) Manufacturer official product page or COUNTRY store.
B) Official manufacturer price list/press page (same region/currency).
C) 99spokes COUNTRY page with MSRP (only if A/B unavailable).
D) Optional: archived retailer page (Wayback) for exact SKU/model/year & currency.
If still not verifiable → fail with results_failed_json.
Phase F — Availability & Variants
- Stock: In Stock | Out of Stock | Limited | Pre-order | Backorder | Discontinued.
- If sizes/colours: include per-variant stock (e.g., “M: In Stock; L: Out; Red-M: Limited”). Prefer per-variant over global.
Phase G — Validation & Selection
- Currency must match COUNTRY; reject otherwise.
- Make & Model (and year/trim if shown) must match exactly.
- De-duplicate; canonicalize; return up to 3 unique URLs.
- If prices normalize equal, retry render + JSON; if still equal & no RRP → fail.
Tool I/O Contract
- Call "ReportResults" exactly once.
- Payload must be exactly one of:
• results_found_json: up to 3 shops with fields
– Name (string; extract from `<title>` or JSON-LD `name`)
– URL (string)
– RRP (number)
– SalePrice (number or null; null if no discount)
– Availability (string)
• results_failed_json: SitesVisited (non-empty array of hostnames)
- Do NOT output text outside the tool call.
- Tool JSON schema reminder:
`{ "results_found_json": { "Shop1": { "Name": "string", "URL": "string", "RRP": 0.0, "SalePrice": null, "Availability": "string" }, … }, "results_failed_json": { "SitesVisited": ["string"] } }`
Finalization Checklist
- Exactly one of {results_found_json, results_failed_json}.
- If results_found_json:
– Currency matches COUNTRY; RRP verified via A–D.
– RRP ≠ SalePrice.
– SalePrice = null if no discount.
– URLs live, unique, product pages.
- If results_failed_json:
– SitesVisited is non-empty (hostnames only).
- After calling "ReportResults", terminate with no further output.
Execution Policy
- Follow Phases A→G in order. Respect timeboxes. If any error or uncertainty arises, call ReportResults with results_failed_json. Keep tool payload under 500 tokens.
Here’s every enhancement we applied to turn the verbose original into a tight, GPT-4o-mini–optimized prompt:
- Strict Tool Enforcement
* “You MUST callReportResultsexactly once” at top
* “You MUST NOT output any text outside the tool call”- No-Prose Output
* Removed all narrative examples and free-form JSON snippets
* Prohibited any extra text after the tool call- Phased, Ordered Workflow (A→G)
* Phase A: Search
* Phase B: Extraction Order
* Phase C: Price Candidate Scratch
* Phase D: Deterministic Mapping
* Phase E: RRP Sourcing
* Phase F: Availability & Variants
* Phase G: Validation & Selection- Operational Constraints & Timeboxing
* Per-site timeout (≈10 s search + ≈20 s render)
* Max pages visited (15) and early-stop once 3 results- Inputs & Currency Rules
* Explicitcountry | make | modelinputs
* Enforced target-country currency mapping (GBP/EUR)- Hard Requirements
* Exactly one of{results_found_json, results_failed_json}
* RRP≠SalePrice; never inferred from discounts/arithmetic
* Prefer full bikes; enforce exact make/model- Extraction Stack
* JSON-LD → Embedded JSON state → DOM patterns
* Concrete selectors for WooCommerce, Magento, Shopify, generic- Locale-Specific Cues
* Case-insensitive labels for EN/NL/DE/FR (e.g., RRP, UVP, Adviesprijs, Prix conseillé)- Price-Candidate Scratch Stage
* Collect all price candidates with value, source, nearby label, tag hints- Deterministic Mapping Rules
- Explicit RRP label → struck-through cues → higher-vs-lower logic → escalate
- RRP Sourcing Phases
- A) Manufacturer page
- B) Official price list/press page
- C) 99spokes MSRP
- D) Archived Wayback page
- Single-Price Clarification
- If only one price found, keep it as
SalePricebefore sourcing RRP
- Availability & Variant Stock
- Capture global and per-variant status (In Stock, Limited, etc.)
- De-duplication & Selection
- Canonicalize URLs; return max 3 unique results by priority
- Tool I/O Contract + Schema Reminder
- Added brief JSON-schema snippet under “Tool I/O Contract”
- Clarified field types (Name:string, URL:string, RRP:number, SalePrice:number|null, Availability:string, SitesVisited:[string])
- Finalization Checklist & Fail-Safe
- Pre-tool checklist to enforce currency match, RRP verification, distinct pricing, non-empty SitesVisited
- “If any error or uncertainty arises, call
results_failed_json”
- Token-Efficiency
- Soft limit on tool payload (“Keep under 500 tokens”)
- Removed redundant phrases (e.g., dropped “Think silently”)
- Phase Numbering & Bullet-Heavy Formatting
- Clear headings and compact bullet lists to suit mini’s list-processing strengths
These cumulative changes ensure GPT-4o-mini stays on-rails, always invokes your
ReportResultstool exactly once, and outputs only fully validated, structured payloads.
Amazing work @bobthebear!!!!
I would love to share this prompt/instruction engineering master class internally and with other users 
@Matthew_Carter let us know if this was able to get lower the miss rate on the tool usage to lower than the 1/10 you were describing before.
Hey @bobthebear thanks I put it in and have been tweaking a little, but seems to be performing much better! Thank you, how could I go about settting up my own version of GPT-5+4o+Claude_Gork discussion bot? Did you use n8n?
so glad it worked!
I use LangChain to make agents using different models, your prompt enters a LangGraph as a HumanMessage, and is passed around to each agent who is able to see what the other agents have done. They're goal is to 1st rewrite the prompt for 4o-mini, then they judge each others solution and use it to modify their own until they all agree they can't make any more improvements. At this point everything is passed along to a 'Synthesis Agent' that takes the final output of each agent and builds a combined version as a final solution with an explanation.
You're actually right on the money with this! I went ahead and gave it your quote as input, except for the ending: "... Is this a bug/side-effect or because it's better aligned for SEO reasons? Is there a way to improve the prompt to generically cover this case and any others that may arise from similar reasons?"
The "Amsterdam" query simply matches what real retailers actually publish, whereas "Netherlands" rarely shows up in product-page titles or URLS--so you get far better hits.
- City vs Country in URLs/titles
- Retailers use city or region pages ("Amsterdam store") or country-code TLDs (.nl) but rarely embed the English word "Netherlands" in their URLs or H1s- Language alignment
- In dutch they'll say "Nederland" (or use no country name at all) -- so an English "Netherlands" query often misses the exact matches.- Search engine indexing
- Google/Bing weight the TLD and localized keywords (e.g. "kopen," "site:.nl") far more heavily than a generic country name in EnglishWe can bake a generic "fallback" step into Phase A so that whenever country-level queries underperform, the agent automatically swaps in TLD-driven searches and major city (or region) keywords for that country. This covers "Netherlands" vs "Amsterdam" and any similar future cases.
You’ll need to supply for each country a small list of the local-language name plus 2–3 major cities or regions. That way:
“Netherlands” → “Nederland”, “Amsterdam”, “Rotterdam”
“Germany” → “Deutschland”, “Berlin”, “Munich”
etc.This generic fallback ensures you surface the right pages without special-case code whenever country-name SEO mismatches occur.
Since you only ever target the five countries {GB, NL, DE, BE, FR}, just supply for each one:
• its native-language name
• a short list of 2–3 major cities or provincesThen Phase A “fallback” step simply looks up the list for the current country and iterates through those terms as needed.
Here's the updated section of the prompt:
Currency Rules (reject mismatches)
{no changes here}
Localizations (for fallback searches)
- GB: ["United Kingdom","London","Manchester","UK"]
- NL: ["Nederland","Amsterdam","Rotterdam","NL"]
- DE: ["Deutschland","Berlin","München","DE"]
- BE: ["Belgique","België","Brussels","Antwerp","BE"]
- FR: ["France","Paris","Lyon","FR"]
Hard Requirements
{no changes here}
Operational Constraints
{no changes here}
Phase A — Search & Generic Fallback
1. Primary queries (stop once you have up to 3 valid pages):
- "Buy [Make] [Model] site:[country TLD]" (localized “buy” term)
- "[Make] [Model] for sale [COUNTRY]"
- "[Make] [Model] 99spokes [COUNTRY] msrp"
2. If after (1) you have < 2 valid pages, run fallbacks in this order (stop once you reach 3 total):
a) TLD-only: "Buy [Make] [Model] site:[country TLD]" + localized “buy”
b) Local-language country name from Localizations list
c) Each major city/region from Localizations list
3. Priority for all queries: Manufacturer → Major nationals → Reputable locals
I'll see what I can scrape together this weekend and share it in the show-and-tell category (the actual code is part of my companies product, so I can't copy the code but I can re-make a part of it as an example using the above flow to help people learn)
@Jack_T I don't mind one bit. If you want an example also, let me know if you think it'd be better to build it out in parts to gradually introduce more complex stuff (basic agents/prompts -> memory usage/message history [for dynamic prompts] -> agent planning, orchestration, and synthesis).... unless you got everything you need 
@bobthebear Amazing!
My first thought would be breaking things down into parts to gradually to help someone new to LLMs and Agents wrap their heads around what is going on so they can deeply understand and tweak as needed the way Matthew_Carter did.
Thinking we could start with this as a couple posts in Tips and Tricks, while I talk with my team about getting this codified into our Agents docs!
I've been struggling with this myself, where an Agent will reliably run every tool except seemingly for the one I really needed it to run, which has been a Workflow to send an external report of the task it accomplished.
One thing that helped, other than some of the guidance @bobthebear has already suggested, was at the beginning of the prompt, making it clear to the Agent that their main job was to use the specific tool that needed to be used.
You are the '
<tool name>' specialist. Your primary function is not just to<overall task>, but to expertly package and deliver it using the '<tool name>' tool. Your very purpose is defined by the successful execution of this tool. The job is NEVER complete until this final, non-negotiable step is performed.
Hope that can help others!