DEV Community: Prajwal Hallale

Your HAR file is a bug report. Turn one request into a cURL that runs

Prajwal Hallale — Wed, 04 Nov 2026 09:48:06 +0000

A screenshot of a failed request tells the next person almost nothing. A HAR capture tells them everything except which of the four hundred entries matters and how to replay it.

There are two ways this handoff goes wrong: a message that says "it returns 500, here is a picture", and a 12 MB archive with no note attached. The second version gets fixed faster, but only if the person receiving it can turn the archive back into a command. That conversion is mechanical, and the mechanical part breaks in ways that look like product bugs.

What a HAR file actually contains

A HAR is JSON. The spec defines log.entries, and each entry holds one request and its response:

log.entries[n].request   method, url, httpVersion, headers[], cookies[],
                         queryString[], postData{ mimeType, text, params[] }
log.entries[n].response  status, statusText, headers[], content{ size,
                         mimeType, text, encoding }, redirectURL
log.entries[n].timings   blocked, dns, connect, send, wait, receive, ssl
log.entries[n].time      total milliseconds

Two things in there are worth more than the rest. request.postData.text is the exact body that was sent, byte for byte, which is usually what a screenshot cannot show. response.content carries the bytes that came back, and when those bytes are not text the entry sets content.encoding to base64 so the archive stays valid JSON.

Capture the small window, not the whole tab

The archive is only as useful as the session you recorded it in, and a browsing session holds your cookies for everything you visited.

Open a fresh window, log in, reproduce the failure once, stop. Then export from the Network panel. In Chrome, since version 130, the export is sanitized by default: Cookie, Set-Cookie and Authorization headers are dropped unless you turn on Settings > Preferences > Network > "Allow to generate HAR with sensitive data" and pick the matching export option. That default is good for your secrets and bad for reproduction, because a request replayed without its auth header returns 401 and the bug report becomes a mystery again. Export the sensitive version on your own machine, then redact the specific values before it leaves your laptop. The steps further down do that part.

Firefox exports the same full log from its own Network panel. Either way, the file includes response bodies, which is the part that matters.

Find the one entry

Do not read the archive. Query it. This prints every entry that failed, with its index, which is the only number you need from here on:

python3 - <<'PY'
import json
har = json.load(open("capture.har"))
for i, e in enumerate(har["log"]["entries"]):
    if e["response"]["status"] >= 400:
        print(i, e["response"]["status"], e["request"]["method"],
              e["request"]["url"][:110], e["time"], "ms")
PY

If the failing call returned 200 with a wrong body, filter on the URL path instead of the status. Slow calls are the third case, and the wait timing is the one that names them: timings.wait is time to first byte, timings.receive is the rest.

Convert it, with the fields a naive converter forgets

Copying the request as a dictionary loses duplicate headers and picks up fields the client must set itself. This converter drops those and keeps everything else:

import json, shlex, sys

DROP = {"content-length", "transfer-encoding", "connection", "host"}

def to_curl(entry):
    req = entry["request"]
    chunks = [f"-X {req['method'].upper()}", shlex.quote(req["url"])]

    for header in req.get("headers", []):
        name = header["name"]
        if name.startswith(":") or name.lower() in DROP:
            continue
        chunks.append("-H " + shlex.quote(f"{name}: {header['value']}"))

    post = req.get("postData") or {}
    if post.get("text") is not None:
        flag = "--data-binary" if post.get("mimeType", "").startswith("multipart/") else "--data-raw"
        chunks.append(flag + " " + shlex.quote(post["text"]))

    chunks.append("--compressed")
    return "curl " + " \\\n  ".join(chunks)

har = json.load(open(sys.argv[1]))
print(to_curl(har["log"]["entries"][int(sys.argv[2])]))

Run against a POST entry captured from httpbin.org/anything, it prints:

curl -X POST \
  https://httpbin.org/anything \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer sk_test_...' \
  -H 'Accept: application/json' \
  --data-raw '{"order_id": "ord_1042", "refund": true}' \
  --compressed

That command replayed the request and returned the same JSON body, 537 bytes, with the server echoing the exact payload. The four decisions in the script are the ones that turn a broken replay into a working one.

Content-Length is gone. The archive records the length the browser sent, and once you change the body, or the shell rewrites it, the header lies. A server waiting for 99 bytes that never arrive holds the connection until curl gives up (exit 28 over HTTP/1.1), and over HTTP/2 curl aborts the stream (exit 92). Neither error mentions the header that caused it.

Pseudo-headers are gone. Entries from HTTP/2 sites carry :authority, :method, :path and :scheme. They are protocol instructions rather than headers, and curl maps or discards them depending on the target protocol, so a command that behaves locally can behave differently on a colleague's machine. Anything starting with a colon is not a header.

Duplicates survive because headers are a list. Building a dict collapses repeated Accept or Cookie values and silently changes what the server sees.

--compressed is added because browsers send Accept-Encoding and expect a compressed response. Without it the body may arrive as bytes that look like garbage in your terminal.

Redact before you paste it into a ticket

Sanitizing by hand is how tokens end up in issue trackers. Walk the headers and replace values instead:

import json
SECRET = {"authorization", "cookie", "set-cookie", "x-api-key"}
har = json.load(open("capture.har"))
for entry in har["log"]["entries"]:
    for header in entry["request"].get("headers", []) + entry["response"].get("headers", []):
        if header["name"].lower() in SECRET:
            header["value"] = "REDACTED"
json.dump(har, open("capture.redacted.har", "w"), indent=2)

Keep the header names. A maintainer needs to know an Authorization header was present and roughly what shape it had, not its value. Redact query strings too, since analytics and API keys travel there often, and check postData.text for a password or a session token before attaching the file.

When the body is not text

If content.encoding is base64, the response is binary and the text field is an encoded blob. Decode it to a real file rather than reading base64 out loud:

import base64, json
har = json.load(open("capture.har"))
content = har["log"]["entries"][0]["response"]["content"]
if content.get("encoding") == "base64":
    open("payload.bin", "wb").write(base64.b64decode(content["text"]))

The round trip is worth checking once on a known file. Decoding a 482,855 byte PNG back from its base64 text produced an identical hash. For one-off decoding without a terminal, Base64 to file does the same thing in the browser and guesses the MIME type and filename.

Multipart uploads are the other shape worth knowing. The entry still holds postData.text with the full boundary and parts, so the --data-binary branch in the converter reproduces the request as long as you keep the Content-Type header that carries the boundary. Do not strip it.

GraphQL requests are just POSTs

A GraphQL call in a HAR looks like an ordinary POST to /graphql with a JSON body holding query, variables and operationName. Replaying it is the same command. What usually goes wrong is that people read the operationName and hand-write a smaller query, which changes the response. Keep the captured query, including the fields you do not recognise, or the response will differ for a reason that has nothing to do with the bug. If you are composing one from scratch rather than replaying one, GraphQL to cURL builds the POST body for you.

If you would rather not run a script

Convert HAR to cURL takes the archive, or a single entry copied out of it, and prints cURL commands in the browser, which is handy when the archive is already on someone else's machine. For reading the archive itself, JSON formatter collapses a 12 MB file into something you can navigate. Those pages process the input in the browser rather than uploading it, which matters when a redacted capture is still sensitive.

What goes in the report

The archive, redacted. The one-line cURL, replayed on your machine with the status and the response time you got. And one sentence naming what you expected instead. Three items, and the person reading it can reproduce the failure in under a minute without asking you a question.

The archive is not the report. The command is the report. The file is the evidence behind it.

Why 2.675 Rounds to 2.67: A Field Guide to Money Math Bugs

Prajwal Hallale — Sun, 01 Nov 2026 18:27:18 +0000

Open a Python REPL and type three lines:

>>> 0.1 + 0.2
0.30000000000000004
>>> round(2.675, 2)
2.67
>>> round(2.5), round(3.5)
(2, 4)

All three results look wrong. None of them is a bug in Python. Each one follows a rule that is working exactly as designed, and the rules are not the ones most people assume their computer uses. Money is where those assumptions get expensive.

0.1 has no exact binary form

Computers store fractional numbers in base 2, the same way we write integers in base 10. A value like 0.125 is easy in binary: it is 1/8, one bit after the point. A value like 0.1 is not. Its binary expansion repeats forever:

0.0001100110011001100110011001100110011001100110011...

Stop at any finite number of bits and you have an approximation. A Python float keeps 53 bits of precision, so the stored value of 0.1 is the fraction 3602879701896397 / 2**55, which is close to 1/10 but not equal to it. The Python tutorial prints the exact stored value:

>>> from decimal import Decimal
>>> Decimal.from_float(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')

Add two of those approximations and the error surfaces at the 17th digit, which is why the result prints as 0.30000000000000004. JavaScript uses the same IEEE 754 binary64 format and returns the same answer.

This is also why 2.675 rounds down. The literal 2.675 is stored as 2.67499999999999982236431605997495353221893310546875, a number strictly below 2.675. Any rounding rule applied to it will produce 2.67, because that is the correct rounding of the value actually in memory.

Rounding is a policy, and languages disagree

Representation explains the first problem. The second one is that "round" is not a single operation. Python 3 rounds halfway cases to the nearest even integer, a rule called banker's rounding. That is why round(2.5) is 2 and round(3.5) is 4. The language reference states it directly: when two multiples are equally close, the result goes to the even choice.

JavaScript rounds halfway cases toward positive infinity. The MDN documentation notes that this differs from languages that round half away from zero, and the asymmetry shows up on negative numbers:

Math.round(0.5)    // 1
Math.round(-0.5)   // -0
1 / Math.round(-0.5) // -Infinity

Then toFixed adds a third behavior, because it rounds the decimal expansion of the stored binary value. That produces results that look like a different bug entirely:

(2.675).toFixed(2)  // '2.67'
(1.005).toFixed(2)  // '1.00'

None of these engines is wrong. They implement different rounding policies, and each policy is reasonable until the number is a price, a tax line, or an invoice total.

Three failures that reached production

The Vancouver Stock Exchange index, 1982 to 1983

The exchange started an index at 1000 in January 1982 and updated it after every trade. Each update was truncated to three decimal places, and the truncated value was used to compute the next one. With roughly 3,000 updates a day, the truncation compounded into a loss of about 25 points per month. By late November 1983 the published index read 524.811. Correcting the arithmetic over the weekend of November 25 to 28 raised it to 1098.892. The index had been understating the market by more than half for nearly two years, not because of a crash, but because a rounding error was fed back into its own input. Wikipedia has the figures.

The lesson is not "use more decimals". The lesson is that a rounded value must never become the input to the next calculation in a chain.

The Patriot missile battery, 1991

A Patriot battery in Dhahran tracked time in tenths of a second. The value 0.1 was stored in a 24-bit register, chopping the repeating binary expansion and introducing an error of about 0.000000095 seconds per tenth. That error was multiplied by the number of tenths since boot. After roughly 100 hours of uptime the clock was off by about 0.34 seconds, which was enough for the system to miscalculate a Scud's position. The missile was not intercepted, and 28 soldiers died. The GAO report is public, and the numerical walkthrough is widely taught.

The failure mode here is a small bias in one direction, accumulated over a long time. Financial systems have the same shape: a per-transaction rounding bias of one cent is invisible in a test and material after ten million transactions.

Excel 2007 and the number 65,535

In September 2007, users found that =77.1*850 displayed 100000 instead of 65535. Microsoft's own post-mortem confirmed the pattern: many calculations that should have produced 65,535 displayed 100000, while others such as =65535*1 worked. The bug sat at the boundary where the calculated value was converted to the text shown on screen, and it was patched.

This one is about the display layer rather than the calculation. The stored value was correct; the text rendered from it was not, and for a spreadsheet user the number on screen is the number that matters.

What actually holds up

Store money as integers in the smallest unit

Stripe's API makes the rule explicit: the amount field is "a positive integer representing how much to charge in the smallest currency unit" (see the Charge object). 100 means $1.00, and a zero-decimal currency like JPY is already in its smallest unit. Integer arithmetic inside a safe range is exact, which removes representation error from every addition, subtraction, and comparison. JavaScript's safe integer limit is 9,007,199,254,740,991, or about $90 trillion in cents, which is enough for any ordinary ledger.

Use a decimal type when the language has one

Python's decimal module and Java's BigDecimal store decimal digits rather than binary fractions, so 0.1 is exactly 0.1. The catch is that the rounding mode is an argument, not a default you can ignore:

from decimal import Decimal, ROUND_HALF_UP

def money(value: str) -> Decimal:
    return Decimal(value).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

money("2.675")  # Decimal('2.68')

Pass a string, not a float. Decimal(2.675) imports the representation error and gives 2.67499999999999982236431605997495353221893310546875, which rounds back to 2.67. Decimal("2.675") is the decimal you meant.

Pick the rounding mode the domain requires. Tax authorities usually specify half-up or a floor at a particular step. Banks often use half-even. The important part is that the choice is written down and tested, not inherited from whichever language happened to run the code.

Round once, at the boundary

Compute in exact units, and round only when you produce a value a human will see or a system will store as a final amount. Interest accrual, allocation, and tax calculations should run on unrounded values; the invoice line rounds once. If you round at every step, the errors compound in the same way as the Vancouver index.

Allocate the remainder instead of losing it

Splitting 100.00 three ways does not divide evenly. Rounding each share independently gives 33.33 three times, and one cent vanishes. The largest remainder method assigns the leftover units to the first shares:

def split(total_cents: int, parts: int) -> list[int]:
    base, remainder = divmod(total_cents, parts)
    return [base + (1 if i < remainder else 0) for i in range(parts)]

split(10_000, 3)  # [3334, 3333, 3333]

The sum always equals the total, which is the property an accounting system actually checks.

Test the invariants, not just the examples

Two assertions catch most money bugs before they ship:

assert sum(split(10_000, 3)) == 10_000
assert money("2.675") == Decimal("2.68")

The first one is a property: every split sums back to its input. The second one pins the rounding policy in a place where a language upgrade or a refactor will break the build if it changes. Add a case for negative amounts, because refunds and credits are where half-up and half-even diverge most visibly.

The short version

Binary floats cannot represent most decimal fractions exactly. That is arithmetic, not a language defect.
Rounding modes differ between languages and between industries. Choose one, name it, and test it.
Never feed a rounded value into the next calculation. Round at the boundary.
Integers in the smallest unit, or a decimal type, for anything that has to balance.
Split totals with a remainder method so the parts still sum to the whole.

A single cent looks like noise. The same cent, applied a few million times without a rule, is a line item nobody can reconcile.

Your best engineer writes the least code. Standup makes them look useless.

Prajwal Hallale — Sun, 01 Nov 2026 18:25:27 +0000

One person in standup lists nine tickets. Another says they spent the day reading. Six months later, the area the second person owns has no incidents, no midnight pages and no rewrite.

The board rewards the first person. The system rewards the second one. Those are not the same measurement, and the gap explains a lot of bad promotion decisions.

Deletion does not produce a ticket

The visible unit of work is code added. The valuable unit is often code removed: a feature nobody uses, a service that existed for one customer, a dependency that pulled in forty more, a config flag that has been true since 2023.

Deleting all of that shows up as a small diff and a line in the changelog. It also removes a permanent maintenance cost. Nobody puts "deleted 4,000 lines" on a performance review, which is why so few people optimise for it.

The first day is reading, not typing

A senior engineer starts by finding out where the data comes from, who calls the function, what the last three commits touched and whether the bug reports share a cause. That looks like nothing is happening. It is the cheapest way to avoid building the wrong thing quickly.

Juniors are usually told to start coding to show progress. The advice is well meant and expensive. Progress that has to be thrown away is not progress, it is a rehearsal.

The cheapest bug is the feature you refuse

Scope negotiation gets a bad name because it sounds like obstruction. In practice, asking "do we need this at all" is the most valuable review available. A shipped feature costs maintenance, documentation, support, tests and attention for as long as the product exists. A feature that never ships costs one conversation.

The engineer who kills a bad idea in a planning meeting has saved more work than the one who ships it cleanly. Only one of them has something to demo.

Boring choices are a feature

Postgres. A cron job. A single server. A monolith. The senior picks whatever the team can operate at 3am, not whatever looks best in a design doc. Interesting technology is a cost that gets paid by whoever is on call, usually someone who did not choose it.

This is also why the most experienced person in the room is often the least excited about the new framework. They have watched a migration before, and they remember who did the work.

The work with no diff

A lot of senior output never reaches a commit:

Answering the question that stops a junior from building the wrong abstraction.
Reviewing the pull request that would have taken production down.
Writing the paragraph in the README that ends ten future questions.
Fixing the flaky test everyone else retries.
Sitting with the new hire until the codebase stops feeling hostile.

None of that appears in a commit graph. All of it compounds.

How to tell slow from senior

Both look the same in a standup. The difference is what the system looks like afterwards. Drift leaves the mess where it was and adds a bit more. Seniority leaves the system quieter: fewer alerts, fewer surprises at release, fewer places where one person is the only one who understands it.

So ask three questions about the last month: what did you remove, what did you talk the team out of, and who did you unblock? If all three answers are "nothing", it is not seniority you are looking at. It is someone waiting for a ticket.

The obvious counterpoint

None of this excuses missing deadlines. A senior who ships nothing is just expensive, and "I was thinking about architecture" is not a deliverable. Output still matters. The argument is about where the effort lands: less new surface area, more reliability, fewer things that need babysitting later.

The best engineer on your team probably cannot prove what they did last sprint. Look at what stopped breaking.

What is the last thing you deleted at work? The answers usually say more about a team than any velocity chart.

How to compute the real APR on a loan (derivation + 20 lines of Python)

Prajwal Hallale — Sun, 01 Nov 2026 17:48:21 +0000

Two loan offers land in your inbox. Both say 6.5%. One has a $1,200 origination fee and the other has none. The monthly payment on the first is not a cent higher than on the second, because the fee is taken out of the money before it reaches you. Compare the quoted rates and the two offers look identical. On a $20,000 five-year loan, the fee turns 6.5% into a 9.12% APR.

The APR is the number that makes them comparable, and it is just the internal rate of return on the loan's cash flows. This post derives it, implements it, and shows the two places where a quoted rate misleads: front-loaded fees and flat-rate interest.

What the quoted rate actually is

A loan quote gives you a nominal annual rate r and a term of n months. The payment follows the annuity formula:

payment = P * (r/12) / (1 - (1 + r/12)^(-n))

For $20,000 at 6.5% over 60 months that is $391.32 a month, or $23,479.38 in total, of which $3,479.38 is interest. So far so ordinary. The quoted rate prices the principal on the assumption that you receive all of it.

APR is the rate where the cash flows net to zero

Now add a $1,200 origination fee, deducted at closing. You still owe payments on $20,000, but only $18,800 ever hits your account. Economically you borrowed $18,800 and are paying $391.32 a month for 60 months.

The APR is the annualised discount rate that makes the present value of those payments equal the money you actually received:

18,800 = sum(payment / (1 + i)^k)    for k = 1..60
APR = 12 * i

There is no closed-form solution for i, since the equation is a polynomial of degree 60, but there is exactly one positive root: the present value falls monotonically as i rises, and that is all a bisection search needs.

Using 12 * i rather than compounding to (1+i)^12 - 1 is deliberate. US Regulation Z defines APR as a nominal annual rate, so a monthly IRR is multiplied by twelve. Comparing it to an APY from a savings account is apples to oranges: APY compounds and APR does not.

The implementation

def payment(principal: float, annual_rate: float, months: int) -> float:
    """Fixed monthly payment on an amortising loan."""
    r = annual_rate / 12
    if r == 0:
        return principal / months
    return principal * r / (1 - (1 + r) ** -months)


def apr(net_advanced: float, monthly_payment: float, months: int) -> float:
    """Annualised IRR of the loan's cash flows, as a decimal (0.0912 = 9.12%)."""
    lo, hi = 0.0, 3.0                      # 0% .. 300% monthly, plenty of room
    for _ in range(200):                   # 200 halvings is far past float precision
        mid = (lo + hi) / 2
        pv = sum(monthly_payment / (1 + mid) ** k for k in range(1, months + 1))
        if pv > net_advanced:              # rate too low: payments are worth too much
            lo = mid
        else:
            hi = mid
    return ((lo + hi) / 2) * 12

Two details matter in that function. Bisection rather than Newton, because pv(i) is smooth and strictly decreasing, so the search cannot diverge; a hundred iterations is already overkill and two hundred costs microseconds. And net_advanced is the money you can spend, not the face value. Fees deducted at closing shrink it, and that is the whole mechanism by which APR exceeds the quoted rate.

The worked example

payment(20_000, 0.065, 60)                  -> 391.32
apr(20_000, 391.32, 60)                     -> 0.0650   (6.50%)
apr(18_800, 391.32, 60)                     -> 0.0912   (9.12%)

The same $1,200 fee, at the same rate, priced against different terms:

Term	Payment	APR, no fee	APR, $1,200 fee	APR, $2,400 fee
36 mo	$612.98	6.50%	10.72%	15.33%
48 mo	$474.30	6.50%	9.72%	13.24%
60 mo	$391.32	6.50%	9.12%	11.98%
72 mo	$336.20	6.50%	8.71%	11.13%

Two things show up in that table. A fee hurts more on a short loan, because it is spread over fewer dollars of interest, so the effective price per borrowed dollar rises. At 36 months the same $1,200 fee is worth 4.2 percentage points of APR; at 72 months it is worth 2.2. That is why "no fee, slightly higher rate" is usually the better trade on a short term and often the worse one on a long term.

The other is that APR measures price, not the bill. The 72-month loan has the lowest APR of the fee-paying rows and the highest total interest ($4,206 versus $3,479 at 60 months). APR answers how expensive each dollar-year of borrowing is, not how much you will pay in total. You need both numbers: APR to compare offers, total cost to decide whether to borrow at all.

Trap two: the flat rate

Some lenders, car finance and personal loans especially, quote a flat rate: interest is charged on the original principal for the whole term, and the monthly payment is (principal + principal * rate * years) / months.

6.5% flat on $20,000 over 60 months
interest = 20,000 * 0.065 * 5      = $6,500
payment  = 26,500 / 60             = $441.67
apr(20_000, 441.67, 60)            = 11.68%

The same "6.5%" is nearly twice as expensive as a 6.5% reducing-balance loan, because flat-rate interest ignores that the balance falls every month. Add the $1,200 fee and the APR reaches 14.43%. Any quote expressed as a flat rate has to be converted before it can be compared with anything, and the conversion is the same twenty lines above.

What APR leaves out

APR is a good comparator with a narrow definition. It does not include:

Late fees and penalty rates, which are contingent and therefore outside the finance charge.
Optional products such as payment protection, gap insurance and extended warranties, unless they are required to get the loan.
Rate resets on variable loans. The APR of an adjustable-rate mortgage is computed from the initial rate and an assumed schedule; it is not a prediction.
Prepayment. The calculation assumes you hold the loan to maturity. Pay it off early and the fee is spread over a shorter period, which raises the effective cost above the quoted APR.

It also varies by jurisdiction. Reg Z in the US, the APRC under the EU Consumer Credit Directive and the UK's APR all use slightly different fee baskets and rounding rules. The core identity, net proceeds equal the present value of payments, is the same everywhere.

Checking a real quote

To run a quote through this without writing code, the APR calculator on Finance Calc Kit takes the loan amount, rate, term and fees and prints the APR together with the formula and each step of the cash-flow table; the EMI calculator gives the payment and amortisation schedule. Both run client-side, so the numbers stay in the browser, and neither asks for an account. I build Finance Calc Kit, and the code above is the same maths the calculator runs, so you can check it against your own numbers.

The rule I use on any loan offer: compare APR first, because it is the only figure that prices fees; compare total payments second, because a lower APR over a longer term can still cost more; then go back to the fee list and ask which fees you can negotiate away. Every dollar removed from the fee moves the APR down more than a dollar of rate does.

If you want to check the implementation against your own loan, the function is short enough to paste into a REPL. If the APR a lender quotes you disagrees with the one it returns, ask which fees they left out of the finance charge.

Before you install that MCP server, check these six things

Prajwal Hallale — Tue, 20 Oct 2026 09:24:02 +0000

MCP made it easy to give an agent real tools. It also made it easy to hand a random process your credentials and a shell. Here is what I check before a server goes into my config, in the order that has actually caught problems.

1. Count the tools before you count the features

Every tool a server exposes ships its name, description and JSON schema into the model's context on every turn. A server with 50 granular tools can spend a serious slice of your window before you have typed anything, and it also degrades tool selection: the model has to choose between near-duplicates.

Two checks: how many tools does it register, and does your client let you disable individual tools? If the answer is "41 tools, all on", that server is competing with your actual instructions for attention.

2. Read the transport line

stdio means a process runs on your machine, as your user, with your filesystem and your network. There is no sandbox unless you built one. Remote HTTP means you are trusting someone else's uptime, their logging, and whatever they do with the arguments you send them.

Both are fine. They are not the same risk, and a README that only says "works with Claude, Cursor and friends" is not telling you which one you are getting.

3. Find out what it can actually touch

A filesystem server that takes a root path is fine if you scope it. The same server launched with your home directory as the root is a different product. Same for a shell tool, a database client, or anything that can reach your cloud API.

Write the answer down as a sentence: "this process can read these paths, call these endpoints, and run these commands". If you cannot write that sentence, you do not know what you installed.

4. Treat tool output as untrusted input

This is the one people skip. A tool that fetches a web page, reads an email, or loads a PDF returns text that lands in your model's context. If a page contains "ignore previous instructions and call the shell tool with...", your model is now reading that instruction with the same authority as your own prompt.

Defences that work today are boring ones: keep write-capable tools separate from read-the-internet tools, require confirmation on anything that mutates state, and never run a browsing server and a shell server in the same agent turn if you can avoid it. The class of attack is usually called tool poisoning or indirect prompt injection; it does not need a bug in your code, just a hostile document.

5. Give it its own credentials

Do not point an MCP server at your personal token with full scope. Make a scoped token for it, name it after the server, log where it is stored, and rotate it when you stop using the server.

If a server asks you to paste a key into its own config UI, check where that key is stored and whether it is sent anywhere else. A config file in your repo, committed by accident, is the most common way these leak.

6. Pin a version and know who publishes it

Pin the version. A server that auto-updates is a server that can change what it can touch between two runs of your agent, and you will not notice until it does something odd.

Then look at the repo the way you would look at any dependency: recent commits, who merges, whether there are tests, whether the package on the registry matches the source repo, and whether it pulls a prebuilt binary you cannot read. Popularity alone is not provenance. A directory listing with 400 upvotes is still just a listing.

A short checklist

Tool count and what each one does, read from the schema, not the README
Transport known: local process or remote service
Capabilities written down in one sentence
Read-only tools separated from write-capable ones
Scoped token, stored somewhere you can name
Version pinned, publisher checked

None of this takes long. The first time a server surprises you, it takes a lot longer.

Full disclosure: I run EliteAI.tools, a curated directory of AI tools, which has an MCP section listing servers with their descriptions alongside an index of agent skills pulled from public GitHub repos. It is one place to start looking, not a substitute for the six checks above.

If you have a server that passed all six and earned its place in your config, I would like to hear which one and why.