DEV Community: Amaresh Pelleti

Git 3.0: What Actually Breaks (SHA-256, Rust, More)

Amaresh Pelleti — Thu, 24 Sep 2026 12:09:44 +0000

Git 3.0 changes the default hash function, the default reference storage format, the default branch name, and the build toolchain required to compile Git at all. This comes straight from git-scm.com's own BreakingChanges documentation.

New Repositories Default to SHA-256, Not SHA-1

Git 3.0 changes the default hash function for new repositories from SHA-1 to SHA-256. NIST deprecated SHA-1 back in 2011, and Git has supported SHA-256 as an opt-in option since 2018. What's new is that SHA-256 becomes the default.

Existing SHA-1 repositories keep working. This only affects repos created after you upgrade, using git init without an explicit --object-format=sha1 flag. SHA-256 hashes are 64 hex characters instead of 40, so anything parsing commit hashes needs to handle both.

reftable Replaces the Files Backend by Default

New repositories will default to storing references in the reftable format instead of the traditional files-plus-packed-refs layout. This matters most for tools that read .git/refs/ directly instead of using git for-each-ref or similar plumbing.

Rust Becomes Mandatory to Build Git

This is the widest-reaching change. Git has adopted Rust gradually since Git 2.49, with every component staying optional — until now. The rollout has three stages:

Git 2.52 — Rust auto-detected by Meson, disabled by default in the Makefile build
Git 2.55 — both build systems default-enable Rust (already shipped)
Git 3.0 — build options removed, Rust becomes mandatory

Git developer Patrick Steinhardt described the approach to Phoronix as "a test balloon" meant to give the project time to build proper infrastructure and give distributors time to adjust toolchains.

Important: if your CI builds Git from source instead of installing a package, check whether your build image has Rust support before Git 3.0 ships.

Seven Things Git 3.0 Removes Outright

Grafting commits support
git-pack-redundant
Shorthand remote URLs in $GIT_COMMON_DIR/branches/ and /remotes/
The --stdin option on git name-rev
git-whatchanged
core.commentString=auto
core.preferSymlinkRefs=true

safe.bareRepository also changes its default from all to explicit — a real security-relevant change for automation that clones bare repositories.

What to Check Before Git 3.0 Ships

Phoronix reports a target of around end of 2026. Checklist: grep CI configs for the removed commands, confirm build images have Rust if compiling from source, check for direct .git/refs/ reads, and test that hash-parsing tooling handles 64-character hashes.

Quick Summary:

Git 3.0 defaults new repos to SHA-256 instead of SHA-1; existing repos are unaffected
New repos also default to reftable instead of loose-files ref storage
Rust becomes mandatory to build, rolling out across Git 2.52, 2.55, and 3.0
Seven features removed outright, including git-whatchanged and grafting
safe.bareRepository now defaults to explicit instead of all

ECS vs EKS: What Each One Actually Costs You

Amaresh Pelleti — Wed, 23 Sep 2026 10:14:24 +0000

ECS vs EKS comparisons usually stop at "ECS is simpler, EKS is more portable." That's true, but it skips the number that actually shows up on your AWS bill. ECS charges nothing to run the control plane. EKS charges $0.10 per cluster-hour for the first 14 months a Kubernetes version is supported, then $0.60 per cluster-hour once that version moves into extended support — a jump from roughly $73 a month to about $438 a month for a single cluster.

The Control Plane Price Everyone Skips

ECS has no separate control-plane charge. AWS runs the scheduler, API, and task placement logic for free — you only pay for the EC2 or Fargate compute actually running your containers.

EKS is different. Per AWS's own EKS pricing page, every cluster costs $0.10 per hour for standard support, covering a Kubernetes version for 14 months after release. Miss that window, and the same cluster jumps to $0.60 per hour under extended support for up to 12 more months. $0.10/hour is about $73/month. $0.60/hour is about $438/month — a 6x jump for leaving a cluster on an older version.

	ECS	EKS
Control plane	Free	$0.10/hour (standard support)
After 14 months, unpatched	N/A	$0.60/hour (extended support)
Approx. monthly control-plane cost	$0	$73 → $438
Compute	EC2 or Fargate, billed normally	EC2 or Fargate, billed normally

Why the Extended Support Jump Catches Teams Off Guard

It's not hidden — it's right on AWS's pricing page. What catches teams off guard is that it's a per-cluster charge tied to the Kubernetes version, not your application code. A cluster that sits forgotten for a year and a half is exactly the kind of cost that shows up as a surprise line item in a FinOps review.

Where ECS's Simplicity Argument Actually Holds

ECS wins on cost and simplicity when your workload doesn't need Kubernetes-specific tooling. No control plane fee, no version-lifecycle clock, and task definitions are a smaller surface than Kubernetes manifests and CRDs.

That has a limit. ECS's model is AWS-specific. Need to run the same workload elsewhere, or through Helm charts and ArgoCD? None of that transfers.

Where EKS's Cost Actually Pays for Itself

EKS's fee buys the entire Kubernetes ecosystem — the same manifests, Helm charts, and GitOps tooling that work on GKE, AKS, or bare metal. If your team already runs Kubernetes anywhere else, that portability is worth more than $73 a month.

EKS also supports Fargate, same as ECS, so "EKS forces node management" doesn't hold up anymore.

The Actual Decision Criteria

Pick ECS if you're AWS-only with no existing Kubernetes investment. Pick EKS if you need multi-cloud portability, or your team's tooling is already built around Kubernetes primitives.

If you pick EKS, put the version upgrade on a real calendar — cheap to handle on schedule, expensive to ignore.

Quick Summary:

ECS has no control-plane fee; EKS charges $0.10/cluster-hour standard, $0.60/cluster-hour extended support
The extended-support jump (~$73/mo → ~$438/mo) hits clusters running Kubernetes versions older than 14 months
ECS wins on simplicity and cost for AWS-only workloads
EKS's fee buys real portability across any Kubernetes environment
Both support Fargate — "EKS means managing nodes" isn't a real argument anymore

Cursor Pricing: What the Plans Actually Give You

Amaresh Pelleti — Tue, 22 Sep 2026 09:50:00 +0000

Cursor's pricing page lists four plans — Hobby, Pro, Pro+, and Ultra — but only one of them has a real number attached to what you get. Pro costs $20 a month for "extended limits on Agent." Pro+ costs $60 for "3x Pro limits." Ultra costs $200 for "20x Pro limits." Every tier above Hobby is defined as a multiple of Pro, and Pro's actual baseline isn't published anywhere on the page.

That's not a documentation gap. It's the whole pricing model.

What Each Cursor Plan Actually Includes

Plan	Price	What you get
Hobby	Free	Limited Agent requests, access to Composer
Pro	$20/mo	Extended limits on Agent, frontier model access, cloud agents
Pro+	$60/mo	3x Pro's Agent limit, higher Grok Bot usage
Ultra	$200/mo	20x Pro's Agent limit, priority access to new features
Teams	$40–$120/seat	Pooled usage across the team

Cursor's own pricing page describes every tier's allowance in relative terms without ever stating what one unit of usage costs. A reader on justinmckelvey.com summed it up: "Every tier is a multiple of Pro, and Pro is a multiple of nothing you can see."

The Multiplier Pricing Actually Has a Pattern

Compare tiers by dollar-per-unit instead of the marketing copy and something real shows up. Pro+ costs 3x Pro's price for 3x Pro's allowance — same $20 per unit, no discount for spending more. Ultra breaks that pattern: $200 for 20x Pro's allowance works out to $10 per unit, half the per-unit cost of Pro or Pro+.

Ultra is the only tier that actually changes the underlying economics. Pro+ just buys more of the same rate.

Cursor Router Changed What "Auto" Actually Bills

Auto mode used to mean a flat rate no matter which model handled your request. That changed July 22, 2026, when Cursor Router replaced Auto's fixed heuristics with a classifier trained on 600,000+ real coding requests, picking a model per request across three modes:

Intelligence — frontier-model quality
Balance — strong quality at lower cost, the default for most people
Cost — cheapest mode clearing a quality bar

Cursor's numbers show Auto Intelligence at roughly 60% lower cost than running frontier models directly, and Balance at about 36% cheaper, with measured cost-per-commit of $6.76 (Intelligence) and $4.63 (Balance).

The catch is billing, not quality. A user on Cursor's forum put it directly: "Auto, to me, used to mean 'cheap flat rate, don't worry which model actually ran behind the scenes.' I emphasized used to because as of today, this no longer holds." Auto Balance can route to an expensive frontier model and bill at its real rate — no separate warning shown.

What Happens When You Hit the Limit

Cursor tracks two usage pools: Cursor Models (Grok 4.5–4.7, Composer 2.5) and Other Models (third-party, billed at provider rates). Usage resets monthly and doesn't roll over.

Hit your limit and you get an in-editor notification with two choices: turn on on-demand pay-as-you-go usage, or upgrade tiers. Neither happens automatically. One widely shared example documented a team whose $7,000 annual subscription was consumed in a single day of normal usage.

Important: on-demand usage has no built-in spending cap of its own — check it periodically if you enable it.

Teams, Enterprise, and Legacy Max Mode Pricing

Teams/Enterprise plans using their own API key pay a flat Cursor Token Rate of $0.25 per million tokens. Legacy Max Mode bills at the model's own API rate plus a 20% surcharge. Neither rate appears on the main pricing page — both are buried in the usage-limits docs.

Quick Summary:

Pro ($20), Pro+ ($60, 3x Pro), Ultra ($200, 20x Pro) are priced as multipliers of an unpublished baseline — only Ultra lowers the per-unit cost
Cursor Router (July 22, 2026) replaced fixed Auto-mode routing with per-request classification across Intelligence/Balance/Cost
Auto Balance can bill frontier-model rates with no warning — check your invoice for unexpected model names
Teams/Enterprise with their own key pay $0.25/million tokens; legacy Max Mode is API rate + 20%
Hitting your limit doesn't auto-charge — you choose on-demand usage or an upgrade

Running Ollama in Production: systemd, TLS, and API Auth

Amaresh Pelleti — Mon, 21 Sep 2026 11:13:37 +0000

Ollama production deployment means three things the official docs don't cover: the default systemd unit runs Ollama unsandboxed, the reverse-proxy example in Ollama's own FAQ has no TLS and no auth, and there's no built-in authentication at all — anyone who reaches the port can call the API. None of that is a bug; it's just out of scope for a quickstart. This closes the gap with the actual hardening steps.

This is provider-agnostic — VPS, bare metal, home server, any Linux box.

Hardening the systemd Service Beyond the Default Unit

Ollama's installer creates a dedicated ollama system user instead of running as root, and the default unit looks like this:

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=$PATH"

[Install]
WantedBy=multi-user.target

Reasonable baseline, not hardened. Add these via sudo systemctl edit ollama:

[Service]
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
ReadWritePaths=/usr/share/ollama/.ollama

ProtectSystem=strict makes the filesystem read-only except API filesystems — ReadWritePaths carves out the one directory Ollama needs to write models into, or pulls fail silently. Apply incrementally and check systemctl status ollama after each addition.

Running Ollama in Production Behind Nginx

Ollama's FAQ gives the minimal baseline:

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://localhost:11434;
        proxy_set_header Host localhost:11434;
    }
}

HTTP-only, no access control. Leave OLLAMA_HOST at its loopback default rather than binding to 0.0.0.0 — nginx should be the only thing facing the network.

Adding TLS with Let's Encrypt

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com

certbot rewrites the server block for HTTPS and installs a renewal timer automatically.

The Real Blocker: No Built-In Auth

Every Ollama endpoint answers anyone who reaches the port. Auth has to live in nginx:

location / {
    if ($http_x_api_key != "your-long-random-key-here") {
        return 401;
    }
    proxy_pass http://127.0.0.1:11434;
    proxy_set_header Host localhost:11434;
}

nginx's if is unreliable for anything beyond one simple comparison — fine here, but don't stack more if blocks expecting them to compose. For multiple keys, use auth_request instead.

Logs: journald, Not logrotate

Ollama logs to journald by default — logrotate doesn't apply. journalctl -e -u ollama tails logs; retention is /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M
MaxRetentionSec=1month

Set both — space caps alone let old quiet-period entries linger, age caps alone don't stop a sudden volume spike from filling disk.

Quick Summary:

Default systemd unit isn't sandboxed — add ProtectSystem=strict, PrivateTmp, NoNewPrivileges, ReadWritePaths
Keep OLLAMA_HOST on loopback; nginx faces the network
certbot --nginx handles TLS in two commands
Zero built-in auth — an X-API-Key check in nginx is the minimum fix
Logs go to journald, not a file — set SystemMaxUse and MaxRetentionSec instead of logrotate

Full breakdown at DevToolHub.

The terraform-docs GitHub Action: A Complete CI Setup Guide

Amaresh Pelleti — Fri, 18 Sep 2026 12:06:26 +0000

The terraform-docs GitHub Action generates a Markdown table of every input, output, and variable in a Terraform module, then commits it straight into your README.md on every pull request. The official docs page covers one example and stops there — no full input list, no config-file setup, and nothing about the one failure mode that catches almost everyone the first time they wire this into a real repo.

This covers what the official page skips: every input the action actually supports, the difference between fail-on-diff and auto-commit mode, how to document more than one module at once, and why the auto-commit step silently fails on pull requests from a fork.

What the terraform-docs GitHub Action Actually Sets Up

The action wraps the terraform-docs CLI and runs it inside your workflow instead of on a developer's laptop. On a pull_request trigger, it walks your working-dir, generates the docs, and either prints them, replaces the target file, or injects them between two HTML comment markers in your existing README.md.

That third mode — output-method: inject — is the default, and it's the one worth understanding first. It looks for  and  markers in the file. If they're there, the generated table replaces everything between them and leaves the rest of your README untouched. If the file doesn't have the markers yet, the action appends the generated block to the end. If the file doesn't exist at all, it creates one using the template input, which must itself contain both markers or the next run has nowhere to inject into.

Every terraform-docs GitHub Action Input, Not Just the One in the Docs

The official page's example sets four inputs and calls it done: working-dir, output-file, output-method, git-push. The action's actual README lists 18. Here's the full set:

Input	Default	What it does
`working-dir`	`.`	Comma-separated list of directories to generate docs for
`output-file`	`README.md`	File in the module directory where docs get written
`output-format`	`markdown table`	terraform-docs output format (ignored if `config-file` is set)
`output-method`	`inject`	`print`, `replace`, or `inject`
`config-file`	`disabled`	Name of a terraform-docs config file to use instead of individual inputs
`atlantis-file`	`disabled`	Parse an Atlantis config to find module directories automatically
`find-dir`	`disabled`	Run a `find` under this directory to discover `.tf` files
`recursive`	`false`	Update submodules recursively instead of just `working-dir`
`recursive-path`	`modules`	Submodule path to walk when `recursive` is true
`fail-on-diff`	`false`	Fail the job if generated docs differ from what's committed (ignored if `git-push` is set)
`git-push`	`false`	Commit and push the generated docs back to the branch
`git-commit-message`	`terraform-docs: automated action`	Commit message for the auto-push
`git-push-user-name` / `git-push-user-email`	empty	Defaults to the `github-actions[bot]` identity if left blank
`git-push-sign-off`	`false`	Add a `Signed-off-by` trailer to the commit
`template`	HTML comment markers	Used only when `output-file` doesn't already exist
`indention`	`2`	Markdown heading indent level, 1 through 5
`args`	`""`	Extra flags passed straight through to the `terraform-docs` binary

fail-on-diff is explicitly ignored the moment git-push is set to true. And output-format does nothing once you set config-file, since the config file's own formatter key takes over.

Getting Auto-Commit Working: The checkout Step Most Setups Get Wrong

- uses: actions/checkout@v3
  with:
    ref: ${{ github.event.pull_request.head.ref }}

Without that ref override, actions/checkout defaults to a detached-HEAD merge commit — a synthetic ref GitHub builds to preview the merge. You can commit to it, but the commit goes nowhere real. Set ref to github.event.pull_request.head.ref and checkout lands on the actual PR branch.

name: Generate terraform docs
on:
  - pull_request
jobs:
  docs:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v3
        with:
          ref: ${{ github.event.pull_request.head.ref }}
      - uses: terraform-docs/gh-actions@v1.4.1
        with:
          working-dir: .
          output-file: README.md
          output-method: inject
          git-push: "true"

That permissions: contents: write block isn't in the action's own examples, but you need it — some orgs default GITHUB_TOKEN to read-only, and the push fails before it even reaches the fork-specific problem below.

Why terraform-docs GitHub Action Fails on Forked Pull Requests

GitHub's workflow-syntax docs are explicit: when a workflow runs on a pull_request "from a forked repository," the GITHUB_TOKEN's "permissions are adjusted to change any write permissions to read only" — regardless of your permissions: block. You "can use the permissions key to add and remove read permissions for forked repositories, but typically you can't grant write access."

Your workflow can have contents: write right there in the YAML, git-push set to true, and the checkout ref pointing at the exact right branch — none of it matters on a fork PR. The action generates the docs correctly, then fails on the push step with a 403.

Two real workarounds:

Switch to fail-on-diff for external PRs — you lose auto-commit, but the check still catches stale docs, and a human commits the fix.
Use pull_request_target instead of pull_request. It grants a full read/write token on fork PRs, but runs in the base branch's context — never check out head.ref from an untrusted fork with this event for anything beyond running terraform-docs itself.

fail-on-diff or Auto-Commit: Which Mode Should You Actually Use?

fail-on-diff fails the job if the generated output doesn't match README.md — nothing gets pushed, a human commits the fix. That's the safer default for a public or multi-contributor repo. Auto-commit (git-push: true) fits an internal repo with a small trusted team, where a docs-bot commit is a fair trade for never having a stale README. Since the two are mutually exclusive on the same job, decide per repo.

Documenting Every Module at Once

working-dir as a comma-separated list (working-dir: .,modules/vpc,modules/eks) works when you know every path already. recursive: true walks recursive-path (default modules) and picks up new submodules without touching the workflow file. atlantis-file reuses your existing atlantis.yaml project list. find-dir runs a plain find for .tf files — the least structured option, useful with no fixed module convention yet.

Using a Config File Instead of Piling On Inputs

Past four or five non-default inputs, a .terraform-docs.yml is easier to manage than a wall of with: keys:

formatter: "markdown table"
output:
  file: README.md
  mode: inject
  template: |-
    <!-- BEGIN_TF_DOCS -->
    {{ .Content }}
    <!-- END_TF_DOCS -->
sort:
  enabled: true
  by: name

Set config-file: .terraform-docs.yml on the action, and output-format stops doing anything — the config file's formatter key wins.

Quick Summary:

18 real inputs vs the 1 example shown on the official docs page
fail-on-diff and git-push are mutually exclusive on the same job
Auto-commit needs ref: ${{ github.event.pull_request.head.ref }} on checkout
Forked-repo PRs always get a read-only GITHUB_TOKEN — auto-commit silently fails there
recursive, atlantis-file, find-dir cover three different multi-module layouts

Full breakdown at DevToolHub.

AI Agents Explained: How They Actually Work

Amaresh Pelleti — Thu, 17 Sep 2026 12:01:25 +0000

AI agents explained in one sentence: software where an LLM decides what to do next — which tool to call, with what arguments — based on the result of what it just did, in a loop, instead of following a script you wrote in advance. That loop, and the model's control over it, is the entire difference between an agent and a regular app that happens to call an LLM.

AI Agents Explained: What Makes Something an "Agent"?

Anthropic's own engineering team draws the line clearly. A workflow is a system "where LLMs and tools are orchestrated through predefined code paths." An agent is a system where "LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." In a workflow, your code decides what happens next. In an agent, the model does — which tool to call, whether to call another after seeing the result, and when the task is done.

How Does an AI Agent Actually Call a Tool?

Tool calling is a structured feature, not a prompt trick. You describe each tool as a JSON schema and pass it to the model. Ollama's /api/chat documents the shape: a tools array with type: "function" entries carrying a name, description, and parameters. When the model wants to use one, it returns a tool_calls array with the function name and arguments — your code executes it and sends the real result back as a new message.

What Is the Agent Loop, and Why Does It Need a Stopping Condition?

Observe state, decide an action, execute it, feed the result back as the new state. Left unchecked, that loop has no natural end. Anthropic's guidance is explicit that agent tasks "often terminate upon completion, but it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control." Pick at least one before an agent goes near production traffic.

AI Agents Explained: Where MCP Fits In

Tool-calling JSON solves how a model requests a tool. It doesn't solve how an agent connects to tools it doesn't already know about — that's what MCP standardizes. See which MCP servers are worth connecting and what changed when MCP's auth spec updated before wiring an agent into one.

Why AI Agents Get Stuck in Loops

A common failure isn't a wrong answer — it's the same tool call, same arguments, repeated forever, because "nothing in its setup tells it that repeating an identical call is pointless." Frameworks default to generous iteration caps (LangGraph 25 steps, LangChain 15) that catch this late. A no-progress guard — hash (tool, arguments, result), halt after 2-3 identical repeats — catches it in seconds.

Workflow or Agent?

If the steps are known and fixed, build a workflow: more predictable, easier to debug, lower runaway-cost risk. Reach for an agent when the right sequence genuinely depends on what's discovered along the way. Most real systems mix both rather than making an entire pipeline agentic by default.

Common Mistakes

Vague tool success signals that invite retries. Trusting iteration limits alone to catch stuck loops fast. Skipping the tool-permission question — an agent is only as safe as what its tools can do. Making everything agentic when a fixed workflow would be simpler and cheaper.

Full article with FAQ and quick summary: devtoolhub.com/ai-agents-explained

What Is RAG? Retrieval-Augmented Generation Explained

Amaresh Pelleti — Tue, 15 Sep 2026 10:49:17 +0000

What is RAG, in one sentence? A way to make an LLM answer questions using documents it was never trained on, by searching those documents for relevant passages and handing the model the results as context before it generates a response. No retraining, no fine-tuning — just a search step bolted onto the front of a normal prompt.

The term comes from a 2020 Facebook AI Research paper that described it as combining "pre-trained parametric and non-parametric memory for language generation" — the model's trained knowledge, plus a live lookup into an external index.

What Is RAG?

Retrieval-augmented generation is a pattern, not a specific tool: retrieve relevant information for a query, then generate an answer using that information as context. The original RAG paper, authored by Patrick Lewis and colleagues at Facebook AI Research, paired a pre-trained sequence-to-sequence model with a dense vector index accessed by a pre-trained neural retriever.

RAG exists because LLMs have two hard limits. Their knowledge is frozen at training time, and they don't know your private data at all. Retrieval solves both by pulling relevant text in at request time instead of baking it into the weights.

What Is RAG Actually Doing When It Retrieves Data?

The pipeline runs a fixed sequence for every question:

Chunk your documents into smaller passages
Embed each chunk into a vector using an embedding model
Store the vectors in a vector database
Embed the incoming question the same way
Retrieve the chunks whose vectors are closest to the question
Generate an answer using those chunks as context

Any LLM can handle the generation step. The retrieval half is what makes RAG RAG.

What Is a Vector Database, and Why Does RAG Need One?

A vector database indexes by geometric closeness rather than exact values, so a search for "how do I reset a password" can match "forgot your login credentials" even with almost no word overlap. Ollama's API exposes /api/embed for this: send {"model": "...", "input": "..."}, get back an array of floats per input. nomic-embed-text is a solid local default — Ollama's own listing states it beats OpenAI's text-embedding-ada-002 and text-embedding-3-small on short and long context tasks, at a 274MB download.

Why More Retrieved Chunks Doesn't Mean Better Answers

A 2023 Stanford/Berkeley/Samaya AI study found model performance "is often highest when relevant information occurs at the beginning or end of the input context" and "significantly degrades" when it's buried in the middle — the "lost in the middle" effect. A tighter retrieval step of 3-5 genuinely relevant, well-ranked chunks tends to outperform a looser one with more, worse-ranked results.

RAG vs Fine-Tuning

RAG adds new knowledge without touching the model's weights — good for data that changes. Fine-tuning changes model behavior, tone, or output format by retraining the weights. They solve different problems and plenty of production systems use both.

Common Mistakes

Chunking without testing retrieval quality. Assuming the retriever always finds something relevant (it doesn't stop hallucination, it just changes what gets hallucinated on top of). Skipping re-indexing after data changes. Treating every task as a RAG problem when the answer already lives in the model's training data.

Full article with the FAQ and quick summary: devtoolhub.com/what-is-rag

What Is an LLM? A Working Model for Engineers

Amaresh Pelleti — Mon, 14 Sep 2026 11:46:39 +0000

An LLM is a model that has one job: given the text so far, predict the next token, append it, and repeat. That's it. Everything else — chat interfaces, coding assistants, agents that call tools — is scaffolding built around that one loop running thousands of times per response.

Most explanations either stop at "it's trained on the internet" or jump straight into transformer math you'll never touch. Neither one helps when you're deciding how much VRAM to buy, why a long conversation suddenly gets dumber, or why your token bill doubled overnight. This is the model you actually need.

What is an LLM?

A large language model is a neural network trained to predict the next token in a sequence, repeated over enough text that it picks up grammar, facts, and reasoning patterns as a side effect of getting good at that one task. Hugging Face's own generation docs put it plainly: an LLM "is trained to generate the next word (token) given some initial text (prompt) along with its own generated outputs up to a predefined length or when it reaches an end-of-sequence (EOS) token."

That's the whole mechanism. There's no separate "understanding" step. The model has learned, from its training data, which token is statistically likely to come next given everything before it — and at large enough scale, "statistically likely" starts looking a lot like reasoning.

Size is measured in parameters — the numeric weights the network adjusts during training. A 7B model has about 7 billion of them. More parameters generally means better output, but it also means more memory to hold the weights and more compute per token generated. That trade-off is the entire reason quantized, smaller models exist.

How does an LLM generate text?

One token at a time, in a loop, with no ability to revise what it already wrote. The model looks at every token so far — your prompt plus whatever it has generated in this response. Then it outputs a probability distribution over its entire vocabulary for what comes next.

Then a decoding strategy picks the actual token from that distribution:

Greedy search — always pick the single most likely next token. This is the library's default decoding strategy. Deterministic, and prone to repetitive output.
Sampling — pick randomly from the distribution, weighted by probability, controlled by a temperature parameter. Low temperature (under 0.4) stays close to greedy; high temperature (above 0.8) gets more varied and more prone to nonsense.

That picked token gets appended to the sequence, and the whole thing runs again to pick the next one. This continues until the model emits an end-of-sequence token or hits a length limit you set. There is no lookahead and no backtracking — once a token is chosen, it's part of the context for every token that follows, mistakes included.

This is also why LLMs hallucinate confidently instead of saying "I don't know." The model isn't checking facts; it's continuing a pattern. If the highest-probability continuation of a plausible-sounding sentence is a wrong fact, the model produces the wrong fact with the same fluency as a right one.

What is a token, and why does the context window matter?

A token is the model's actual unit of work — usually a word, part of a word, or a punctuation mark, not a full sentence. "Deployment" might be one token; "unconfigured" often splits into two or three. Everything you feed the model and everything it generates gets converted to and from tokens.

The context window is the maximum number of tokens the model can hold in memory at once — your system prompt, the conversation history, and the response it's generating, all counted together. Run out of room and the oldest tokens get dropped or the request fails outright, depending on how the client handles it.

This is a hard ceiling, not a soft one. A model with a 4,096-token context window doesn't get slower as you approach the limit — it silently loses the beginning of the conversation, or errors out, depending on the client.

Context windows vary by model and by how you run it — Ollama's own docs aren't fully consistent on the default either. Its FAQ quotes a flat "4096 tokens," but the newer context-length docs say the real default scales with GPU VRAM: 4k below 24 GiB, 32k from 24–48 GiB, 256k at 48 GiB and up. Check num_ctx or ollama show <model> rather than assuming — see DevToolHub's Ollama hardware requirements guide for how much RAM and VRAM that adds per model size.

How to measure your LLM's token throughput yourself

Run any local model with the verbose flag:

ollama run llama3.1 --verbose "Explain quicksort in one paragraph"

The output includes a full timing breakdown, including prompt eval rate and eval rate in tokens per second. eval rate is the number that actually determines whether a chat feels instant or sluggish. Ollama's API returns the same data as raw fields on every call — prompt_eval_count, eval_count, prompt_eval_duration, eval_duration, all in nanoseconds — so you can calculate tokens per second yourself with eval_count / eval_duration * 10^9.

Why model size and quantization determine your hardware

A 70B model outperforms a 7B model on complex reasoning, but needs roughly 8x the memory and runs far fewer tokens per second on the same GPU. For narrow tasks — classification, extraction, simple chat — a well-chosen 7B or 12B model often gets you most of the quality at a fraction of the cost.

Quantization shrinks memory footprint by reducing weight precision — from 16-bit down to 4-bit, typically — cutting model size roughly 4x with a modest quality loss. That's why an 8B model tagged Q4_K_M downloads at around 5 GB instead of the 16+ GB its full-precision weights would take.

Common mistakes engineers make with LLMs

Treating a bigger model as always the right call. For narrow tasks, a smaller tuned model often matches a frontier model's accuracy at a fraction of the latency and cost.
Not budgeting for context growth. A tool-calling agent can burn through thousands of tokens before producing one user-facing answer — every tool description and response counts against the same context window as the conversation.
Assuming greedy decoding is always safe. It's deterministic, which helps testing, but makes output more repetitive and prone to looping.
Skipping the auth model on tool-calling setups. An LLM that can call tools is only as safe as what those tools are allowed to do.

Full article with the FAQ and quick summary: devtoolhub.com/what-is-an-llm

The MCP Registry, By the Numbers

Amaresh Pelleti — Fri, 11 Sep 2026 12:08:01 +0000

The official MCP registry is the closest thing the Model Context Protocol has to an app store. So we pulled every entry from its API and counted what's actually in there. The short version: 30,375 servers as of September 10, 2026, but a third of them come from about 50 accounts, 62% were published once and never updated, and the companies that founded MCP have published almost none of their own servers there. The registry changes every hour, so treat these as a snapshot, not a leaderboard.

How big the MCP registry actually is

The registry API returned 99,114 server-and-version records, which collapse to 30,375 unique servers once you keep only the latest version of each. That is roughly 3x what it held in May 2026 (about 9,650 servers), and the curve is still steepening:

Month servers first published	New servers
Sep 2025 (launch)	407
Feb 2026	1,081
Apr 2026	2,387
Jun 2026	3,662
Jul 2026	4,840
Aug 2026	6,265

August 2026 alone added more servers than the registry's entire first five months combined. Whatever "MCP adoption" means, the supply side is not the bottleneck.

Almost nothing ever leaves. Of the 30,375 servers, 98.9% are marked active and 1.1% (332) are deprecated. Zero are visibly deleted. The registry adds; it does not prune.

Who is publishing all these servers

Every server name is a reverse-DNS namespace tied to a verified source — either a GitHub account (io.github.username/server) or a domain the publisher proved they own (com.example/server), per the registry's publishing rules. The split:

67.2% published under an io.github.* namespace — an individual or org GitHub account
32.8% published under a verified domain — companies with com., io., ai., dev. prefixes

Across ~18,200 distinct publishers, the distribution is extremely top-heavy. The top 10 publishers account for 17.7% of every server in the registry. The top 50 account for 24.6%. Meanwhile 16,356 publishers have exactly one server each.

The largest single publisher, io.github.sadri-dridi, has 1,505 servers — about one in every twenty in the registry. They are single-function micro-tools with descriptions like "Acres to hectares, number discarded" and "Absolute value sign, number discarded." The next tier tells a similar story: io.github.Evozim has 375 servers, and 276 registry entries share the exact description "Premium agentic endpoint for [name]-mcp." ai.smithery mirrored 213 servers straight from its own directory, test projects and all.

Some bulk publishers are doing real work — io.github.pipeworx-io (1,321 servers) and io.github.mcp-dir (1,113) are systematically wrapping public APIs with genuine descriptions. But the pattern holds: the raw server count is inflated by a handful of automated publishing operations, not 30,000 hand-built tools.

Remote won: how MCP servers are actually deployed

Every server declares how you connect to it — a remote HTTP endpoint, a local package you install, or both.

Deployment	Share of servers
Remote only (HTTP / SSE)	54.8%
Local only (installable package)	38.9%
Both	4.9%
Neither declared	1.4%

Remote is now the majority, and it's overwhelmingly the current transport: 17,584 remote endpoints use streamable-http versus 1,073 still on the deprecated sse transport.

For the local servers, the package ecosystem breaks down as:

Package registry	Packages
npm	8,673
PyPI	3,684
mcpb (Claude Desktop bundle)	1,158
OCI (container image)	899
NuGet	111
Cargo	48

npm is more than twice PyPI. If you maintain MCP tooling, that's where the users are.

The maintenance problem

Here's the number that should make you cautious about picking a server off the list by its description alone.

62% of servers have exactly one published version. They shipped once and were never revised.
40.8% of servers' latest version is still 1.0.0, 0.1.0, or 0.0.1 — a first release with no iteration behind it.
Median versions per server: 1. The mean is 3.26 only because a few servers have hundreds of releases (the busiest has 1,176).

On freshness, the picture is better than the versioning suggests but still uneven. Grouping every server by when its current version was last updated:

Last updated	Share
Within 30 days	37.9%
31–90 days	25.7%
91–180 days	19.0%
181–365 days	7.7%
No update timestamp	9.8%

Roughly 36% of servers haven't been touched in three months or more (counting the ones with no timestamp). For a protocol whose auth and transport spec changed materially in the 2026-07-28 update, a server last updated in early 2026 is a server that predates the current rules.

What the registry does not tell you

The registry entry for a server records its name, description, version, transport type, the package or remote URL, a link to the source repository, icons, and a website. That is the whole schema.

It records nothing about whether the server is safe to run. There is no field for the authentication method, no security-review status, no check that the remote endpoint is even online, and no install or usage count. Namespace verification proves the publisher controls io.github.their-account — it says nothing about the server behind it.

And 22.9% of servers link no source repository at all. For remote-only servers — the ones you point an agent at over HTTP — that rises to 37%. More than a third of the remote MCP servers in the official registry give you an endpoint and a description, and no code to read.

This matters because "official registry" carries weight it hasn't earned yet. It's official in the sense that the MCP project runs it — not in the sense that anything in it is vetted. The archived reference Postgres server with a read-only bypass is the reminder: a trusted label is not an audit.

The founding vendors have barely shown up

The registry is backed by Anthropic, GitHub, and Microsoft. Their own server counts in it:

Namespace	Servers
`com.microsoft`	16
`io.github.github`	1
`com.stripe`	1
`io.github.awslabs`	1
`com.anthropic`	0
`io.github.modelcontextprotocol`	0

The official reference servers, GitHub's remote MCP server, Anthropic's own tools — most of the servers you'd actually reach for aren't published to the registry their maintainers built. Discovery for the servers that matter still happens through docs and word of mouth, not the registry.

How to actually use the MCP registry

It's a genuinely useful index for one thing: finding out whether a server exists and where its code lives. Beyond that, filter hard.

Start from the namespace. A com. or io. verified-domain namespace means a company staked its domain on it. An io.github. namespace with 1,000+ servers under it is a bulk operation — judge the individual server, not the publisher.
Check the version and the update date, not just the description. 1.0.0, published eight months ago, no repo link — skip it, especially for anything remote.
Follow the repository link before you connect anything. If there isn't one, and it's a remote server, that's a hard stop for production use.
Re-verify auth yourself. The registry won't tell you if a remote server implements the current OAuth 2.1 requirement. You still have to check each one against its own docs.

Frequently Asked Questions

Q: How many MCP servers are in the official registry?
A: 30,375 unique servers as of September 10, 2026, from about 99,000 total version records. It has roughly tripled since May 2026 and is still growing, adding more than 6,000 new servers in August 2026 alone.

Q: Are the servers in the MCP registry vetted or secure?
A: No. The registry verifies that a publisher owns the namespace they publish under (via GitHub OAuth or domain verification), but it stores no security review, no authentication details, and no check that a server works. Treat a listing as "this exists," not "this is safe."

Q: Is the official MCP registry the biggest one?
A: It's the canonical one, but not the only index. Third-party directories like PulseMCP and Smithery aggregate across sources and report similar or larger totals depending on how they count. Some of the official registry's volume is mirrored from those directories.

Q: Should I publish my MCP server to the registry?
A: Yes, if it's real and maintained — it's free, and it's where automated discovery is heading. Publish under a verified-domain namespace if you can, link the source repository, and keep the version current with the spec. That alone puts you ahead of most of the list.

Q: Why aren't Anthropic's or GitHub's servers in the registry?
A: Unclear. As of this snapshot, com.anthropic has zero entries and io.github.github has one. The founding organizations built the registry but have mostly not populated it with their own servers, so the highest-quality servers are underrepresented.

Quick Summary:

The official MCP registry holds 30,375 servers (99,114 version records) as of 2026-09-10, up ~3x since May 2026, adding 6,000+ per month
67% are published under a personal GitHub namespace; the top 10 publishers account for 17.7% of all servers, one of them with 1,505 single-function micro-tools
55% of servers are remote-only (almost all streamable-http), 39% are local packages (npm leads, then PyPI, then Claude Desktop bundles)
62% have only one version, 41% are still on a 1.0.x/0.x first release, and ~36% haven't been updated in 3+ months
The registry records no auth method, no security review, and no uptime check; 23% of servers (37% of remote-only ones) link no source repository
Anthropic, GitHub, and Microsoft — who back the registry — have published almost none of their own servers to it

The registry is a directory, not a seal of approval. Use it to find servers and their code, then vet each one the way you'd vet any dependency you're about to hand your data to.

Best MCP Servers in 2026: One Pick Per Category

Amaresh Pelleti — Thu, 10 Sep 2026 12:14:14 +0000

The best MCP servers in 2026 aren't just the ones with the most GitHub stars. With the 2026-07-28 spec update — final and current since late July — making OAuth 2.1 mandatory for every remote MCP server, "best" now also means "still working under the final spec." Here's one solid pick per category, what it actually does, and where it stands on auth.

This is for anyone deploying MCP servers for a team, not just testing one locally. If you're only running servers on your own machine for personal use, the OAuth requirement mostly doesn't touch you — skip to the core utilities section below.

What Makes the Best MCP Servers in 2026

Three things separate a server worth deploying from one that'll cause you problems in six months:

Who maintains it — official vendor support beats an abandoned community fork
How it's deployed — local/stdio servers never needed OAuth; remote/HTTP servers now do
Whether it's actually been tested against real attacks — not every "official" label means safe, as you'll see below

Best MCP Servers by Category

Category	Server	Maintainer	Transport	OAuth Status
Core utilities	Filesystem, Git, Fetch, Memory	MCP steering group	Local (stdio)	Not applicable
Dev/code	GitHub MCP Server	GitHub (official)	Remote (also local)	OAuth 2.1 + PKCE, GA since Sept 2025
Payments	Stripe MCP Server	Stripe (official)	Remote hosted (local stdio also available)	OAuth by default; docs still cite the pre-2026 MCP auth spec
Observability	Sentry MCP Server	Sentry (official)	Remote (hosted on Cloudflare; local stdio available)	OAuth via your Sentry org login
Docs/productivity	Notion MCP Server	Notion (official)	Remote hosted (official local server exists)	OAuth on hosted; token-based on local
Databases	Postgres (community forks)	Community (official version archived)	Local (stdio)	Not applicable, but read the warning below

Core Utilities: No OAuth Needed Here

The official reference servers — Filesystem, Fetch, Git, Memory, Sequential Thinking, and Time — are maintained directly by the MCP steering group. They run locally over stdio. That means they never talk to the network in the first place. The 2026-07-28 auth overhaul doesn't touch them, because the OAuth requirement applies to remote transports only.

If your agent just needs to read local files, search git history, or fetch a URL, these cover it. No auth setup required. That's also their limit — nothing here is shareable across a team the way a hosted server is.

Remote Servers with OAuth Already Built In

Three vendors got ahead of the auth shift instead of scrambling after the spec finalized — with one caveat worth knowing on compliance claims.

GitHub shipped its remote MCP server to general availability in September 2025. It's the only one of the three that explicitly documents OAuth 2.1 with PKCE, across VS Code, Visual Studio, JetBrains, Eclipse, Xcode, and Cursor. Short-lived, auto-refreshing credentials replace long-lived personal access tokens — exactly the direction the final spec pushes every server toward.

Stripe runs its primary MCP server as a hosted endpoint at mcp.stripe.com, with OAuth as the default and restricted API keys available for autonomous agents that need a narrower blast radius than a full secret key. A local stdio option also exists (@stripe/mcp on npm, still actively updated) for anyone who'd rather keep keys off a hosted flow. One honest caveat: Stripe's docs still reference the pre-2026 MCP authorization spec, so verify its 2026-07-28 alignment yourself before treating it as fully compliant with the new requirements.

Sentry took the hosted-first path, running its server on Cloudflare's Workers platform with OAuth tied to your existing Sentry organization login. Sentry's own writeup is blunt about why hosted comes first: the local install workflow — cloning repos, managing config paths — has "a lot of sharp edges." A local stdio mode still exists for those who want it.

Notion's hosted MCP server is OAuth-based and the path Notion recommends. An official local stdio server (notion-mcp-server) authenticated with an internal integration token still exists too, though Notion has flagged it may be sunset — build new integrations against the hosted endpoint.

[IMAGE: articles/images/2026-07-25-best-mcp-servers-by-category-diagram.png | alt: "local vs remote MCP servers and which ones need OAuth 2.1"]

The Postgres Warning: Official Doesn't Mean Safe

Here's the one every other "best MCP servers" list skips. Anthropic's own reference Postgres server shipped a read-only mode meant to block writes. It didn't. Datadog Security Labs' case study documents the SQL injection in detail: the server happily accepted a semicolon-delimited COMMIT; DROP SCHEMA public CASCADE; — breaking straight out of its own read-only transaction. Worth being precise about the timeline: the server was archived in May 2025 as part of a bulk sweep of unmaintained reference servers, and the security disclosure landed after — on a server that was already abandoned. Nobody was watching it either way.

The lesson isn't "avoid database MCP servers." It's that a vendor's name on a server doesn't guarantee its safety claims hold up. If you're running a Postgres MCP server today, use a community fork with real query parsing and permission attenuation. Confirm it's still maintained before you trust it with production credentials — the same instinct you'd bring to any runtime security tooling that promises to enforce a boundary it hasn't actually tested.

Choosing the Best MCP Servers for Your Stack

Match the deployment model to who's using it, not just what the server does:

Solo use, local machine — stick with core utilities and local stdio servers. No OAuth to configure, nothing exposed to the network.
Shared across a team, low-sensitivity data — remote servers like GitHub, Stripe, or Sentry are built for this. All three run OAuth-first; GitHub documents OAuth 2.1 + PKCE explicitly, and for the others, verify current 2026-07-28 spec alignment against their docs before you rely on it.
Sensitive internal data (databases, internal APIs) — self-host, and don't assume "official" means "audited." Check the maintenance history yourself.

If you're building any of this out as part of a Claude-based workflow, Anthropic's developer training track covers MCP server setup directly, alongside Agent Skills.

Frequently Asked Questions

Q: Do I need OAuth for a local MCP server I only run on my own machine?
A: No. The OAuth 2.1 requirement in the 2026-07-28 spec applies to remote/HTTP transports. A local stdio server never exposed itself to the network, so it isn't in scope.

Q: Is the official Anthropic Postgres MCP server still usable?
A: It's archived and unmaintained — it went into Anthropic's archive sweep in May 2025, and a real read-only bypass was disclosed after that. Use one of the actively maintained community forks instead, and verify its query-parsing approach before connecting production credentials.

Q: Which MCP server should a small team deploy first?
A: Start with whichever remote server you already pay for and trust. GitHub, Stripe, and Sentry are all officially maintained and OAuth-first. Each one solves a real, specific problem instead of acting as a general-purpose demo.

Q: Are community MCP servers safe to use in production?
A: Some are. Check who maintains it, when they last updated it, and whether anyone has reviewed it for the same class of bug that took down the official Postgres server. An unaudited read-only claim is not the same as an enforced one.

Quick Summary:

The best MCP servers for most teams split cleanly by transport: core utilities (Filesystem, Git, Fetch, Memory) run locally over stdio and don't need OAuth at all
GitHub's remote MCP server documents OAuth 2.1 + PKCE explicitly; Stripe and Sentry ship OAuth-first hosted servers (Stripe's docs still cite the pre-2026 auth spec — verify before assuming full compliance)
Stripe's hosted endpoint is the primary path, but an official local stdio server (@stripe/mcp) exists too
Anthropic's reference Postgres server — archived as unmaintained in May 2025 — had a read-only mode that failed to block a DROP SCHEMA statement, per Datadog Security Labs
Match server deployment to sensitivity: local for anything internal, remote OAuth servers for shared team tools

Audit which of the best MCP servers your team already runs against this list — the 2026-07-28 spec is final, so any remote server not yet aligned with its OAuth requirements is the one to fix before older clients start failing against it.

MCP Server Authentication: What the 2026-07-28 Spec Broke

Amaresh Pelleti — Thu, 10 Sep 2026 01:31:37 +0000

MCP server authentication stopped being optional a month ago. The Model Context Protocol's largest spec revision since launch finalized on schedule on July 28, 2026 and is now the current protocol version. It turns every remote MCP server into a formal OAuth 2.1 resource server. No more bring-your-own-token. No more skipping auth because your server only talks to internal agents.

That's not the only breaking change. Sessions are gone. The initialize handshake is gone. The Tasks feature moved out of core into an extension. Here's exactly what changed, what you need to fix, and what still has a 12-month grace period.

What Actually Changed in the MCP 2026-07-28 Spec

The release candidate locked on May 21, 2026, giving SDK maintainers a 10-week validation window, and the final spec published on July 28 as planned. Per the official spec blog, this is the biggest rewrite since MCP launched — the protocol moves from bidirectional and stateful to request/response and stateless — and it touches four areas at once:

Transport — protocol-level sessions and the Mcp-Session-Id header are gone from Streamable HTTP
Lifecycle — the initialize/initialized handshake is gone entirely
Tasks — the async task feature graduated from experimental core into an official extension, with a different API
Authorization — MCP servers are now OAuth 2.1 resource servers, full stop

None of this was a soft rollout. Servers on the 2026-07-28 revision won't necessarily work with older clients, and the reverse is also true. If you maintain a public or internal MCP server and haven't audited against the final spec yet, you're already a month behind the clients and SDKs that have.

MCP Server Authentication Becomes Mandatory OAuth 2.1

This is the change with the most real search volume behind it. That makes sense — it touches every server that accepts remote connections. Per the final authorization spec and WorkOS's breakdown, the spec now requires things your server didn't need before:

Protected Resource Metadata (RFC 9728). Your server must expose a .well-known/oauth-protected-resource endpoint. Or it can include resource_metadata in its WWW-Authenticate header instead. Either way, clients can discover your authorization server automatically:

WWW-Authenticate: Bearer resource_metadata="https://api.example.com/.well-known/oauth-protected-resource"

Resource Indicators (RFC 8707). Clients must now name the specific MCP server a token is meant for when they request it. This closes a real gap. Without a resource indicator, a token issued for one MCP server could get replayed against a different one. With it, the authorization server binds the token to a single audience.

Issuer verification (RFC 9207). Authorization servers should include the iss parameter, and clients must validate it whenever it's present — the final spec softened this from the release candidate's mandatory framing, and says a future revision is expected to make inclusion a hard requirement. Either way, if you migrate your MCP server to a different auth provider, existing clients need to re-register. There's no silent handoff.

On top of that, the spec deprecates Dynamic Client Registration (RFC 7591) in favor of Client ID Metadata Documents (CIMD). DCR keeps working for now, but CIMD is the preferred registration path going forward. Clients still registering through DCR must also declare an OpenID Connect application_type — something the old spec never asked for.

This lands three months after security researchers at OX Security disclosed a design flaw in the MCP SDK's STDIO transport that let arbitrary commands execute across more than 7,000 public servers. That RCE was a different transport and a different bug. This spec update doesn't patch it. What it does fix is a gap the STDIO issue never touched: a standard way for a server to confirm a token belongs to it, not to a callback meant for someone else. If you already run runtime security tooling like Falco on Kubernetes to catch anomalous process execution, treat this as the same category of gap, closed at a different layer.

Sessions and the Initialize Handshake Are Gone

If your server tracks state using Mcp-Session-Id, that header no longer exists on Streamable HTTP. Client info that used to travel through the initialize/initialized exchange now rides in _meta on every request instead. Look for fields like io.modelcontextprotocol/protocolVersion, /clientInfo, and /clientCapabilities.

Practically, this means:

Replace any session-based state with a server-issued handle passed back as a regular tool argument
Implement the new server/discover RPC endpoint for capability negotiation
Expect an UnsupportedProtocolVersionError instead of a failed handshake when a client's version doesn't match

This kills sticky-session routing requirements entirely. A stateless MCP server behind a plain load balancer becomes a normal deployment instead of a special case. You no longer need session affinity just to keep a client talking to the same backend instance.

Migrating the Tasks Extension

If your server uses Tasks for long-running operations, the spec replaces the experimental 2025-11-25 API. It removes tasks/list outright. You now drive the lifecycle with tasks/get, tasks/update, and tasks/cancel. Servers can hand back a task handle without a client opting in first.

The same revision introduces a core-protocol pattern (separate from the tasks extension) for anything that used to hold a connection open waiting on the client. Instead of a server-initiated callback, a call returns an InputRequiredResult carrying inputRequests and an opaque requestState. The client gathers what it needs and re-issues the original call with inputResponses and the echoed requestState. All the state lives in the payload instead of an open connection. That means any server instance can process the retry — the same stateless principle driving the session removal. One addition that landed between the release candidate and the final spec supports this: every result now carries a required resultType field, "complete" or "input_required", so clients can tell a finished call from one waiting on input without guessing from the payload's shape.

[IMAGE: articles/images/2026-07-25-mcp-server-authentication-spec-update-diagram.png | alt: "MCP client to authorization server to MCP server auth flow with resource indicators"]

What's Deprecated, Not Removed Yet

Three features get a 12-month minimum deprecation window instead of an immediate cut, under the new lifecycle policy (SEP-2596):

Roots — replaced by tool parameters, resource URIs, or server-side config
Sampling — replaced by direct integration with your LLM provider's API
Logging — replaced by stderr on stdio transports or OpenTelemetry for anything else

You don't have to touch these immediately. But treat the window as a countdown, not a reprieve. The spec's new governance model requires a conformance suite before any feature reaches "Final" status, and these three didn't make the cut.

One smaller change worth knowing: the error code for a missing resource changes too. It moves from the MCP-specific -32002 to the standard JSON-RPC -32602 (Invalid Params). If you have client code branching on the old code, that branch stops firing.

Checklist: Locking Down MCP Server Authentication Against the Final Spec

For most self-hosted or internal MCP servers, authorization hardening matters more than the transport changes. Work through this order:

Confirm your server exposes .well-known/oauth-protected-resource or sets resource_metadata on WWW-Authenticate
Check that your authorization server issues tokens scoped with a resource indicator naming your specific MCP server
Verify iss validation is happening on the client side, not just token signature checks
Audit any code that reads Mcp-Session-Id or relies on the initialize handshake — both need replacing before older clients start failing silently
If you use Tasks, migrate off tasks/list and the 2025-11-25 polling model now, while you can still test against both old and new clients

If you're newer to the protocol itself, the site's Model Context Protocol guide covers the architecture this revision rewrites. And if you're building these servers as part of a broader Claude integration, Anthropic's own developer training track covers MCP alongside Agent Skills.

Frequently Asked Questions

Q: Do I have to rewrite my MCP server now that the spec is final?
A: If your server only talks to clients you control, you have flexibility to upgrade both sides together. If you run a public or third-party-facing MCP server, prioritize the OAuth 2.1 changes now — SDKs built against the final spec are already shipping, and older clients and new servers won't necessarily interoperate.

Q: Does the new spec fix the MCP STDIO RCE from April 2026?
A: No. That vulnerability was in the STDIO transport's command execution model. Anthropic characterized the underlying behavior as expected, not as a bug to patch. The July 28 update hardens OAuth-based authorization for remote transports — a related but separate concern.

Q: What happens if my client still sends Mcp-Session-Id to a 2026-07-28 server?
A: A server built against the new spec won't recognize it. Protocol-level sessions no longer exist on Streamable HTTP. You need to move that state into request payloads or _meta fields instead.

Q: Is Dynamic Client Registration completely removed?
A: No — the spec deprecates it in favor of Client ID Metadata Documents, but DCR support continues for backward compatibility. New integrations should register with CIMD.

Q: Did Roots, Sampling, and Logging stop working when the spec finalized?
A: No. The spec deprecates them with a minimum 12-month window before removal. Existing implementations keep functioning while you migrate to the replacements.

Quick Summary:

The MCP 2026-07-28 spec, final and current since July 28, makes OAuth 2.1 mandatory for remote servers: Protected Resource Metadata (RFC 9728), Resource Indicators (RFC 8707), and RFC 9207 issuer verification (client-side validation required whenever iss is present)
Sessions (Mcp-Session-Id) and the initialize/initialized handshake are removed from Streamable HTTP — client info now travels in _meta on every request
Tasks graduates from experimental core to an official extension; tasks/list is removed in favor of tasks/get and tasks/update
Roots, Sampling, and Logging are deprecated with a 12-month minimum window, not removed outright
Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, though DCR still works

Audit your MCP server's auth flow against the checklist above this week. The spec has been final for a month, SDKs targeting it are already in the wild, and every week of delay widens the gap between your server and the clients calling it.

Ollama Model Library, By the Numbers

Amaresh Pelleti — Sun, 06 Sep 2026 14:21:50 +0000

Someone asks "what's the best Ollama model" in a Discord or a Reddit thread almost every day. The answer usually comes from memory, or a single favorite. So we pulled the actual data instead. Every model in the Ollama model library, its pull count, its capability tags, and when it was last updated. Current as of September 5, 2026 — the library changes weekly, so treat these counts as a snapshot, not a permanent ranking.

What's in the Ollama model library right now

The Ollama model library holds 239 models as of this pull. That spans general chat models, embeddings, vision models, and a growing "cloud" category that runs on Ollama's hosted infrastructure instead of your GPU. Combined, every model in the library has been pulled just over 1.04 billion times.

That total tells you less than it looks like it should. Pulls aren't spread evenly. A handful of general-purpose chat models account for most of it. The long tail of specialized or older models barely registers.

Where Ollama model library pulls actually concentrate

The top 10 models by pull count account for 56.4% of all pulls in the entire library. Meta's Llama family and DeepSeek's reasoning models lead by a wide margin:

Rank	Model	Pulls	Capabilities
1	`llama3.1`	119.2M	tools
2	`deepseek-r1`	92.4M	tools, thinking
3	`nomic-embed-text`	84.6M	embedding
4	`llama3.2`	82.4M	tools
5	`gemma3`	40.1M	vision
6	`qwen2.5`	39.3M	tools
7	`qwen3`	36.3M	tools, thinking
8	`mistral`	33.3M	tools
9	`gemma2`	31.8M	text only
10	`llama3`	25.2M	text only

Here's the thing about that list: it's mostly older releases. llama3.1 and llama3.2 alone outpull every newer Llama version combined. llama3 — several generations behind — still sits at 25.2M pulls. That's because pull counts accumulate over a model's lifetime. An older model with a long track record will always look bigger than a newer one that's objectively better. Don't read this table as "what to use today." Read it as "what people have been defaulting to."

nomic-embed-text at #3 breaks the chat-model pattern. It's a pure embedding model. Its position this high says a lot about how much RAG and semantic-search tooling runs on Ollama underneath the chat interfaces people actually see.

How many Ollama models actually support tool calling

If you're building an agent, this number matters more than pull count. Only 93 of 239 models (38.9%) carry the tools capability tag. The rest either don't support structured tool calling, or Ollama hasn't tagged them for it.

The full capability breakdown across the library:

Tools (function calling): 93 models — 38.9%
Thinking (extended reasoning): 42 models — 17.6%
Vision: 38 models — 15.9%
Cloud (hosted, not local): 18 models — 7.5%
Embedding: 12 models — 5.0%
No special tag (plain text completion): 118 models — 49.4%

These overlap — a model like gemma4 carries vision, tools, thinking, and cloud tags at once. But the practical read is simple. Half the library is plain text completion. If your use case needs tool calling specifically, you're choosing from under 40% of what's listed. Check a model's tags on its library page before you build around it, not after.

Why the Ollama model library carries 7,359 tag variants

Across all 239 models, there are 7,359 individual tags. Each one is a different quantization, parameter size, or context configuration of the same base model. That averages out to roughly 30.8 variants per model, though it's lopsided — llama3.1 alone carries 93 tags, while a narrow embedding model might have 3.

This ties into the same issue covered in the Ollama vs LM Studio comparison. Ollama's model names default to a specific quantization, usually Q4_K_M, a 4-bit quant, without making that choice obvious on the model card. With 30+ tagged variants per model on average, "the model" isn't one thing — it's a family. The tag you don't specify is a decision Ollama makes for you. If you're benchmarking against another tool, pin the exact tag (ollama pull llama3.1:8b-instruct-q8_0, for example) instead of the bare model name.

How much of the Ollama model library is still maintained

Freshness in the library skews old. Of the 239 models:

174 (72.8%) were last updated over a year ago
51 (21.3%) were updated sometime this year
9 (3.8%) were updated this month
5 (2.1%) were updated this week

Nearly three-quarters of the library hasn't been touched in over a year. That's not automatically a red flag. A model's weights don't need updates the way a CLI tool does, and a good 2024 model is often still a good model. But it does mean the library is mostly an archive with a small, actively-tended front section. If a model card shows no update in over a year, and a same-family successor has recent activity, the successor is usually the safer default.

What this means if you're picking a model to run

Two practical takeaways come out of this data. First, pull count is a popularity signal, not a quality signal. It rewards models that have been available the longest. That's why year-old Llama releases still outrank newer, often better models. Cross-check pull count against a model's actual release date before treating it as a recommendation.

Second, the capability tags are the fastest filter for narrowing 239 models down to the ones that fit your use case. Building an agent? Filter to the 93 tools-tagged models first. Need a local embedding model for RAG? nomic-embed-text and mxbai-embed-large are the two with real usage behind them. For everything else — running the model once you've picked it — the hardware requirements guide and the Ollama API guide cover the setup.

Frequently Asked Questions

Q: How many models are in the Ollama library?
A: 239 models as of September 5, 2026. The Ollama model library is updated regularly, so this number changes — check ollama.com/library directly for the current count.

Q: What is the most popular model in the Ollama library?
A: llama3.1, with 119.2 million pulls, ahead of deepseek-r1 at 92.4 million and nomic-embed-text at 84.6 million. All three are well over a year old, which is typical — pull counts accumulate over time and favor established models.

Q: How many Ollama models support function calling?
A: 93 of 239 models (38.9%) carry the tools capability tag, which indicates support for structured function calling. Check the individual model's page on ollama.com to confirm before building an agent around it.

Q: Why does Ollama have so many tags for one model?
A: Each tag is a different quantization, parameter size, or configuration of the same base model. The library averages about 30.8 tags per model, and the untagged default usually points to a 4-bit quantization rather than the highest-quality version available.

Quick Summary:
– 239 models in the Ollama model library as of September 5, 2026, with 1.04 billion cumulative pulls.
– The top 10 models account for 56.4% of all pulls — usage concentrates hard in a handful of established releases.
– Only 38.9% of models carry the tools (function-calling) tag; 49.4% have no special capability tag at all.
– The library averages 30.8 tag variants per model, so the untagged default is a quantization choice you're making without realizing it.
– 72.8% of models haven't been updated in over a year — the library is mostly an archive with a small active front section.

If you've picked a model from this list and need to know whether your hardware can run it, the Ollama hardware requirements guide breaks down RAM and VRAM by model size. And if local hardware runs out before your model does, the Ollama Cloud pricing and limits guide covers the hosted tier.