The apartment cost USD 2,130 a month in the browser. A fast read of its leasing calculator returned HTTP 200 and a total of zero.
That was the awkward part of an October 12, 2026 rental comparison using 2Captcha MCP. The Asher apartment #3083 showed USD 2,065 in base rent plus USD 65 in mandatory monthly fees for a 12-month lease. Feeding zero into the comparison would have made the apartment look free.
This article revisits that recorded case. I haven't rerun the calculator, and the prices aren't a current offer.
Two routes, different evidence
The log contains two fast reads: the calculator URL and the same URL with ?modal=1. Both returned zero totals without base rent. The saved browser screenshot shows unit #3083, an October 12 move-in date, a 12-month term and the USD 2,130 monthly total together.
A separate extraction of the main apartment detail page returned 2065, 2130 and 12 months, matching the browser. That gave me usable evidence from that page. It didn't settle what happened on the calculator route.
I requested a rendered read too. Its last recorded status was running; the completed outcome isn't in the evidence set. I can't call it a fix or a failure. The cause of the discrepancy remains unknown.
The mistake to avoid is treating a successful response as permission to use every number inside it.
What I'd keep beside the price
For this apartment, a useful comparison row would contain:
- Object: The Asher, apartment #3083.
- Conditions: October 12 move-in, 12-month term.
- Browser observation: USD 2,065 base rent, USD 65 mandatory monthly fees, USD 2,130 monthly total.
- Fast calculator reads: zero totals, base rent absent.
- Rendered read: last seen running; completed outcome unknown.
I'd keep the URLs and supporting passages from the returned content with that row. Then I could see the disagreement without asking the model to choose the more plausible price.
A passage needs checking against the actual tool output. It can support a field without proving the page was complete. And although zero may be valid, an absent price doesn't establish zero.
Pending work needs its own place in the record. If a call returns a background job, inspect its terminal outcome and result before using the field. Submitting another request doesn't tell you how the first one ended.
Where page loading fits
Playwright documents that interfaces can keep updating after the load event. Scrapy suggests locating the underlying data source, using a browser when needed. Neither diagnoses this calculator result.
Before sending Total Monthly Leasing Price to a spreadsheet, I'd check the same unit and lease conditions in the browser.
Try one field first
The official 2Captcha MCP repository has setup and tool documentation. You'll need an account and an API key in your client's configuration.
Here's a proposed agent prompt, not a tested run or a built-in MCP response schema:
Read this public URL and find the requested field. Keep the URL, object ID, selected conditions and a supporting passage with the value. Mark missing information unknown. If the operation returns a background job, inspect its terminal result. Leave the value out of calculations until it has been independently checked.
Start with a field you can inspect yourself. An unresolved result is still useful when it shows exactly what's missing.
Sources
2Captcha MCP setup and tools: https://github.com/2captcha/2captcha-mcp
Playwright navigation and loading: https://playwright.dev/docs/navigations
Scrapy dynamic content: https://docs.scrapy.org/en/latest/topics/dynamic-content.html
Recorded rental walkthrough: https://dev.to/michael_p_brain/how-i-used-mcp-to-compare-apartment-rent-and-fees-in-austin-2m80
Calculator routes investigated: https://www.theasheraustin.com/floorplans/b1/3083/calculator/ and the same route with ?modal=1
Top comments (5)
"An absent price doesn't establish zero" is the line I'd keep taped to the monitor. One cheap gate that fits your comparison row: before a number from a fast read goes into a calculation, require that the supporting passage actually contains that number or the field label as text. A total of 0 with no passage behind it is a parse that found nothing, not a value. And storing the rendered read as pending with its job id, instead of firing another request, is the right call for exactly the reason you give: a second request tells you nothing about how the first one ended.
Agreed. I'd check the field label too. In this case, $2,065 was base rent and $2,130 was the monthly total. Mixing those up would still give a plausible-looking comparison, even with a passage supporting each number. Keeping the job ID also leaves a specific result to follow up on.
I work on Tokenade, which trims what a tool returns before the model reads it, so this is my daily problem. A success status only tells you the page arrived. It says nothing about whether the number the agent read matches the one on screen.
That adds another place to check. Did the model receive the same evidence the tool returned? For Tokenade, how do you decide which field labels and conditions to keep when trimming a response? Those details can change what a price means.
@michael_p_brain Same evidence is the right bar, and a success status can't meet it. A price only means something with its unit and its condition next to it, so I'd keep those with the number when a response gets trimmed.