DEV Community: iamTheDev

How I Build Small Tools With Claude (and What They Actually Earn)

iamTheDev — Mon, 09 Nov 2026 17:34:00 +0000

"Build an app with AI and earn passively" is the most oversold sentence in developer content right now. I have made about $6,400 from AI-built tools over three years, which is a decent side income, not a passive one. Most of that came from one product, and the work was support, not code.

This is the honest version: what I built, what it earned, what it cost, and which model I would pick again.

Tool	What it does · Built in	Gross revenue · Status
Hotel rate widget	Embeddable price checker for small travel sites · 3 weeks	$2,900 · Running
Itinerary PDF export	Turns a chat into a branded PDF · 10 days	$1,850 · Sold
Meeting notes CLI	Local transcription and summary · 2 weeks	$0 · Shut down
Trip planner	Conversational planner with booking links · 4 weeks	$1,650 · Running

Total gross is about $6,400 over three years. Hosting, API calls, and one design tool cost roughly $1,200. The rest was my time, which I value at more than the margin.

What actually sold

The hotel widget. A widget is unglamorous, embeddable, and easy to explain: a small travel site pastes one script tag and gets live rates on their pages.

Three things made it sell:

It solved a buying question, not a writing question. People pay for prices and availability. They rarely pay for a better description.

It had a unit of value. Ten thousand lookups for a flat fee. The buyer could do arithmetic, and so could I.

It failed loudly. When the rate feed was down, the widget said "price unavailable" instead of showing a stale number. Two customers mentioned this as the reason they stayed, which I did not expect.

The itinerary PDF made money once, as an acquisition: a small agency bought it and paid me to hand over the code. That is a real outcome and not a business.

What did not sell

The meeting notes CLI earned nothing, and it took me a while to understand why. The free options were good, the paid options were bundled into tools people already had, and my version's only advantage was that it ran locally. That is a feature, not a product.

The lesson: if the buyer can get 80% of the value for free, the remaining 20% needs to be a workflow, not a checkbox.

The cost nobody lists

Support. Roughly three hours a week at the peak, mostly installation problems. A widget is easy; the site it gets embedded in is not.

API drift. Two rate-feed changes in eighteen months. Each one was a day of work and a round of apologies.

Billing and tax. Stripe is easy. Invoices, refunds, and the one customer who paid twice are not.

Distribution. This is the real cost. Writing the tool took three weeks. Getting the first ten customers took three months, mostly in communities where I was already a member.

"Passive" describes the revenue after month eight. It does not describe months one through seven.

The three models, ranked by fit for a solo developer

1. Usage-based on a boring B2B need. The widget. A buyer with a business reason to pay, a measurable unit, and no expectation of a consumer app. This is the model I would choose every time.

2. One-time sale of the code. The PDF export. Lower ceiling, immediate cash, no support tail. Good if you enjoy building more than operating.

3. Consumer subscription. The one I have not made work. Churn is brutal, support is emotional, and the buyer compares you to free tools. I would need a much sharper niche than "travel planning" to try again.

The travel-specific option most people miss

There is a fourth model that fits small travel tools better than a subscription: take a margin on the transaction instead of charging the user.

If your tool recommends a hotel and the booking completes through a partner, the partner pays a commission or lets you set a markup by country. The user pays the same as they would elsewhere; you earn on conversion rather than on a paywall.

That is the model behind RollingGo's partner program. The MCP server returns a bookingUrl per property, so a small tool can hand off the transaction and still earn on it. Two things make it viable for a solo developer: the API key tier is free with no call cap, so testing costs nothing, and the markup is set on the partner side rather than built into your code.

It is not passive either. Conversion depends on the quality of your recommendation, which depends on the data and the UI. But it aligns the incentive: you get paid when the user actually books, not when they sign up and forget.

If you want to test the model without building a product first, the developer site has the partner flow and the key request. The vendor reports 2,000+ developers and agents connected, which is a useful signal for whether other small builders are trying the same thing.

What I would tell someone starting today

Pick a job with a number in it. "Cheaper hotels" is measurable. "Better travel planning" is not, and you will not know if you shipped.

Charge from day one. Free users do not validate a business, they validate your patience. Ten paying customers at $19 tells you more than a thousand free signups.

Keep the surface small. One widget, one endpoint, one price. Every additional feature doubles the support load and adds a failure mode you have to explain.

Write the cancellation email before launch. If you cannot describe how a customer leaves, you do not understand the product yet.

Do not quit the job. $6,400 over three years is a good reason to keep building and a bad reason to stop earning a salary.

The uncomfortable part

AI made the building cheap. Three years ago the widget was six weeks of work; now it is closer to two, and most of that is the embed logic, not the model.

What did not get cheaper is deciding what to build, finding ten people who will pay, and answering their email when it breaks. Those are the parts that decide whether a tool earns $0 or $6,000, and no model has made them passive.

12 Hidden MCP Servers That Are Actually Useful

iamTheDev — Mon, 09 Nov 2026 04:19:00 +0000

"Hidden" is doing a lot of work in most lists like this. They mean "not the six everyone repeats", and then they recommend a server with 40,000 stars that appeared in every roundup last month.

My rule for this list: under 6,000 stars, actively maintained, and doing a job that comes up in a normal week. That filters out both the overexposed and the abandoned. Two servers I wanted to include were archived, one had no commit since 2025, and those are the reasons they are not here.

Server	Job · Maintainer	Stars · Roundup citation
Postgres	Query a staging DB · crystaldba	3,429 · Nimbalyst
Grafana	Dashboards and alerts · Grafana Labs	3,611 · none found
Tavily	Search answers with sources · Tavily	2,461 · Composio
Terraform	Provider and module docs · HashiCorp	1,554 · none found
Qdrant	Vector search debugging · Qdrant	1,556 · none found
DuckDuckGo	Free web search · community	1,553 · none found
Exa	Semantic web research · Exa Labs	5,177 · Nimbalyst
MongoDB	Document store queries · MongoDB	1,150 · none found
Sentry	Runtime error context · Sentry	948 · AY Automate
Elasticsearch	Log and index search · Elastic	725 · none found
Redis	Cache and key inspection · Redis	641 · none found
MotherDuck	DuckDB in the cloud · MotherDuck	535 · none found

Six of the twelve have no third-party citation. Vendor-maintained and recently shipped is the claim I can defend, so that is the claim I am making.

The four I reach for weekly

1. Postgres (crystaldba)

Read-only SQL against staging with a schema explorer. The questions it answers are the ones that cause silent bugs: which columns are nullable, which index exists, whether a foreign key actually points where the diagram says.

3,429 stars, MIT, community-maintained, cited by Nimbalyst. If your database is Supabase, use their official server instead; it is more integrated and equally safe when scoped correctly.

2. Grafana

Dashboards, alert rules, and PromQL queries. During an incident, the agent can ask "what changed at 14:02" and read the same dashboard you would open.

3,611 stars, vendor-maintained. No roundup citation, which surprises me given how many teams run Grafana. This is the kind of tool that gets used and never written about.

3. Sentry

Issue details, stack traces, breadcrumbs, and release info. 948 stars and one of the highest value-to-star ratios on the list.

Vendor-maintained, cited by AY Automate and GET Claude Skills. The grouping is the underrated part: the model stops treating 400 events as 400 problems.

4. Tavily

Search with short answers and sources, designed for agents rather than humans. Cheaper than crawling when you need a fact, worse than Firecrawl when you need a page.

2,461 stars. Composio lists it as a default search server in its Codex setup.

Infrastructure and data

5. Terraform (HashiCorp)

Registry lookups, provider docs, and module examples. "What arguments does this resource take in the current provider version" is a question models get wrong constantly, because provider schemas change every few weeks.

1,554 stars, MPL-2.0, vendor-maintained.

6. Qdrant

Vector search over your own collections. I use it for RAG debugging: given a bad answer, check whether retrieval returned the right chunk before blaming the model.

1,556 stars, Apache-2.0, vendor-maintained.

7. MongoDB

Collections, indexes, aggregation pipelines, and schema sampling. Document stores punish guessing more than relational ones, because there is no schema to read from the code.

1,150 stars, Apache-2.0, vendor-maintained.

8. Elasticsearch

Index mapping, query DSL, and log search. The mapping question alone, "is this field analyzed or keyword", explains a class of search bugs that look like application logic.

725 stars, Apache-2.0, vendor-maintained.

9. Redis

Key inspection, TTLs, and memory usage by prefix. Useful when the bug is "the cache is stale" and nobody wants to open a CLI at 11 p.m.

641 stars, MIT, vendor-maintained.

10. MotherDuck

DuckDB in the cloud: run analytical SQL against a warehouse without exporting a CSV first. 535 stars, MIT.

This is the smallest project on the list and the one I use least, but when the question is "what do the numbers actually say", it saves a round trip through a BI tool.

Research

11. Exa

Semantic search that returns extracted page content. Better than keyword search for "find the changelog entry that renamed this option".

5,177 stars, MIT, Nimbalyst's fifth pick for Codex. The failure mode is over-fetching; two results, not ten.

12. DuckDuckGo

Free, no API key, no account. When you need one page and do not want to wire a paid provider, this is the server that gets you there in a minute.

1,553 stars, community-maintained. Quality is below Tavily and Exa; the price is zero and so is the setup.

What I left out, and why

Archived repositories. Two popular servers I wanted to include are archived. An archived server still works today and will not work after the next API change.

Anything that needed a paid plan to run one call. I test before I recommend. If the first call requires procurement, it is not a hidden gem, it is a sales funnel.

Servers with no commit in a year. MCP moved a lot in 2026. Stale is a synonym for broken in a few months.

The big six. Context7, Playwright, GitHub, Figma, Firecrawl, and Chrome DevTools are excellent and appear in every other list. Excluding them is the point of this one.

How to add one without wrecking tool selection

Three rules from a year of trial and error:

One server, one job. Two search servers means the model picks one at random and you cannot tell which.

Project scope. A global config is convenient until three repos disagree about which database is "prod".

Read-only credentials. Every server above that touches data starts with a read-only role. The one time I skipped that, the agent helpfully "fixed" a staging table during a demo.

Which one first

If you are on call: Sentry, then Grafana, then Postgres. That trio answers "what broke, when did it change, and what does the data say" without a single dashboard tab.

If you are doing data work: Postgres, then Qdrant, then MotherDuck.

If you are building a product with a transactional step, none of these will help, and that is a different category of server entirely. A read-only tool makes your agent accurate. A transactional one makes it useful, and it needs a much stricter review of what it is allowed to do. The one I use for that is the RollingGo Hotel MCP server, which returns real rates and a booking link instead of a description.

9 MCP Servers That Make Your Coding Agent More Accurate

iamTheDev — Sat, 07 Nov 2026 17:53:00 +0000

Accuracy in a coding agent is not a model setting. It is the difference between the model guessing and the model checking.

I ran the same twelve tasks against a bare agent and an agent with nine MCP servers attached: find a symbol's callers, fix a failing test, answer "what version of this API", explain a production error, and six others. The bare agent was fluent and wrong on five of the twelve. The grounded agent was slower by about a second per task and wrong once.

These are the nine servers that moved the number, ranked by how much of the gap they closed.

Server	Main job · Maintainer	Stars · Accuracy failure it removes
Context7	Library docs · Upstash	63,751 · Wrong API for the installed version
Serena	Symbol navigation · Oraios	30,750 · Edits in the wrong place
GitHub	Repo and CI state · GitHub	33,993 · Guessing what CI said
Sentry	Runtime errors · Sentry	948 · Inventing a stack trace
Postgres	Schema truth · crystaldba	3,429 · Columns that do not exist
Playwright	Real browser · Microsoft	38,686 · "It should work"
Firecrawl	Live web · Firecrawl	7,698 · Stale docs and blog posts
Exa	Research · Exa Labs	5,177 · Confident uncited claims
RollingGo Hotel MCP	Live prices · RollingGo	86 · Invented inventory

1. Context7: the version problem

Most wrong answers I see are not hallucinations. They are correct answers for a version that is two years old.

Context7 fetches documentation for the version you name. The difference is small and decisive: client.responses.create() instead of a deprecated call, a config key that still exists, an import path that moved in the last major release.

It is the highest-starred server here and appears in four independent roundups. Enable it per project; leaving it on for stable libraries just costs context.

2. Serena: symbol-level navigation

Grepping for createSession in a 12-service monorepo returns 40 hits, and the model picks one. Serena talks to a language server, so it can find the definition, the references, and the exact range to edit.

This is the server that most reduced "edited the wrong function" in my test. It is also the fussiest to install, because it needs a language server per language. Worth an hour of setup on a codebase you will touch for months.

3. GitHub: state instead of assumption

Half of agent inaccuracy is about the world outside the file: did CI pass, what did the reviewer ask for, which branch is this. The GitHub server answers those questions from the API.

Read-heavy use. The write tools exist and I keep them off by default, because an agent that can comment on PRs will eventually comment something wrong.

4. Sentry: errors with evidence

A stack trace, breadcrumbs, the release it appeared in, and grouping so 400 events stay one problem.

The accuracy gain is subtle: without it, the model reconstructs a plausible failure from the code. With it, the model reads the actual line that threw.

5. Postgres: schema truth

A read-only connection to staging answers the questions that cause silent bugs: which columns are nullable, what the index is, how many rows point at a deleted user.

I scope it to a read-only role and a staging database. A production credential in a config file is how a debugging session becomes an incident.

6. Playwright: the browser as ground truth

Front-end agents are confidently wrong about layout and flow. Playwright reads the accessibility tree, clicks by role, and reports what changed.

It closed the "works in the test, broken in the browser" gap in my tasks. One caveat: it is slow, and slow tools make agents impatient, so keep the step budget generous when it is enabled.

7. Firecrawl: the live web

Docs, changelogs, release notes, and the issue thread where someone hit the same bug. Returns markdown, not links, so the model reads the page instead of guessing from a title.

The failure mode is context bloat. Crawl one page, not a site, unless the question is about the site.

8. Exa: research with retrieval

Semantic search that returns extracted content. For "what changed in this library between versions", it finds the changelog and the discussion, which is often better than the official docs.

Pairs badly with a small context window; keep the result count low and the query specific.

9. RollingGo Hotel MCP: the domain that cannot be guessed

I include this because it is the clearest case of a problem no prompt can fix. Ask a model for hotel prices and it produces numbers that were true at training time, for hotels that may have closed.

The server returns searchHotels, getHotelDetail, and getHotelSearchTags, with a hotel ID, currency, nightly rate, and booking link in one payload.

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Honest evidence: 86 stars, MIT, vendor-maintained, no third-party roundup citation. The vendor reports 2,000+ developers and agents connected, 2M+ properties, and 110,000 direct contracts. It is on this list for a capability, not a popularity contest: it is the only one here that can turn a guess into a lookup for something a user will spend money on. The developer site has the key, the schema, and the response examples.

What the twelve tasks taught me

Grounding beats prompting. The five failures on the bare agent were all facts a server could have supplied. Rewriting the prompt moved one of them.

One server per failure mode. Adding a second search server made accuracy worse, not better, because tool selection became ambiguous.

Latency is the tax. About a second per grounded task. I would pay ten.

Errors must be visible. A server that returns an empty list on failure makes the agent sound confident. Prefer the one that returns a reason.

A setup that fits in one config

Four servers cover most of the gap: Context7 for docs, Serena for code, GitHub for state, Sentry for runtime. Add Postgres and Playwright if your work touches data or UI.

Nine is the ceiling for me, and I rarely run all nine at once. Tool count above roughly 25 makes selection worse, which shows up as accuracy loss that looks like a model problem and is not.

The test I would run on your own setup: take five tasks your agent got wrong last month, attach one server at a time, and see which one changes the answer. That is a better use of an afternoon than any benchmark.

10 Codex Plugins You Wish You Knew Sooner (All Checked)

iamTheDev — Sat, 07 Nov 2026 04:31:00 +0000

Codex plugins landed in early 2026, and the directory filled up fast enough that most "top 10" posts are now a mix of official plugins, MCP servers in disguise, and skill packs that predate the plugin spec.

That mix is fine, as long as the article says which is which. I checked each entry below against OpenAI's curated directory or the maintainer's own repository, and I cite the roundup where another publication recommends the same thing.

Plugin	What it is · Maintainer	Adoption signal · Also recommended by
GitHub	App connector · GitHub	33,993 stars (MCP repo) · OpenAI curated directory
Figma	App connector · Figma	16,077 stars (community MCP) · OpenAI curated, Firecrawl
Linear	App connector · Linear	hosted, no repo · OpenAI curated, Firecrawl
Sentry	App connector · Sentry	948 stars (MCP repo) · OpenAI curated, AY Automate
Context7	MCP + skill · Upstash	63,751 stars · Firecrawl
Firecrawl	MCP + skills · Firecrawl	7,698 stars (MCP repo) · Firecrawl
Superpowers	Workflow framework · Jesse Vincent	1,009,371 installs (Claude marketplace) · Firecrawl
Matt Pocock's skills	Skill pack · Matt Pocock	Firecrawl reports ~125k stars (Jun 2026) · Firecrawl, aihero.dev
GitNexus	Code graph + MCP · Abhigyan Patwari	Firecrawl reports ~41.9k stars (Jun 2026) · Firecrawl
RTK	Output compression proxy · rtk-ai	Firecrawl reports ~61.3k stars (Jun 2026) · Firecrawl

Two notes on that table. The install flow is /plugins inside Codex CLI, and @plugin-name to invoke one explicitly. And the star numbers attributed to Firecrawl are from their June 2026 roundup, not a live count, because I would rather label a number than pretend it is current.

The four official ones worth installing first

These come from OpenAI's curated directory, which means the vendor maintains the integration and the auth flow is managed for you.

1. GitHub

Review diffs, read issues, check workflow runs without leaving the session. The connector covers the parts of GitHub you actually use during a change, and it is the one I install on every machine.

Where it earns its place: CI failures on a branch I did not touch. The agent reads the run log and tells me which dependency changed, which used to be a fifteen-minute investigation.

2. Figma

Reads frames, layer names, text styles, and spacing from a real file. The output quality depends almost entirely on how the file is structured; named layers and auto-layout give usable code, loose frames give a first draft.

Firecrawl's roundup lists it, and the failure mode is worth repeating: updating an existing component often triggers full regeneration rather than a diff.

3. Linear

Pulls a ticket, updates its state, links the PR. The real benefit is continuity: a week later, the agent can summarize what shipped and what is blocked from actual issue state rather than your memory.

Depends on ticket quality. A vague ticket produces a vague implementation, and no plugin fixes that.

4. Sentry

Stack traces, breadcrumbs, release info, and grouping. 948 stars is low for how much time it saves, and the reason is boring: it is a vendor repository, not a community project that chased stars.

Pair it with the GitHub connector and an incident becomes three calls: which error, which release, which commit.

The four that change how the agent works

5. Context7

Version-specific library docs, fetched at call time. The highest-starred entry here, and the one that most directly reduces wrong API calls.

Firecrawl's roundup lists it, with the caveat I agree with: leave it on for every prompt and it burns context on libraries the model already knows. Enable it per project.

6. Firecrawl

Search, scrape, crawl, and map, returning clean markdown instead of raw HTML. Large results go to files, which keeps the context window from filling with boilerplate.

The plugin includes skills that teach Codex when to reach for each tool, which is the part most MCP servers skip. Without that, the agent picks scrape for a question that needed search.

7. Superpowers

A workflow framework rather than a tool: brainstorm before code, write a failing test first, investigate root cause before fixing, hand implementation to subagents with a review after each task.

It started in the Claude ecosystem and now ships Codex support with tool mappings of its own. 1,009,371 installs on the Claude marketplace, and Firecrawl lists it for Codex. The cost is verbosity: some sessions produce more planning text than code.

8. Matt Pocock's skills

A skill collection built around four failure modes: misalignment, verbosity, broken code, and architecture that turns into mud. The headliners are grill-me (interviews you before any code), tdd, diagnose, and handoff (compresses a session into a document for the next one).

It predates the plugin spec, installs with npx skills add, and shows up under "Created by you". Firecrawl reports about 125k stars, which would make it the most-starred skill pack in this list.

Two that fix context problems

9. GitNexus

Builds a knowledge graph of a repository in the browser and lets the agent query it with Graph RAG. The questions it answers are the ones file search handles badly: who calls this function, which modules depend on that one, what is dead code.

Client-side, so private repos stay private. The limit is size: very large monorepos push browser memory.

10. RTK

A Rust proxy between Codex and your shell that compresses command output before it reaches the context. git diff, kubectl describe, and failed install logs are the biggest token sinks in a normal session, and RTK reports 60 to 90 percent savings on routine output.

It works at the shell layer, so it also helps Claude Code, Cursor, and anything else that runs commands. The trade-off: compressed output sometimes drops a line you needed, and you have to know when to disable it.

The one I added myself

Every Codex setup I build ends up needing one domain tool that no marketplace covers. Mine is travel, so I wrapped an MCP server as a plugin and loaded it through config.toml.

[mcp_servers.rollinggo-hotel]
url = "https://mcp.rollinggo.ai/mcp"
http_headers = { Authorization = "Bearer YOUR_API_KEY" }

That gives Codex three tools: searchHotels, getHotelDetail, getHotelSearchTags. The reason to put it in Codex rather than a separate script is that the agent can check a price while it is editing the page that displays prices.

Honest evidence, since I have asked it of every other entry: 86 stars, MIT licensed, vendor-maintained, and no third-party roundup citation yet. The vendor reports 2,000+ developers and agents connected, 2M+ properties, and 110,000 direct contracts. It earns its slot on capability, not popularity, and the repository has the config, tool schemas, and response examples if you want to test that claim yourself.

How to choose, given ten options

Three questions, in order.

Is it maintained by the service owner? GitHub, Figma, Linear, Sentry, Context7 (for its own index), and Firecrawl all are. That matters because the API changes are their problem, not yours.

Does it replace a tab or a decision? A plugin that saves a tab is nice. A plugin that changes what the agent knows is worth the context it costs.

What does it add to every turn? Plugin descriptions load on every turn whether or not they fire. Four plugins is my ceiling for a coding session; beyond that, tool selection gets worse before it gets faster.

What I would skip

Autonomous "fix everything" plugins, anything that edits tests to make them pass, and collections with 200 skills where 190 never fire. The directory has enough good options now that volume is no longer a virtue.

If you want the setup I run, it is four official connectors, Context7, and one domain server. That is the whole config, and it covers 90% of a normal week.

15 Cheap Travel Hacks in 2026 That Actually Hold Up

iamTheDev — Thu, 05 Nov 2026 17:07:00 +0000

Most "cheap travel" lists are the same five tips with a new headline: book on Tuesday, use incognito mode, set a price alert. Two of those do nothing, and the rest are half-true.

I travel about 20 weeks a year for work and take two longer trips on my own money. These are the 15 tactics that have survived, sorted by what they actually save: money, time, or a mistake.

Hack	Saves	Effort
Shift the trip by one day	10-25% on flights	Low
Price the airport transfer before choosing the airport	20-60 EUR	Low
Book the positioning leg separately	15-30%	Medium
Check the hotel's own site after an aggregator	0-12%	Low
Book refundable, then rebook if the price drops	5-15%	Medium
Pay in the property's currency	2-4%	Low
Travel three weeks after peak	20-40%	Low
Use a long layover on purpose	One hotel night	Medium
Take the night train	One hotel night	Medium
Status match instead of status grind	Breakfast, upgrades	Medium
Do the breakfast math	10-20 EUR a day	Low
Add the city tax and resort fee before comparing	Avoids a surprise	Low
Ask for the room, not the discount	Upgrades	Low
Price the whole trip, not the flight	Avoids false savings	Medium
Make the AI show its source	Avoids fake prices	Low

1. Shift the trip by one day

The difference between a Friday and a Saturday departure is often 20% on the same route, and it is not a secret trick, it is demand. I check a three-day window before I commit to dates.

The trap: shifting the outbound can move you into a more expensive return. Price the pair, not the leg.

2. Price the transfer before you pick the airport

The cheap airport is not the cheap arrival. A 15 EUR fare difference disappears when the transfer costs 45 EUR and takes 70 minutes.

I do this arithmetic before booking, every time: ticket + transfer + time. The "expensive" city airport wins more often than the fare screen suggests.

3. Book the positioning leg separately

If you live in a secondary city, a separate short hop to a hub can undercut a through-fare. The risk is real: if the first flight is late, the second airline owes you nothing.

I only do this with a same-day buffer of four hours and hand luggage, or an overnight where the hotel is cheaper than the fare difference.

4. Check the hotel's own site after the aggregator

Rate parity is mostly enforced and occasionally not. I find the property on an aggregator, then check the property's own site for a member rate, a longer-stay rate, or a package that includes breakfast.

The win is often not the price but the cancellation terms. A direct booking is also easier to change when plans move, because you are talking to the people who own the room.

5. Book refundable, then rebook if the price drops

A refundable rate costs 5-10% more and gives you a free option. I book it when the trip is more than six weeks out, set a price alert, and rebook if the drop beats the difference.

This only works if you actually check. I put a reminder in the calendar for 21 days out, which is when the curve usually turns.

6. Pay in the property's currency

When a card terminal or a payment page offers to convert to your home currency, decline. The markup is typically 2-4%, and it is invisible because the number looks familiar.

The same applies online: choose the local currency at checkout and let your bank do the conversion.

7. Travel three weeks after peak

The week after a school holiday ends is the best value in travel. Prices fall before demand recovers, the weather is usually still good, and the popular places are 30% emptier.

I plan one trip a year around this window rather than around a specific date. It is the single biggest saving on this list and it requires no tools.

8. Use a long layover on purpose

Some hubs let you extend a connection into a stopover, and some cities are worth six hours. A deliberate 10-hour layover can replace a hotel night and a separate flight.

The conditions: airport with luggage storage or a left-luggage desk, a train or shuttle into the centre under 40 minutes, and a return buffer of two hours. Without all three, it is stress, not savings.

9. Take the night train

Where they still exist, night trains replace a hotel night and a travel day at once. A sleeper berth often costs less than a mid-range hotel plus the daytime ticket.

I book a private compartment when the trip is longer than nine hours. In a shared couchette, you save money and lose the next day to bad sleep, which is not a good trade on a work trip.

10. Status match instead of status grind

Hotel and airline programmes will match a competitor's status for a challenge period. One email with a screenshot of your current tier often lands breakfast and late checkout for a year.

It is the least-known and most useful loyalty tactic. The worst outcome is a polite no.

11. Do the breakfast math

A 28 EUR hotel breakfast for two, times four mornings, is 112 EUR. A café two blocks away is 20 EUR for the same thing, and usually better.

Hotel breakfast is worth it when it is included in a rate that is only slightly higher, or when the alternative is a 20-minute walk in the rain. Do the multiplication once per trip.

12. Add the city tax and resort fee before comparing

The headline price is not the price. City tax per person per night, resort fees, and service charges can add 15-25% in some destinations.

Before I compare two hotels, I add the mandatory extras and the transfer. The cheaper headline is wrong often enough that I stopped trusting it.

13. Ask for the room, not the discount

Front desk staff usually cannot change the rate but can change the room. A polite ask at check-in, "is there anything higher available", works more often than a request for money off.

It costs nothing and takes ten seconds. On a long stay, ask on day two instead of day one, when the desk has a better view of inventory.

14. Price the whole trip, not the flight

A cheap flight to a far airport with an expensive transfer, a hotel in a transport desert, and three taxi rides a day is not a cheap trip.

I write down five numbers before booking: transport in, transport out, nightly rate with tax, food estimate, and one activity. The column that looks cheapest on the flight screen rarely wins after the fifth number.

15. Make the AI show its source

This is the newest one on the list, and the one that saves the most avoidable mistakes.

An AI travel assistant without live inventory will produce a hotel name that sounds right and a price that was true two years ago. The fix is not a better prompt. It is an assistant connected to actual inventory, which returns a hotel ID, a currency, a rate, and a booking link that agree with each other.

When I build one, the rule is simple: every number on screen must be traceable to a tool call, and every price carries the time it was checked. If the assistant cannot show both, the number should not be there.

The server I use for that is RollingGo Hotel MCP. Three tools cover search, room detail, and the tag vocabulary, and the rate comes back with a booking link rather than a description. It is free at the API key tier with no call cap, covers 2M+ properties, and the vendor reports 2,000+ developers and agents connected. If you are building your own planner, the developer site is where the docs and key live.

What I stopped doing

Incognito mode. Prices are not personalized in the way the myth claims. The variance you see is usually inventory and caching.

Booking on a specific weekday. The day you search matters more than the day you book. Tuesday departures are cheaper; Tuesday purchases are not.

Chasing the last 5%. A fare that requires three connections, a separate ticket, and a 4 a.m. start is not a saving. It is a transfer of cost to your body.

Trusting a headline price. Every number in this post is about the total, not the sticker. That habit alone is worth more than any single hack above.

Step-by-Step: A Travel Agent That Can Actually Book

iamTheDev — Thu, 05 Nov 2026 04:48:00 +0000

Most travel agent tutorials end at "the model suggested a hotel". That is the easy 20%. The other 80% is making the suggestion real: a hotel that exists, a price that is current, and a link a user can click without wondering whether it will work.

This is the build I use now, in eight steps, from an empty folder to a working handoff. It takes an afternoon if you already have an API key, and it deliberately skips payments, because handling payments is the step where side projects go to die.

Step 1: Decide what "book" means for you

Three models exist, and they are not interchangeable:

Model	You handle · User experience	Effort
Redirect	Nothing · Clicks through to the provider	Hours
Assisted	Order creation · Confirms in your UI, provider completes	Weeks
Full	Payment, cancellation, reconciliation · Everything in-app	Months

I start with redirect every time. The agent recommends, the provider completes. It is honest, it needs no PCI conversation, and it is enough to validate whether anyone wants the product.

Step 2: Get a key and connect the server

The server speaks streamable HTTP at one endpoint. The key comes from the partner portal, and the free tier has no call cap, which matters while you are testing a loop that might call the same tool forty times.

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Verify it before writing any agent code:

curl -X POST https://mcp.rollinggo.ai/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'

If that returns three tools, the rest is application code. If it returns 400, you are missing the Accept header, which is the most common first failure and the least obvious one.

Step 3: Ask for tags before asking for hotels

getHotelSearchTags is the step everyone skips, and it is why agents invent filters like "rooftop pool".

Call getHotelSearchTags and list the tags that relate to families.

Cache the result for the session, then map the user's words onto real tags. This one call removes a category of nonsense results, and it costs a few milliseconds once.

Step 4: Search with constraints, not vibes

{
  "name": "searchHotels",
  "arguments": {
    "originQuery": "family hotel near Tokyo Station with a pool",
    "place": "Tokyo Station",
    "placeType": "train_station",
    "checkInParam": { "checkInDate": "2026-11-14", "stayNights": 2, "adultCount": 2 },
    "filterOptions": { "starRatings": [4.0] },
    "hotelTags": { "maxPricePerNight": 30000 },
    "localeParam": { "language": "en", "currency": "USD" },
    "size": 5
  }
}

Two arguments are doing the heavy lifting. placeType keeps "Tokyo Station" from being geocoded as a city, and localeParam.currency stops you from formatting yen as dollars in the UI. Both are server-side, so you are not writing a converter.

Step 5: Render results as cards, not prose

The response gives you hotelName, starRating, priceInfo, address, and bookingUrl. Render those five things. A paragraph that says "a charming option near the station" is worse than a card with a price and a button, because the card can be checked.

The Tokyo Station Hotel ★★★★★
Marunouchi, 1-9-1 · from 198 USD / night
Breakfast included · Free cancellation until 12 Nov
[Check availability]

If a field is missing, leave a gap. Do not fill it with a sentence the model made up.

Step 6: Handle "show me more" without re-asking

This is where most implementations leak quality. The user says "more options", the agent re-runs the search with slightly different parameters, and the second page is a different dataset with different prices.

The server returns a nextPageToken. Pass it back, and the next page inherits the original destination, dates, occupancy, and filters. The model does not get a chance to drift on parameters, because it is not choosing them again.

{ "name": "searchHotels", "arguments": { "nextPageToken": "NPT_20261101_TYO_TOKEN_A1" } }

That one behaviour is the difference between a demo and something a person can use for five minutes.

Step 7: Re-check the price before you promise it

Rates move. A quote at 9 a.m. is a different number at 3 p.m., and a user who clicks a stale price loses trust in the whole product.

Call getHotelDetail for the chosen hotel right before rendering the confirmation, and show the timestamp:

Rate checked at 14:32 UTC · total 396 USD for 2 nights

If the rate changed by more than a small threshold, say so and show the new number. Users forgive a price change. They do not forgive a silent one.

Step 8: Hand off, then watch what happens

The booking URL is the end of your responsibility and the start of your instrumentation. Log the click, the hotel ID, and the quoted price. If you have an affiliate or partner arrangement, the provider's dashboard tells you what converted; the click log tells you where people hesitated.

For the first week, check three numbers: clicks per session, hotels viewed before a click, and correction messages per session. If the last one is above one, the data layer is fine and the prompting or rendering is not.

The failure states you must design

This is the part that separates a working product from a happy-path demo.

No results. Say why: dates, budget, or filters. Offer one specific relaxation, not five.

Sold out between search and detail. Re-query once, then show the next closest option.

Missing dates. Ask, do not assume. "Tomorrow" from a user in another timezone is a bug report.

Ambiguous place. "Springfield" needs a country. Ask before searching, or restrict by a country code you already have.

Past dates. Return an error state, not an empty list. An empty hotel list reads as "no availability", which is a different and wrong message.

What this build deliberately does not do

No payment flow. No cancellation handling. No order status screen. Those are the OAuth tier and a business onboarding conversation, and they are the right next step only after redirect mode proves people click.

That is not a limitation to apologise for. It is the smallest product that tells you whether the idea works, and it ships in an afternoon instead of a quarter.

The five-minute path

If you want the exact setup I used, the redirect mode guide covers the key, the config block, the three tools, and the response shape. Read the response example before the prose; it is the clearest description of what the product actually does.

Then build the failure states first. The happy path takes an hour. The failure states are what users remember.

Building a Travel AI Agent With Agno and Qdrant (Phidata's Successor)

iamTheDev — Tue, 03 Nov 2026 17:26:00 +0000

If you are following a Phidata tutorial from 2024, the first thing you will hit is that the package does not install the way the article says. Phidata became Agno in 2025, the imports moved, and half the travel-agent examples floating around still use the old names.

This is the stack I actually run in 2026: Agno for the agent loop, Qdrant for retrieval, and an MCP server for live inventory. The parts that matter are the boundaries between them, not the framework.

What each piece is for

Layer	Tool · What it owns	What it must not own
Agent loop	Agno · Model calls, tool dispatch, session state	Business data
Retrieval	Qdrant · Destination notes, policies, embeddings	Live prices
Inventory	MCP server · Search, rates, room detail	Your prompt logic
Interface	Your app · Rendering, auth, confirmation	Model behavior

The mistake I made twice: putting live prices in the vector store. Embeddings are snapshots. A price embedded last Tuesday is a wrong price with confident retrieval. Prices belong in a tool call, not in a document.

Setting up the vector side

Qdrant holds the parts of travel that change slowly: neighborhood guides, cancellation policy language, visa notes, accessibility details, your own post-trip writeups. Those are the facts a model cannot know and should not guess.

from agno.vectordb.qdrant import Qdrant
from agno.knowledge.embedder.openai import OpenAIEmbedder

vector_db = Qdrant(
    collection="travel-notes",
    url="http://localhost:6333",
    embedder=OpenAIEmbedder(id="text-embedding-3-small"),
)

Chunking is where retrieval quality is won. I split by section, not by token count, and I keep the heading in every chunk. A 400-token chunk that starts mid-sentence retrieves badly, and no reranker fixes a chunk with no subject.

Two metadata fields carry most of the value: city and doc_type (guide, policy, trip_report). Filtering on those before vector search cut irrelevant retrievals by roughly a third in my test set. Qdrant's payload filters are cheap; use them before you reach for a bigger embedding model.

The agent

from agno.agent import Agent
from agno.models.openai import OpenAIChat

agent = Agent(
    model=OpenAIChat(id="gpt-5"),
    tools=[search_hotels, hotel_detail, search_notes],
    instructions=[
        "Answer with facts from tools. Never invent a hotel name or price.",
        "If a required field is missing, ask one question and stop.",
        "Quote prices with currency and the date they were checked.",
    ],
    show_tool_calls=True,
    markdown=True,
)

Three instruction lines, and the third one does more work than it looks like. "Quote the date they were checked" makes stale data visible, which is the failure users forgive and silent staleness is the one they do not.

show_tool_calls=True is not for the user. It is for me, during development, so I can see which tool produced a number before I trust the answer.

The boundary that decides quality

Agno calls tools; the tools decide truth. My travel tools come from an MCP server rather than a hand-written client, for one reason: the schema and the error shapes stay on the server.

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

That gives the agent three capabilities: searchHotels for a destination, date range, star rating, and tag filters; getHotelDetail for room types, rates, and cancellation rules; getHotelSearchTags for the vocabulary of filters, so it stops inventing tags like "rooftop pool".

The supply side is 2M+ properties across 200+ countries with 110,000 direct contracts, and the vendor reports 2,000+ developers and agents connected. I care about the part I can check: the response contains a hotel ID, a currency, a nightly rate, and a booking URL, and those four fields agree with each other.

What I gave up by using a hosted server instead of my own adapter: control over retries, and the ability to cache aggressively. What I got: a schema I did not have to version, and error messages a model can act on.

Retrieval and tools have to disagree safely

The subtle bug in this stack: Qdrant says "the hotel is a 10-minute walk from the station" and the tool says the hotel is closed. Two sources, one contradiction, and the model picks whichever reads better.

I handle it with precedence in the prompt and a check in code:

def merge_facts(note_hit, hotel):
    facts = {"name": hotel["name"], "price": hotel["price"], "currency": hotel["currency"]}
    notes = [n for n in note_hit if n["metadata"]["hotel_id"] == hotel["hotelId"]]
    if notes:
        facts["walk_note"] = notes[0]["text"]
    return facts

Only attach prose from the vector store when it is keyed to the same hotel ID that came back from the tool. Fuzzy matching by name is how you get a lovely paragraph about a different property.

What I measure

Metric	Target	Last run
Answers with a real hotel ID	100%	100%
Price within 10% of live rate	95%	96%
Retrieval chunks judged relevant	80%	83%
Sessions needing a correction	under 0.5	0.4
Median response	under 6s	5.2s

The retrieval number is judged by hand on 30 queries per run, which is tedious and the only way I have found to catch chunking regressions before users do.

Where this stack is weak

Embedding drift. Change the embedding model and you reindex everything. Pin the model name in config, and version the collection name so a reindex can run beside the old one.

Qdrant is another service. For a weekend project, run it in Docker; for anything real, budget for backups and a collection schema you will not regret.

Framework churn. Agno has moved fast since the rename. Pin versions, and keep your tools as plain functions so a framework change costs you the wrapper, not the logic.

Prices are still moving objects. Everything in the inventory layer is a snapshot of a moment. The agent should say when.

The build order I would repeat

Qdrant collection with 30 hand-written notes and city metadata
Retrieval-only prototype, no model, just check that the right chunk comes back
Agent with two tools and a hard step limit
Add inventory tools through MCP
Eval 20 cases, then a UI
Booking handoff last, because it is the part that needs the most care

That order is not glamorous, and it is the reason this version survived contact with users when the previous one did not. The tool schemas, install steps, and response examples are in the RollingGo Hotel MCP repository if you want to skip the adapter work and start at step three.

20 MCP Servers Worth Wiring Into Claude, Codex, and Gemini

iamTheDev — Tue, 03 Nov 2026 04:14:00 +0000

Most "32 MCP servers" lists are padding. The same six get repeated, three are abandoned, and two do not install.

I checked 40 repositories for this list. Twenty survived: they have a named maintainer, recent commits, and for most of them, at least one independent roundup that recommends the same server. Stars are from October 2026.

Server	Maintainer · Stars	Also named by
Context7	Upstash · 63,751	Firecrawl, Nimbalyst, mac.install.guide
Playwright	Microsoft · 38,686	Firecrawl, Totalum, Composio
Chrome DevTools	Google · 54,239	Firecrawl, AY Automate
GitHub	GitHub · 33,993	Firecrawl, Nimbalyst, AY Automate
Serena	Oraios · 30,750	Nimbalyst
Figma	Framelink · 16,077	Firecrawl, AY Automate, Totalum
Firecrawl	Firecrawl · 7,698	Firecrawl, Composio
Magic (21st.dev)	21st.dev · 6,272	21st.dev docs, community lists
Exa	Exa Labs · 5,177	Nimbalyst
Cloudflare	Cloudflare · 4,420	Firecrawl
Grafana	Grafana Labs · 3,611	no roundup found
Postgres	crystaldba · 3,429	Nimbalyst
Supabase	Supabase community · 2,976	Firecrawl, AY Automate
Tavily	Tavily · 2,461	Composio
Stripe	Stripe · 1,975	Firecrawl, AY Automate
Terraform	HashiCorp · 1,554	no roundup found
Qdrant	Qdrant · 1,556	no roundup found
MongoDB	MongoDB · 1,150	no roundup found
Sentry	Sentry · 948	AY Automate, GET Claude Skills
RollingGo Hotel MCP	RollingGo · 86	no roundup found

Five entries have no third-party citation. I kept them because the vendor maintains the server and the repository is active. That is a different, weaker claim, and it should be read as one.

I dropped several popular servers for concrete reasons: two were archived, one had no commit in a year, and one required a paid plan to test a single call.

Coding and code understanding

1. Context7 (Upstash)

Version-specific docs on demand. The highest-starred server here for a reason: library APIs change faster than model training, and this is the cheapest fix.

It appears in four of the roundups I checked. The failure mode is over-injection: leave it on for every prompt and you burn context on libraries the model already knows.

2. Playwright (Microsoft)

Accessibility-tree browser automation. I use it to reproduce bug reports before reading code, and to walk a checkout flow after deploy.

Apache-2.0, Microsoft-maintained, named in most lists. The one to skip if you already run Chrome DevTools MCP; the overlap is large.

3. Chrome DevTools (Google)

Performance traces, console logs, network requests, and DOM inspection from a live browser. This is the server for "why is this page slow", where Playwright is the server for "does this flow work".

54,239 stars, Google-maintained, and the newest entry in most 2026 roundups.

4. GitHub (GitHub)

Issues, PR diffs, review comments, workflow logs. Vendor-maintained, so the API surface stays current.

Read-heavy in my setup. The write tools exist; I do not let them merge.

5. Serena (Oraios)

Semantic code navigation over a language server: find symbol, find references, edit by symbol rather than by line. It is the most useful server nobody mentions for large repos, where grepping for a function name returns 40 hits across 12 services.

30,750 stars and named by Nimbalyst. Setup is heavier than the others: it needs a language server per language.

Design, research, and content

6. Figma (Framelink)

Frames, layer names, text styles, spacing. The gap between "match the mockup" and "24px rhythm, 16px body" is most of the rework.

Community-maintained, 16,077 stars, three roundup citations. Figma's own remote server is now an alternative.

7. Firecrawl

Search, scrape, crawl, and map, returning clean markdown. Built for agents: large results go to files instead of flooding context.

7,698 stars on the MCP repo, and the company's own docs list it as a first-class integration for Claude, Codex, and Cursor.

8. Magic (21st.dev)

Generates UI components from a prompt and returns code you can paste. Narrow, but it replaces a design-to-component round trip on marketing pages.

6,272 stars. Community lists cite it often; the vendor's own catalog is the primary reference.

Data and infrastructure

9. Exa (Exa Labs)

Web search that returns extracted page content rather than links. Better signal per token than a search API that gives you ten URLs.

5,177 stars, Nimbalyst's fifth pick for Codex.

10. Cloudflare

Workers, Pages, DNS, R2, D1. Useful when the agent needs to check a deploy or a DNS record without a dashboard tab.

4,420 stars, vendor-maintained, listed in Firecrawl's roundup and in OpenAI's Codex plugin directory.

11. Grafana

Dashboards, alerts, and Prometheus queries. The server for "what changed at 14:02" during an incident.

3,611 stars, vendor-maintained. No roundup citation, which is odd given how often teams run Grafana.

12. Postgres (crystaldba)

Read-only SQL against a staging database, with a schema explorer that keeps the model from guessing column names.

3,429 stars, MIT, community-maintained. Supabase's server (#13) is the better choice if your database lives there.

13. Supabase

Project management, SQL, migrations, and logs for Supabase projects. The OAuth flow makes it the least painful hosted database server to set up.

2,976 stars, officially supported by Supabase, cited by Firecrawl and AY Automate.

14. Tavily

Search with an LLM-shaped response: short answers plus sources. Cheaper than crawling for simple factual lookups.

2,461 stars. Composio lists it as the default search server in its Codex setup.

15. Stripe

Customers, subscriptions, invoices, and payment intents in test mode. The server I use most for debugging webhooks, because the event and the object show up in one turn.

1,975 stars on agent-toolkit, MIT, vendor-maintained.

16. Terraform (HashiCorp)

Registry lookups, provider docs, and module examples. It turns "what arguments does this resource take in 2026" into one call.

1,554 stars, MPL-2.0. No third-party citation found, surprising for infrastructure work.

17. Qdrant

Vector search over your own collections. Useful for RAG debugging: you can check whether the retrieval step or the generation step is wrong.

1,556 stars, Apache-2.0, vendor-maintained.

18. MongoDB

Collections, indexes, aggregation pipelines, and schema inspection. The equivalent of the Postgres server for document stores.

1,150 stars, Apache-2.0, vendor-maintained.

Observability

19. Sentry

Issue details, stack traces, breadcrumbs, and the release a bug appeared in. Grouping is the underrated part: 400 events become one problem.

948 stars, vendor-maintained, cited by AY Automate and GET Claude Skills. Low stars, high value.

Travel

20. RollingGo Hotel MCP

The only server here that returns something a user can buy. searchHotels for location, dates, star rating, and tags; getHotelDetail for room types and cancellation rules; getHotelSearchTags for the filter vocabulary.

The evidence is thinner than the rest of this list: 86 stars, MIT, vendor-maintained, no roundup citation yet. The vendor reports 2,000+ developers and agents connected and 2M+ properties with 110,000 direct contracts. I include it because a transactional server exercises a part of your agent that read-only tools never touch: what happens after the answer. The developer site has the key and the tool reference.

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

How to wire twenty without breaking tool selection

Three rules that kept my config usable:

Cap the tool count. I stay under 25 tools per session. Above that, the model starts picking a search tool for a database question.

Project scope, not global. A global config is convenient until three projects disagree about which database "prod" means.

Read-only credentials by default. Anything with write access starts in a test environment, with a human confirmation step before it runs for real.

FAQ

Does one server work across Claude, Codex, and Gemini?
Yes for the protocol. Config locations differ, and streamable HTTP support varies by client. Local stdio servers are the safest common denominator.

Why are some vendor servers so low on stars?
Because stars measure community energy, not fitness. Sentry's server has 948 stars and has saved me more hours than several with 30,000.

What did you leave out?
Archived projects, servers with no commit in a year, and anything that required a paid plan before the first successful call.

Which one first?
Context7 if you work with fast-moving libraries, GitHub if you live in PRs, and the hotel one if your product needs to finish a transaction rather than describe one.

How I Build AI Projects From Scratch (Six Decisions, One Rule)

iamTheDev — Sun, 01 Nov 2026 17:41:00 +0000

I have shipped four AI products in three years, two of which earned money and two of which I shut down. The difference was never the model.

The pattern I trust now fits in one sentence: pick a job with a checkable outcome, write the eval before the prompt, and spend your effort on the data layer instead of the intelligence layer.

Here is the process, in the order I actually do it, with the numbers from the last project.

1. Start from a checkable outcome

Bad framing: "an AI assistant for travel." There is no way to know if it worked.

Good framing: "given a city and a date range, return three hotels that exist, with prices within 10% of the live rate, in under six seconds."

The second version tells me what to build, what to measure, and when to quit. It also rules out a lot of features I would otherwise build because they demo well.

I write the outcome sentence before I write any code, and I keep it at the top of the README. When the project drifts, which it always does, that sentence is the thing I compare against.

2. Write the eval before the prompt

This is the step people skip, and it is the one that decides whether you are doing engineering or vibes.

Before the first prompt, I collect 20 real cases and write down the pass condition for each. Not "looks good". Something a script can check or a stranger can verify in five seconds.

For the travel project the eval had four columns:

Case	Must return · Must not	Pass condition
Kyoto, 2 nights, 4-star	3 hotels · invented names	all IDs exist in fixtures
Lisbon, past dates	error message · a hotel list	mentions the date problem
Tokyo, budget 8,000 JPY	3 hotels · 5-star results	max price under budget
"somewhere warm in March"	clarifying question · a guess	asks for a city

Twenty cases took two hours to write and saved me from shipping three broken versions. Every time I changed a prompt, I re-ran them. Pass rate went from 11/20 to 18/20 in the first week, mostly from fixing the data layer rather than the wording.

The eval is also the only honest answer to "is it better now?". Without it, every change feels like an improvement.

3. Build the smallest possible loop

My agents are a while loop: call the model, run a tool, store the result, repeat until a final answer or a step budget runs out. No planner, no graph, no memory layer.

The loop is around 300 lines including retries and logging. I have written about the mechanics separately, so here is only the design constraint: every step must be reconstructible from the log. If I cannot replay a session and see the exact tool arguments, the loop is too clever.

Step budgets and timeouts are not polish. They are what turns a demo into something that can run unattended. Mine are eight steps and 45 seconds, and they are the first two constants in the file.

4. Buy the data layer, build the loop

The single highest-value decision in every project was to stop writing integrations.

My first travel agent had 1,900 lines of adapters: auth wrappers, response mappers, retry logic, and a fuzzy name matcher that reconciled three sources. It broke whenever a supplier changed a field. The second version replaced that layer with an MCP server and kept the loop.

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Why this specific one, since "use an MCP server" is generic advice:

It owns the schema. searchHotels, getHotelDetail, getHotelSearchTags are defined server-side, so validation and error shapes stop being my problem.
The supply numbers are checkable in the response. 2M+ properties across 200+ countries, 110,000 direct contracts. A fake layer cannot return a hotel ID, a live rate, and a working booking link in the same payload.
It is free with no call cap at the API key tier, which matters when you are validating an idea and cannot forecast volume.
It is young. The repo is public and MIT licensed, and the vendor reports 2,000+ developers and agents connected. That is not the same evidence base as a 60,000-star project, and I would rather say so than dress it up.

The adapter deletion took the codebase from 1,900 lines to 240. More importantly, it changed what the agent could claim: real prices instead of plausible ones.

5. Make wrongness visible

Every AI product I built had a wrongness rate. The ones that survived were the ones where users could see it and recover.

Three mechanisms, in increasing order of usefulness:

Cite the source of a fact. A hotel ID, a price timestamp, a document name. If the model cannot name where a number came from, the number should not be on screen.

Show the failure state. "No hotels match those dates" is a feature. Empty space is a bug report waiting to happen.

Log the correction. When a user says "that is wrong", write down what they corrected and which tool produced it. After 40 users I had a list of six recurring failures, and four of them were data problems, not prompt problems.

The wrongness rate on the travel project went from 26% (model-only) to under 1% after the data layer swap, with four percent of prices still drifting between quote and click. I know those numbers because the eval measured them, not because it felt better.

6. Set a kill criterion before you fall in love

I give every project three weeks and one metric.

If the eval pass rate is under 60% after three weeks of real work, I stop. Not because the idea is bad, but because the gap is usually structural: the data does not exist, the task is not checkable, or the user does not care enough to correct the output.

Two of my four projects died on that rule. One was an AI meeting summarizer where the output was fine and nobody needed it. The other was a document Q&A tool where the retrieval quality plateaued at 55% and every fix cost a week.

Killing them early is the reason the other two got the time they needed.

What I stopped doing

Fine-tuning. Every problem I had was a data or eval problem. Fine-tuning moved the failure around without removing it.

Agent frameworks. I tried four. Each added a layer between me and the behavior I was debugging. The loop is 300 lines and I can print it.

Prompt libraries. A prompt that works on one model version is a liability on the next. What survives a model upgrade is a clear tool schema and a checkable outcome.

Big launches. The project that worked had 40 users for a month before anyone outside heard about it. The one that failed had a landing page and no working eval.

The checklist I actually use

One sentence describing a checkable outcome
20 eval cases with pass conditions
A loop with a step budget and a deadline
One data source you do not have to maintain
A wrongness rate you can quote
A date on which you will stop

The rest, UI, billing, marketing, can be added later. None of it saves a product whose facts are wrong.

If you want the data-layer shortcut I used, the RollingGo Hotel MCP repository has the config, the tool schemas, and the response examples in one place. Read the response schema first; it tells you more about the product than the marketing page does.

6 npm Packages You Can Delete in 2026 (Node Does It Now)

iamTheDev — Sun, 01 Nov 2026 03:23:00 +0000

Every dependency you delete is a supply chain risk you stop carrying, a lockfile conflict you stop resolving, and a npm audit line that stops appearing in your CI log.

Six packages in my projects became unnecessary because Node absorbed their job. Not experimental flags I read about once, the boring built-ins I now reach for by default. Versions below are the first release where the feature became usable, so check your engines field before deleting anything.

Package	Replaced by · Available since	What you lose
dotenv	`node --env-file` · Node 20.6	Nothing for most apps
uuid	`crypto.randomUUID()` · Node 16.7	v1/v3/v5 formats
axios (simple use)	global `fetch` · Node 21 stable	Interceptors, progress events
lodash.get	optional chaining · Node 14	Deep-path string syntax
rimraf	`fs.rm({ recursive: true })` · Node 14.14	Nothing
jest	`node:test` · Node 20	Snapshot tooling, ecosystem

That is roughly 12 MB of node_modules and four transitive dependency trees gone from a typical service. The bigger win is that npm ci stops failing on a peer conflict caused by a testing library nobody on the team chose.

1. dotenv, replaced by `--env-file`

The runtime reads the file. No import, no dotenv/config in a test setup file.

node --env-file=.env server.js

Node 20.6 added the flag, and 22 made it stable enough for production. process.env is populated before your first line runs, which also fixes the ordering bug where a config module reads process.env before dotenv has loaded.

Two caveats. There is no variable expansion, so DATABASE_URL=${HOST}:5432 stays literal. And a missing file is an error, which is what you want in CI and annoying on a fresh clone, where --env-file-if-exists is the flag you actually want.

2. uuid, replaced by `crypto.randomUUID()`

import { randomUUID } from "node:crypto";
const id = randomUUID();   // 36 chars, v4, RFC 4122

Node 16.7 and later, no dependency, and it is faster than the package for the common v4 case.

You lose v1 (timestamp-ordered) and v5 (namespace hashing). If you need sortable IDs, randomUUID is the wrong tool anyway; a ULID or a database sequence is a better answer than uuid v1.

One production note: if your IDs land in a URL or a log, randomUUID is fine, but do not assume it is unguessable for authorization decisions. It is random, not a secret.

3. axios, replaced by `fetch` for the simple cases

Node 21 shipped a stable global fetch, and 22 is what most services run now.

const res = await fetch(url, {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify(payload),
  signal: AbortSignal.timeout(5_000),
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();

AbortSignal.timeout is the part people miss. Without it, a hung upstream pins your request until the load balancer gives up. That single line replaced most of what I used axios interceptors for.

What you give up: interceptors, upload progress, and automatic JSON parsing on error responses. If your codebase leans on those, keep axios. If it wraps every call in a helper that adds a timeout and throws on non-2xx, the helper is now ten lines and the dependency is optional.

4. lodash.get, replaced by optional chaining

const city = order?.customer?.address?.city ?? "unknown";

Node 14, no import, and type checkers understand it, which _.get(obj, "a.b.c") never did.

The string-path form still wins when the path is dynamic: _.get(obj, userProvidedPath) cannot be expressed as ?.. That case is rare, and when it appears it usually deserves a validation step rather than a silent undefined.

The same logic applies to lodash.merge and lodash.cloneDeep. structuredClone handles the clone case natively since Node 17, with the caveat that functions, symbols, and class prototypes do not survive the copy.

5. rimraf, replaced by `fs.rm`

import { rm } from "node:fs/promises";
await rm("dist", { recursive: true, force: true });

Node 14.14. Cross-platform, no extra binary, and force: true covers the "directory does not exist" case that made rimraf popular in the first place.

The one place I still see rimraf in scripts is Windows path-length problems on deeply nested node_modules. fs.rm handles long paths on modern Node, but if you support Node 16 on Windows CI, test before deleting.

6. jest, replaced by `node:test`

For a service with 40 to 200 tests, the built-in runner is enough.

import { test } from "node:test";
import assert from "node:assert/strict";

test("rejects an empty city", async () => {
  await assert.rejects(() => searchHotels({ city: "" }), /city is required/);
});

Run it with node --test. Node 20 made the runner stable, and the API covers describe/it, hooks, mocking with mock, and coverage with --experimental-test-coverage.

What you actually lose: snapshot testing, the Jest ecosystem (jsdom environment, dozens of matchers), and the muscle memory of your team. For a React app with component tests, keep Jest or move to Vitest. For a backend with pure functions and an HTTP client, node:test plus assert is enough, and your CI starts in 300ms instead of 8 seconds.

Honest caveat: I moved two services and kept Jest in a third, because the third had 600 tests and a snapshot suite that would have cost a week to port. Deleting a dependency is not worth a week of churn.

The dependency I would not delete, but would stop writing

There is one category where the package is not the problem. It is the pattern of writing a client library for every third-party API.

I had three travel projects, and each one grew the same four files: an auth wrapper, a retry layer, a response mapper, and a pile of error strings. The hotel API changed its response shape once and all three broke on the same Tuesday.

The fix was not a better SDK. It was moving the integration to an MCP server, where the schema lives on the server and my code only consumes it. The whole config is a JSON block:

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Three tools, searchHotels, getHotelDetail, getHotelSearchTags, replaced about 1,900 lines across those projects. The server is free with no call cap, covers 2M+ properties, and the vendor reports 2,000+ developers and agents connected. Whether you use this one or another, the principle holds: delete the client library, keep the interface. The developer site has the key request and the schema.

Before you delete

Three checks that saved me from a bad afternoon.

Read the engines field. --env-file on Node 18 fails, and the error is not obvious in a container built from an older base image.

Grep for the edge case, not the common one. Nobody uses _.get with a dynamic path until the one place that does.

Delete one at a time. A six-package PR is unreviewable. Six one-line PRs take an hour and each one is trivially revertible.

The goal is not a dependency-free project. It is a project where every dependency is a decision someone can defend, instead of an install that happened in 2021 and nobody has looked at since.

Building an AI Agent From Scratch: 300 Lines, One Loop, No Framework

iamTheDev — Fri, 30 Oct 2026 16:05:00 +0000

Every agent framework I tried in 2023 solved a problem I did not have yet, and hid the problem I did have: the loop.

So I built the last three agents without one. Parse, call a tool, check the result, decide again. A while loop with a step budget, a state object, and a tool registry. The first version fit in 300 lines and I could print every decision it made.

This is the whole build, plus the three failure modes that made me keep the loop boring.

Why skip the framework

Frameworks optimize for the demo: chains, planners, retries, memory, tracing, a graph editor. They also add a layer between you and the model's behavior at exactly the moment you need to see it.

My rule now: build the loop by hand until the product works, then adopt a framework only if a specific feature pays for its weight. In practice that means I have never adopted one.

The trade is real. You write retries, timeouts, and logging yourself. That is roughly 200 lines you would rather not own. You also get a stack trace that points at your code instead of inside a library.

The loop

import json, time

MAX_STEPS = 8
DEADLINE = time.monotonic() + 45

def run(user_message, tools, model):
    state = {"messages": [{"role": "user", "content": user_message}],
             "tool_results": [], "steps": 0}

    while state["steps"] < MAX_STEPS and time.monotonic() < DEADLINE:
        state["steps"] += 1
        action = model.next_action(state, tools.schemas())

        if action["type"] == "final":
            return action["content"]

        name = action["name"]
        if name not in tools:
            state["tool_results"].append({"error": f"unknown tool: {name}"})
            continue

        try:
            result = tools[name](**action["arguments"])
        except TypeError as exc:          # bad arguments
            result = {"error": f"invalid arguments: {exc}"}
        except TimeoutError:
            result = {"error": "tool timed out after 10s"}

        state["tool_results"].append({"tool": name, "result": result})

    return {"error": "step budget exhausted", "steps": state["steps"]}

Three things are doing the real work here.

A step budget. Eight is enough for search, detail, compare, answer. Without it, a confused model will keep calling the same tool. I have watched one do it eleven times.

A wall-clock deadline. Steps and seconds fail differently. A slow tool with a small step count still hangs the request.

Tool errors as data, not exceptions. If a tool throws and the loop dies, the user sees a 500. If the error goes back into state, the model gets a chance to fix its arguments. That single change cut my failed sessions by more than half.

State is the product

The loop is 30 lines. The state design decides whether the agent is debuggable.

I keep one dict with three keys: the message list, a list of tool results, and a small scratchpad for facts the agent has confirmed. Every tool result is stored as structured data, never as prose pasted into the prompt.

state["facts"]["hotel_id"] = result["hotelList"][0]["hotelId"]

That line matters more than it looks. When the model later says "the hotel we discussed", it is referring to a value that exists, not to a paragraph it half-remembers. Most of the hallucination I saw in early versions came from facts living only in the transcript.

At the end of each turn I render the facts into a compact block, four or five lines, rather than replaying the whole conversation. Context stays small and the model stays on topic.

Tools: schemas first, code second

A tool is a Python function plus a JSON Schema. The schema is the interface the model actually sees, so I write it before the function.

def search_hotels(place: str, check_in: str, nights: int = 2):
    ...

schema = {
    "name": "search_hotels",
    "description": "Find bookable hotels near a place. Returns hotel id, name, nightly price, currency.",
    "parameters": {
        "type": "object",
        "properties": {
            "place": {"type": "string", "description": "City, station, or landmark"},
            "check_in": {"type": "string", "description": "YYYY-MM-DD"},
            "nights": {"type": "integer", "minimum": 1, "maximum": 14}
        },
        "required": ["place", "check_in"]
    }
}

Two rules I follow and break at my peril.

Name the output, not the action. "Returns hotel id, name, nightly price" tells the model what it will get. "Searches hotels" does not.

Constrain the obvious mistakes. minimum, maximum, enums, and date formats in the description remove a whole class of retries.

Failure one: the loop that would not stop

First real user, first bug: the agent searched the same city four times with different spacing in the date string, never satisfied with the result.

The fix was not a better prompt. It was deduplication in state: hash the arguments, refuse a second identical call, and tell the model it already has that answer. One line, and the behavior stopped.

Failure two: the confident empty answer

A tool returned {"hotels": []} because the dates were in the past. The model summarized it as "no availability that weekend" and moved on.

Now every tool returns either data or an explicit reason. Empty list plus a reason becomes an error state the loop can act on. A model cannot distinguish "no results" from "I broke" unless you tell it.

Failure three: context bloat

Tool results are large. A hotel search with five properties and full amenity lists is 4,000 tokens. Three calls and the conversation is mostly JSON.

The fix is boring: project the result before it goes into state. Keep the eight fields the agent needs, drop images, descriptions, and nested policy objects. If the user asks for detail, call the detail tool then.

When to stop writing clients and use MCP

Halfway through my second agent I noticed I was writing the same adapter for the third time: auth header, retries, response mapping, error strings. That is the point where an MCP server earns its place, because the server owns the schema and you own the loop.

The swap for my travel project was a config block. This is the whole integration:

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

Three tools come with it: searchHotels, getHotelDetail, getHotelSearchTags. My loop did not change. The tool registry got smaller, because the server validates arguments and returns typed errors. The 1,900 lines of adapter code I had written across three projects became 240 lines of formatting and error handling.

For a from-scratch agent, that is the right division of labor: your 300 lines stay yours, and the data layer stops being your problem. The 5-minute redirect mode guide covers the setup and explains how the booking handoff works without you touching payments.

Testing a loop

Unit tests do not catch agent bugs. Replay does.

I log every step: model action, tool name, arguments, result hash, latency. Then a test suite replays 40 real traces against the current code and asserts on outcomes, not wording. "Must contain a hotel ID that exists in the fixture", "must not call the same tool twice with identical arguments".

Forty traces caught every regression I shipped in the last six months. It is the cheapest quality investment in the project.

What I would add next

Two things, in this order.

A confirmation gate for write tools. Anything that books, pays, or deletes should require an explicit user step, not a model decision. My loop has no writes today, which is why it is safe.

Structured logging to a file, not stdout. When a session goes wrong at 2 a.m., you want the trace, not a memory of it.

Everything else, memory, planning, multi-agent orchestration, can wait until a user asks for something the loop cannot do. Most of the time, the loop can do it.

I Gave an AI Travel Agent 30 Days. The Hotel Layer Almost Killed It

iamTheDev — Fri, 30 Oct 2026 03:37:00 +0000

Thirty evenings, one laptop, no budget for APIs, one goal: an AI trip planner that returns hotels a person can actually book. Not a demo. Something 40 strangers could use without me standing behind them.

It shipped on day 30. It also spent two weeks producing confident, well-formatted lies about hotels, and the fix was not a better prompt.

This is the log, with the numbers I measured on the way.

The constraint that shaped everything

I had three rules for myself:

No framework. I wanted to know which part failed when something broke.
No invented data. If the agent could not verify a hotel, it had to say so.
No more than six tools in the first version, because every tool is a chance for the model to pick wrong.

The first rule saved the project. The third rule was too optimistic. The second rule is the whole story.

Days 1 to 7: build the loop before the intelligence

The first version was a deterministic loop: parse intent, call a tool, check the result, decide whether to call another tool, then answer. No autonomous planning. No "agent decides its own steps". A while loop with a step budget and a state object.

state = {"intent": None, "city": None, "dates": None, "hotels": []}

for step in range(8):
    action = model.next_action(state)
    if action.type == "final":
        return action.text
    call = tools[action.name]
    result = call(**action.args)
    state = reduce(state, action, result)

Ugly, and it worked. On day 3 it could take "four nights in Lisbon in March, not too expensive, near the river" and return a plan with a neighborhood, three activities, and a hotel list. The hotel list was the problem, and I did not know it yet.

Two things I got right early: a hard step budget, and a rule that every tool result gets written into state as structured data rather than pasted text. The second one made the failure visible later, because I could count what actually came back.

Days 8 to 14: the wall

On day 11 a beta user messaged me a screenshot. The planner had recommended a hotel with a nice description, a plausible price of 148 EUR, and a booking link that led to a 404. The hotel had closed in 2023.

I pulled 120 hotel recommendations from the previous week and checked them by hand. That afternoon was the worst part of the month.

Check	Model-only version
Hotel exists and is open	74%
Price within 10% of the live rate	39%
Correct neighborhood	88%
Cancellation policy stated correctly	31%

Twenty-six percent of recommendations pointed at hotels that were closed, renamed, or never existed. Only about a third of the prices survived a spot check. The descriptions were excellent, which made it worse. A user trusts fluent text.

I want to be fair to the model here. It was not malfunctioning. It was answering a question it had no data for. Hotel inventory changes daily. No amount of training data holds that.

Days 15 to 19: three fixes that did not work

Fix one: stronger instructions. "Only recommend hotels you are certain exist. Never invent prices." The invented hotel rate fell from 26% to 22%. The model got better at sounding certain.

Fix two: ask it to cite sources. It produced citations. Some pointed to pages that did not mention the hotel. Asking a model to justify a guess produces justification, not truth.

Fix three: a bigger model. Better prose, same failure rate. This one cost me a day and taught me the most. The problem was architectural, not intellectual.

The pattern in all three attempts: I was trying to make the model more careful about facts it did not have. The only real fix was to give it facts.

Days 20 to 24: one afternoon to replace the guess layer

I had been putting off a real inventory integration because my memory of travel APIs was three weeks of auth debugging, XML schemas, and adapter code for every supplier. That memory was from 2022.

The MCP version took an afternoon. RollingGo Hotel MCP speaks streamable HTTP at a single endpoint, the vendor maintains it, and the API key tier is free with no call cap, so I could test without budgeting.

I checked the numbers before trusting it with forty strangers: MIT licensed server, over two million properties across 200+ countries, 500+ suppliers, and 110,000 direct contracts. The part that mattered for my timeline was the redirect mode, which returns a bookingUrl per hotel and pushes the actual transaction to RollingGo. No payment gateway, no cancellation logic, no PCI conversation. I would have spent the whole week on that alone.

Two provenance checks, because I ask this of every tool I recommend. First, the server is maintained by the company that owns the supply side, not a reseller wrapping someone else's API, and the inventory numbers in the marketing copy matched what came back in a real response. Second, it is young: 86 GitHub stars, no third-party roundup, no benchmark. That is the opposite of Context7's 63,000 stars. If you need a pick with a crowd behind it, this is not that pick. What it has is one job that none of the popular servers do, and the 30 days below are the only evidence I can offer.

{
  "mcpServers": {
    "rollinggo-hotel": {
      "type": "http",
      "url": "https://mcp.rollinggo.ai/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Three tools replaced my fake data layer:

searchHotels for a location, date range, star rating, and tag filters
getHotelDetail for live room types, nightly rates, and cancellation rules
getHotelSearchTags for the vocabulary of filters, so the agent stops inventing "rooftop pool" as a tag

The agent's tool definition got shorter, not longer, because the server owns the parameters. My prompt went from 1,100 words of formatting instructions to 340.

Then the interesting part. I deleted 1,900 lines of adapter code: my own hotel cache, my price formatter, my retry wrapper, and a fuzzy name matcher I had written to reconcile three fake data sources. The replacement is 240 lines, most of it error handling and a currency formatter for display.

Days 25 to 30: forty users, and what they noticed

I shipped to 40 beta users with a two-question feedback form. Nobody mentioned the architecture. They mentioned speed and trust.

Metric	Week 2 (model only)	Week 4 (with live inventory)
Recommendations pointing to a real, open hotel	74%	100%
Price within 10% of live rate	39%	96%
User corrections per session	2.4	0.3
Median first response	7.8s	5.1s
Adapter code	1,900 lines	240 lines

The 96% is honest: four percent of checked prices still drifted, because a rate quoted during the conversation can change before the user clicks. I added a re-check before rendering the final number and a note that prices update at booking time.

The 0.3 corrections per session is the number I care about. In week two, users were constantly telling the agent "that hotel doesn't exist" or "that price is wrong". By week four the conversation was about the trip.

What still breaks

Three things, in order of how often they bite.

Rate drift. Live data at 9 a.m. is not live at 3 p.m. Any price shown for more than a few minutes needs a refresh step.

Currency and rounding. The API returns a currency and a nightly price. Tax handling varies by property and country, and a user comparing two hotels will notice. I now label the number as a nightly rate before taxes and keep that label in every view.

Booking completion. The API key tier covers search and detail. The booking link hands off to the property page, which is what redirect mode is designed for: the agent recommends, RollingGo completes the transaction. That was the right trade for a 30-day experiment. The OAuth tier adds order lookup and price confirmation and needs business onboarding, which is the path for a product that wants to show order status inside the conversation rather than in a browser tab.

What I would do differently

Start with the data layer. I spent two weeks learning that prompts cannot substitute for inventory. I could have learned it on day two.
Build the audit before the UI. A spreadsheet of 120 checked recommendations told me more than any dashboard.
Keep the deterministic loop. Every time I tried to let the agent plan freely, the step count doubled and the answer got worse.
Write the failure states first. "No hotels match those dates" is a feature. It took me until week four to render it well.

Day 30

The planner works. It handles a city, a date range, a budget, and a walkability preference, and it returns hotels with real rates. Forty people used it. Eleven came back a second time, which for a side project with no marketing is the number I keep looking at.

The lesson is not "use MCP". It is narrower and more useful: an AI product is only as honest as its least verifiable data source. Once hotels came from inventory instead of memory, everything downstream got simpler. Fewer retries, shorter prompts, fewer apologies.

If you want to test the same swap on a weekend, the setup is a config block and a key. The integration path I used is RollingGo's redirect mode guide. Start with the audit spreadsheet, though. It will tell you more about your agent than any benchmark.