MCP servers, agents, and the rest of the AI build stack — with the trade-offs, not just the pitch.
49 tools across 8 categories, each with what it actually does, who it suits, and the constraint you will hit. No affiliate links, no sponsored placements, no ranking — every entry carries a stated limitation, because a directory that only lists upsides is an advert.
Model Context Protocol servers expose a system — files, a database, an API, a browser — to any MCP-compatible client through one standard interface, so you wire an integration once instead of once per assistant.
MCP Reference Servers
Anthropic · Server collection
Open source
The MCP reference server collection provides maintained implementations — filesystem, fetch, memory, git, sequential thinking — that serve as both working connectors and the canonical example of how to write an MCP server correctly.
This is the repository to read before writing your own server. The implementations are deliberately small and show the protocol's shape: tool declaration, argument schemas, structured results and error handling. Most teams start by running one of these, then fork the closest match.
Best for
Learning the protocol from working code rather than the spec
Giving an agent scoped local filesystem or git access
A reference implementation to copy when writing an internal server
Trade-off
Reference servers are written to be readable, not hardened. Treat authentication, rate limiting and path escaping as your job before anything touches production data.
The GitHub MCP Server lets an agent read and act on repositories, issues, pull requests, code search and Actions through GitHub's own maintained connector.
Vendor-maintained, which matters more than it sounds: GitHub's API surface moves, and a first-party server tracks it. It turns 'review this PR' or 'find where this function is called across the org' into a single tool call instead of a shell script wrapping the REST API.
Best for
Agents that triage issues, review pull requests or watch CI
Code search across repositories an agent has not cloned
Replacing bespoke GitHub API glue in an internal agent
Trade-off
The token you hand it defines the blast radius. A broadly scoped personal access token gives an agent write access to everything you can touch — scope per-repository, and prefer a GitHub App over a PAT for anything shared.
Playwright MCP drives a real browser from an agent using the accessibility tree rather than screenshots, so the model reads page structure as text instead of guessing at pixels.
The accessibility-tree approach is the important design decision. Vision-based browser agents burn tokens on screenshots and misidentify elements; a structured tree gives the model named, addressable controls. Practical for end-to-end test authoring, scraping behind a login, and any workflow that only exists as a web UI.
Best for
Automating a workflow that has no API
Generating and maintaining end-to-end tests
Agents that need to verify their own changes in a running app
Trade-off
A browser session is stateful and slow relative to an API call, and any page an agent visits can inject instructions into the tree. Never point it at untrusted pages while it holds credentials or write tools.
A PostgreSQL MCP server exposes schema inspection and read-only SQL to an agent, letting it answer data questions by writing queries instead of being fed exports.
The pattern that makes this work is schema-first: the agent reads table and column definitions, then writes SQL against them. That is far more reliable than dumping rows into context, and it scales to databases far larger than any context window.
Best for
Natural-language reporting over an existing database
Letting an agent investigate a data question during debugging
Internal analytics assistants that must not mutate data
Trade-off
Read-only is a configuration choice, not a guarantee — enforce it with a dedicated database role, not with a prompt. Also expect expensive queries: an agent has no instinct for what will table-scan a billion rows.
The Sentry MCP Server pulls production errors, stack traces and issue context into an agent's working set so a fix can be written against the real failure rather than a pasted snippet.
Closes the loop between 'something broke in production' and 'here is the patch'. The agent reads the issue, the stack trace and the surrounding events, then works in the repository with that context already loaded.
Best for
Agent-assisted triage of production incidents
Turning a recurring error into a pull request
Enriching a bug report with real trace data before human review
Trade-off
Stack traces and event payloads routinely contain customer data. Scrub before the agent sees it, or you have quietly extended your data-processing boundary to a model provider.
A Slack MCP server gives an agent read and post access to channels and threads, which is how most internal assistants end up reaching the humans they work for.
Two distinct uses: reading — mining channel history for decisions and context that never made it into a document — and writing — posting summaries, alerts and requests for approval where people already are.
Best for
Standup, incident and release summaries posted automatically
Human-in-the-loop approvals inside an existing channel
Answering questions from decisions buried in channel history
Trade-off
Channel history is untrusted input. Anyone who can post in a channel an agent reads can attempt to steer it, so keep read scopes narrow and never let channel text authorize a privileged action.
The Fetch MCP server retrieves a URL and converts it to clean markdown, giving a model readable page content instead of raw HTML it would waste most of its context parsing.
The smallest useful MCP server and a good first one to run. HTML-to-markdown conversion typically cuts token count by an order of magnitude while improving comprehension, because navigation chrome and inline scripts never reach the model.
Best for
Letting an agent read documentation pages on demand
Lightweight research steps inside a larger workflow
Cheap page ingestion where a full browser is overkill
Trade-off
It cannot render JavaScript, so single-page apps come back nearly empty — reach for a browser-based server there. And fetched pages are untrusted text: content from a URL must never be treated as instruction.
The Memory MCP server stores facts as a local knowledge graph of entities and relations, giving an agent recall that survives past the end of a conversation.
A deliberately simple persistence layer: the agent writes entities, relations and observations, then queries them on later runs. Useful as the reference model for what agent memory means before committing to a heavier managed offering.
Best for
Assistants that must remember user preferences between sessions
Prototyping a memory design before building a real store
Long-running agents that accumulate project knowledge
Trade-off
It is a local file-backed graph with no multi-user isolation, access control or retention policy. Fine for one developer or a prototype; not a system of record.
The libraries that own the request → tool call → result → repeat cycle. The real choice is how much of the loop you want to write yourself versus inherit, and how much you are willing to be locked into one vendor's abstractions.
Claude Agent SDK
Anthropic · Agent SDK
Open source
The Claude Agent SDK packages the Claude Code harness as a library, shipping the agent loop, context management, file and shell tools, subagents, hooks and permissions behind a single query call.
Available for Python and TypeScript. You supply a prompt and options; the SDK supplies the loop and a working toolset — read, write, edit, bash, glob, grep, web search — plus MCP support for anything else. It is a harness, not a hosting platform: you still deploy and run it yourself.
Best for
Coding and filesystem agents that need tools on day one
Automations shaped like a developer task — refactor, migrate, triage
Teams who want Claude Code's behavior under programmatic control
Trade-off
Batteries-included means opinionated. If you need a control flow the harness does not express, you fight it — a plain tool-call loop against the Messages API gives you full control for a modest amount of extra code.
The Tool Runner in the official Anthropic SDKs drives the call-execute-loop cycle over tools you define, removing the boilerplate agent loop without adding a framework.
You write the tool functions; the SDK handles the iteration until the model stops requesting tools. Per-turn hooks give you approval gates, error interception and result modification. Distinct from the Claude Agent SDK — no built-in tools and no sandbox, just the loop.
Best for
Custom-tool agents where you own every tool
Adding human approval gates on specific tool calls
Avoiding a framework dependency for a small agent
Trade-off
It gives you the loop and nothing else — no tracing, no memory, no retries beyond the SDK's own. For anything long-running you will assemble the surrounding infrastructure yourself.
LangGraph models an agent as an explicit state graph of nodes and edges, making control flow, checkpointing and human-in-the-loop interrupts first-class rather than emergent.
The graph is the point. Where a plain loop leaves control flow implicit in prompt text, LangGraph makes it inspectable code: you can see every path, resume from a checkpoint, and pause for human approval at a named node. That structure is what makes cyclical, long-running workflows debuggable.
Best for
Multi-step workflows with branching and retry logic
Long-running agents that must survive a restart
Approval steps that pause execution for a human decision
Trade-off
Real conceptual overhead. For a single agent with five tools the graph abstraction costs more than it returns — it pays off when the control flow is genuinely complex, and not before.
The OpenAI Agents SDK is a deliberately small framework built on agents, handoffs between them, guardrails and built-in tracing.
The primitive set is intentionally minimal — agent, handoff, guardrail, session — which keeps it readable in a way larger frameworks are not. Tracing is built in rather than bolted on, so you can see a run's structure without adding an observability vendor first.
Best for
Multi-agent designs where work is handed between specialists
Teams already standardized on OpenAI models
Small agents where framework weight is the main risk
Trade-off
Designed around OpenAI's own API shape. Other providers are reachable, but the ergonomics and newest features track OpenAI first — a real consideration if provider independence matters to you.
Pydantic AI brings typed, validated model outputs to agent building, treating an LLM response as a schema-checked Python object rather than a string to parse and hope about.
Built by the Pydantic team, so validation is the core rather than an add-on: you declare the result type, and the framework enforces it, retrying on validation failure. Model-agnostic, with dependency injection for testability.
Best for
Python services where the model output feeds typed downstream code
Structured extraction that must validate before it is used
Teams that already build on Pydantic and FastAPI
Trade-off
Python only, and validation retries cost tokens and latency. If your output is genuinely free-form prose, the type machinery is overhead you do not need.
The Vercel AI SDK is the default TypeScript toolkit for streaming model responses into a UI, with one provider-agnostic interface and first-class React hooks.
It solves the part most teams underestimate: streaming tokens, tool calls and structured objects into a browser without writing transport plumbing. Provider switching is a one-line change, which makes it the pragmatic choice for full-stack TypeScript products.
Best for
Chat and copilot interfaces in Next.js or React
Streaming structured objects, not just text, to the client
Products that must keep the option to change model provider
Trade-off
Weighted toward the frontend. For a headless backend pipeline with no UI, a provider's own server SDK is a more direct fit, and the newest provider features land there first.
CrewAI organizes multiple agents as a crew with assigned roles, goals and delegation, which makes multi-agent designs quick to express and quick to demonstrate.
The role metaphor — researcher, writer, reviewer — is genuinely productive for getting a multi-agent prototype running in an afternoon. Sequential and hierarchical process models cover most collaboration shapes without hand-wiring message passing.
Best for
Prototyping a multi-agent workflow quickly
Research-then-synthesise pipelines with distinct stages
Demonstrating a multi-agent concept to non-engineers
Trade-off
Role-play framing hides cost and control flow. Multi-agent crews multiply token spend fast, and before reaching for one, check whether a single agent with better tools solves the same problem — it usually does.
Mastra is a TypeScript agent framework bundling workflows, agent memory, RAG and evals in one opinionated stack rather than leaving them to be assembled.
Aimed at TypeScript teams who want LangGraph-style durable workflows without leaving the Node ecosystem. Durable workflow steps, typed tool definitions and built-in evaluation reduce the number of separate libraries a project has to hold together.
Best for
TypeScript backends that need durable agent workflows
Teams avoiding a Python service purely for agent code
Projects that want memory and evals without extra vendors
Trade-off
Younger and smaller than the Python-side alternatives, so the ecosystem, integrations and hiring pool are thinner. Weigh that against the cost of running a second language in your stack.
Which AI tool should my engineers write code with?
Coding Agents & IDE Tools6
Agents that read, write and run code in a real repository. They differ less in model quality than in how they manage context, how much autonomy they take, and whether they run in a terminal, an editor, or CI.
Claude Code
Anthropic · Coding agent
Proprietary
Claude Code is a terminal-native coding agent that reads a repository, plans a change, edits files, runs commands and iterates on the output — available in the CLI, desktop and web apps, and as IDE extensions.
The terminal-first design is a real architectural choice: the agent works where the build, tests and git already live, so verification is a command away rather than a plugin API away. Extensible through MCP servers, skills, hooks and subagents.
Best for
Multi-file refactors and migrations across a large repository
Work that must be verified by running tests, not by inspection
Automating repository chores in CI as well as interactively
Trade-off
An agent with shell access is exactly as dangerous as the permissions you grant it. Run it against version-controlled code with a considered permission mode — the convenience of skipping approvals is how unreviewed changes reach a branch.
Cursor is a VS Code-derived editor with codebase-wide indexing, multi-file agent edits and inline completion built into the editing surface rather than added beside it.
Because it forks the editor rather than extending it, the AI features reach further than a plugin can — repository-wide semantic index, agent edits applied as reviewable diffs, and rules files that constrain behavior per project. The migration cost from VS Code is close to zero.
Best for
Developers who want AI assistance inside their normal editing flow
Reviewing agent changes as diffs before accepting them
Teams standardizing conventions through per-repo rules files
Trade-off
You adopt an editor, not a feature — extension compatibility and update cadence are now someone else's decision. Codebase indexing also means source is processed off-machine unless you configure otherwise.
GitHub Copilot provides inline completion, chat and agent modes across major IDEs, with pull-request review and enterprise policy controls wired into GitHub itself.
The enterprise default, and usually for procurement reasons rather than capability ones: it is already inside the GitHub agreement, the admin controls exist, and IP indemnification is on the table. Broad IDE coverage means it fits teams that have not standardized on one editor.
Best for
Large organizations that need central policy and audit
Mixed-editor teams needing one tool everywhere
Buyers who need indemnification and compliance answers
Trade-off
Breadth over depth. On long autonomous multi-file work, dedicated agents typically go further before needing a human — Copilot's strength is consistent assistance across a whole organization, not maximum autonomy.
Aider is an open-source terminal coding agent that edits a git repository directly and commits each change, giving every AI edit its own reviewable, revertible commit.
Git integration is the defining feature: because each change lands as a commit, `git diff` and `git revert` are the review and undo mechanism, with no proprietary state to trust. It builds a repository map to work on codebases far larger than a context window, and is model-agnostic.
Best for
Developers who want every AI edit in git history by default
Bringing your own API key with no vendor subscription
Scripted or CI-driven code changes from a terminal
Trade-off
Terminal-only, with no editor integration or GUI. The commit-per-change model also produces noisy history that usually wants squashing before review.
Cline is an open-source VS Code extension that runs an autonomous coding agent inside the editor, asking permission before each file edit and terminal command.
The permission-per-action model is the distinguishing choice: you see and approve each step rather than reviewing a finished result, which is a reasonable trade while learning how far to trust an agent. Bring-your-own-key and MCP support keep it provider-neutral.
Best for
Staying in VS Code without switching to a different editor
Watching each step while calibrating trust in an agent
Open-source tooling with your own model provider and key
Trade-off
Approving every action is slow, and the natural response — enabling auto-approve — removes exactly the safety property you installed it for. Token cost is also directly yours and easy to underestimate.
Continue is an open-source assistant for VS Code and JetBrains that runs against any model — including self-hosted ones — making it the practical route to AI assistance without code leaving your network.
Configuration-driven and model-agnostic by design: point it at a hosted API or a local runtime and the same interface works. For regulated environments, pairing it with a locally served open-weight model is often the only assistant setup that clears review.
Best for
Air-gapped or regulated environments with no external model calls
JetBrains users, who have fewer strong options
Teams needing per-project control over which model is used
Trade-off
Quality tracks the model you point it at — with a small local model the experience is markedly weaker than a frontier-model tool. Configuration is also more hands-on than commercial alternatives.
Specifications and packaging tools that decide what a model sees. Most production AI failures are context failures, not model failures — this is the layer where that gets fixed.
Model Context Protocol (MCP)
Anthropic · Open standard
Open source
The Model Context Protocol is an open standard for connecting AI assistants to tools and data sources, so one server implementation works with every compatible client instead of once per assistant.
MCP defines how servers advertise tools, resources and prompts, and how clients invoke them. Its value is combinatorial: N integrations across M assistants collapses from N×M bespoke connectors to N servers. Adoption across major assistants and IDEs is what turned it into the default integration layer.
Best for
Exposing an internal system to several AI clients at once
Avoiding vendor-specific plugin formats
Standardizing how tools are described across an organization
Trade-off
The standard covers transport and tool description, not authorization policy. Who may call which tool, with whose credentials, and what an untrusted tool result is allowed to influence remain entirely your design problem.
Agent Skills package procedural knowledge — instructions, scripts and reference files — into folders a model loads only when a task actually calls for them, keeping specialized expertise out of the base prompt.
A skill is a directory with a description and instructions, optionally carrying executable scripts and reference documents. The model reads the description, decides relevance, and loads the body on demand. That progressive disclosure is the point: a hundred skills cost almost nothing until one is needed.
Best for
Encoding a house style, review checklist or runbook once
Document generation and other repeatable multi-step procedures
Sharing organisational know-how across a team's agents
Trade-off
Skills load on a description match, so a vague description means the skill never fires and a broad one means it fires constantly. Writing that description well is the actual work, and it needs testing like any other trigger.
llms.txt is a proposed convention for publishing a markdown file at a site's root that gives language models a curated, navigable map of its documentation.
Where robots.txt says what crawlers may access, llms.txt says what a model should read and in what order — an index of the pages that actually matter, in a format that costs few tokens to consume. Adoption among developer-tool documentation sites has been the fastest.
Best for
Documentation sites that want accurate answers about their product
Reducing hallucinated API details in assistant answers
Giving coding agents a reliable entry point into your docs
Trade-off
It is a convention, not a ratified standard, and no model is obliged to read it. Treat it as low-cost insurance that may improve how assistants describe your product, not as a guaranteed channel.
Repomix packs an entire repository into a single AI-friendly file with token counts and configurable ignore rules, so a whole codebase can be handed to a model in one paste.
Solves the mundane problem of getting a codebase into a chat interface that has no repository access. Respects ignore rules, reports token counts before you exceed a limit, and can strip comments to fit more signal into the same window.
Best for
Whole-repository review or architecture questions in a chat UI
Onboarding a model to a small or medium codebase quickly
Producing a reproducible context snapshot for a bug report
Trade-off
It does not scale — beyond a modest repository size no context window is large enough, and packing everything degrades attention besides. Retrieval or an agent that reads files on demand is the right answer above that threshold.
Tree-sitter is an incremental parser that produces a concrete syntax tree for source code, making it the standard way to chunk code along real function and class boundaries instead of arbitrary line counts.
Unglamorous infrastructure under most serious code AI. Naive chunking splits a function in half and retrieval quality collapses; syntax-aware chunking keeps semantic units intact. Grammars exist for essentially every mainstream language, and parsing is fast enough to run on every keystroke.
Best for
Chunking code for retrieval without breaking functions apart
Extracting symbols to build a repository map
Any code-analysis step that regex would get subtly wrong
Trade-off
A low-level library, not a product — you write the traversal code, and each language needs its grammar wired up. Real work, and worth it only when code quality of retrieval genuinely matters.
Vector storage and retrieval. The honest default is the database you already run; a dedicated vector store earns its operational cost only past a scale most teams never reach.
pgvector
PostgreSQL community · Database extension
Open source
pgvector adds vector similarity search to PostgreSQL, letting embeddings live in the database you already run, back up and know how to operate.
The correct default for most teams. Vectors sit beside relational data, so a query can filter by tenant, date and permission in the same statement as the similarity search — a join that separate vector databases make awkward. Supports exact and approximate indexes.
Best for
Any team already running PostgreSQL
Retrieval that must filter by user, tenant or permission
Avoiding a second datastore and its operational burden
Trade-off
At very large scale, dedicated engines outperform it on pure vector workloads and offer richer index tuning. That crossover point is far higher than most teams assume — measure before migrating.
Qdrant is an open-source vector database written in Rust with strong payload filtering, available self-hosted or as a managed cloud service.
Its filtering implementation is the differentiator — combining metadata predicates with vector search without the recall collapse that naive post-filtering causes. Quantization options cut memory substantially, which is what makes large collections affordable.
Best for
Large collections with heavy metadata filtering
Self-hosting with a credible managed option later
Memory-constrained deployments that need quantization
Trade-off
A separate service to deploy, monitor and keep consistent with your primary database. That dual-write problem is real operational work — do not take it on before pgvector has actually failed you.
Weaviate is an open-source vector database with built-in hybrid search, combining keyword and vector scoring in a single query with a schema-first data model.
Hybrid search out of the box matters more than the marketing suggests: pure vector search misses exact identifiers, error codes and product SKUs that keyword search catches trivially. Weaviate can also generate embeddings via configured modules rather than in your application.
Best for
Retrieval where exact terms and semantics both matter
Teams wanting embedding generation inside the database
Structured collections with defined schemas and cross-references
Trade-off
The schema-first, module-driven model has a steeper learning curve than a plain vector store, and module configuration becomes its own thing to maintain and version.
Chroma is an embedding database designed for the fastest possible path from idea to working retrieval, running in-process with no server to start.
The developer-experience choice: a few lines gets you a working collection, with persistence to disk when you want it and a client-server mode when you outgrow embedded use. The right tool for finding out whether retrieval helps at all before investing in infrastructure.
Best for
Prototypes and notebooks where setup time dominates
Local development against a production vector store
Teaching, demos and proofs of concept
Trade-off
Optimized for approachability rather than scale — plan on migrating for a production workload of real size. Treat it as the prototyping step, not the destination.
LlamaIndex is a data framework for connecting private data to language models, covering ingestion, parsing, chunking, indexing and query strategies rather than storage.
Storage is the easy part of RAG; getting messy PDFs, spreadsheets and web pages into clean, well-chunked text is the hard part, and that is what LlamaIndex addresses. It also implements advanced query strategies — reranking, multi-step decomposition, routing — that measurably beat naive top-k retrieval.
Best for
Ingesting varied document formats into a retrieval pipeline
Query strategies beyond simple similarity search
Teams who want RAG patterns implemented rather than invented
Trade-off
Large surface area with many abstractions and a fast-moving API. Skimming the concepts and writing the retrieval loop yourself is often faster than learning the framework, unless you need the advanced strategies.
Pinecone is a fully managed vector database with serverless scaling, chosen by teams who want retrieval infrastructure they never operate.
The trade is explicit: no cluster to size, patch or rebalance, in exchange for a vendor dependency and usage-based cost. For teams without platform engineers, that is frequently the correct economics — an engineer's time spent on vector infrastructure is rarely cheaper.
Best for
Teams with no capacity to run stateful infrastructure
Workloads with spiky or unpredictable query volume
Getting to production quickly without an ops project
Trade-off
Proprietary and managed: your vectors live in someone else's system, cost scales with usage, and migrating away later is a project. Confirm the data-residency answer before storing anything regulated.
Tracing, scoring and regression testing for non-deterministic systems. Without this layer you cannot tell a prompt improvement from a coincidence, and you ship changes on vibes.
Langfuse
Langfuse · LLM observability
Open source
Langfuse is an open-source LLM engineering platform for tracing, prompt management, evaluation and cost tracking, self-hostable so traces never leave your infrastructure.
Self-hosting is the deciding factor for many teams: traces contain prompts and outputs, which routinely include customer data, and shipping that to a third party is a compliance conversation. Framework-agnostic instrumentation and prompt versioning cover the day-to-day needs.
Best for
Regulated environments that cannot send traces off-premises
Debugging why one specific production request went wrong
Tracking token cost per feature, customer or endpoint
Trade-off
Self-hosting means you now operate a trace store, and high-volume tracing produces a lot of data. Sampling and a retention policy are decisions you must make deliberately, not later.
LangSmith provides tracing, dataset management, evaluation and prompt versioning as a managed platform, with the tightest integration into LangChain and LangGraph applications.
Inside the LangChain ecosystem, instrumentation is close to free — set an environment variable and traces appear with the graph structure intact. The dataset and evaluator workflow is mature: capture real production traces, curate them into a test set, and run regressions against every prompt change.
Best for
Applications already built on LangChain or LangGraph
Turning production traces into regression test datasets
Teams that want the platform operated for them
Trade-off
Managed and proprietary; a self-hosted option exists but on enterprise terms. It also works best with LangChain — outside that ecosystem the integration advantage largely disappears.
Braintrust is an evaluation-first platform for AI products, built around running scored experiments against datasets so prompt and model changes can be compared on evidence.
Where most tools start from tracing and add evals, Braintrust starts from evals and adds tracing. The workflow is experiment-shaped: define a dataset, define scorers, run variants, compare. That framing is what stops prompt engineering from being guesswork.
Best for
Comparing prompt or model variants with real numbers
Gating deploys on an eval suite in CI
Teams doing continuous prompt iteration at scale
Trade-off
Only useful if you invest in datasets and scorers — the platform cannot tell you what good looks like. That curation effort is the real cost, and it is larger than the license.
Phoenix is an open-source observability and evaluation tool for LLM and RAG applications, built on OpenTelemetry and runnable locally in a notebook.
Standing on OpenTelemetry matters: traces are portable to any OTel-compatible backend rather than trapped in a vendor schema. Phoenix also ships RAG-specific analysis — retrieval relevance, response groundedness — that generic APM tools do not model.
Best for
Diagnosing why a RAG pipeline retrieves the wrong context
Local trace inspection during development
Teams standardized on OpenTelemetry
Trade-off
Positioned as the open on-ramp to a commercial platform, so the most polished workflows lead toward the paid product. The local experience is genuinely useful on its own, but expect that pull.
The OpenTelemetry semantic conventions for generative AI define standard attribute names for model calls, tokens and tool invocations, so LLM telemetry lands in the observability stack you already run.
The strategically safe choice. Instrument to the convention and traces flow to any OTel backend — your existing APM included — instead of a separate silo owned by one AI-observability vendor. Increasingly emitted natively by SDKs and frameworks.
Best for
Organizations with an existing OpenTelemetry investment
Avoiding lock-in to a single AI-observability vendor
Correlating model latency with the rest of a request trace
Trade-off
A convention, not a product — you get portable attribute names and no UI, evaluators or datasets. It is the foundation under a tool, not a replacement for one.
Promptfoo is a command-line tool for testing prompts and red-teaming LLM applications from a declarative config, designed to run in CI like any other test suite.
Config-driven and local-first: describe test cases and assertions in YAML, run the matrix across prompts and models, get a pass/fail result a build can gate on. The red-teaming side probes for jailbreaks, prompt injection and PII leakage before an attacker does.
Best for
Adding prompt regression tests to an existing CI pipeline
Security testing an LLM feature before release
Comparing models on your own cases rather than public benchmarks
Trade-off
CLI and config-first, so it lacks the production trace exploration a full observability platform gives you. Most teams end up running it alongside one, not instead of one.
How do I route, host and fall back between models?
Gateways & Model Serving6
Proxies that put one interface in front of many providers, and runtimes that serve open-weight models on your own hardware. Both exist to stop a single provider outage from being your outage.
LiteLLM
BerriAI · Gateway
Open source
LiteLLM exposes many model providers behind one consistent interface, as a Python library or a self-hosted proxy with keys, budgets, rate limits and fallbacks.
The proxy mode is what makes it infrastructure rather than a convenience wrapper: one endpoint for every team, per-key budgets and spend tracking, automatic fallback when a provider degrades. Provider changes become a configuration edit rather than a code change.
Best for
Central spend control and rate limiting across many teams
Automatic failover between providers during an outage
Trying a new model without touching application code
Trade-off
A gateway is a new single point of failure on your critical path, and the lowest-common-denominator interface can obscure provider-specific features you actually want. Deploy it with the redundancy any critical service gets.
OpenRouter is a hosted gateway offering hundreds of models from many providers through one API and one bill, with automatic routing around provider failures.
Removes the account-per-provider problem: one key, one invoice, and the ability to try a model you have no contract with in a single line change. Useful for evaluation work where signing procurement agreements per model is the actual bottleneck.
Best for
Evaluating many models without separate vendor accounts
Products that let end users choose their own model
Prototypes that must not be blocked on procurement
Trade-off
Every request routes through a third party, which adds latency and puts your prompts in another processor's path. For regulated data, go direct to the provider or self-host.
vLLM is a high-throughput inference server for open-weight models whose paged attention memory management makes serving concurrent users on your own GPUs practical.
The de facto standard for self-hosted serving at scale. Continuous batching and paged KV-cache management deliver throughput that naive serving cannot approach, and the OpenAI-compatible endpoint means most clients work unchanged.
Best for
Serving open-weight models to many concurrent users
Data-residency requirements that rule out hosted APIs
High-volume workloads where per-token API pricing dominates cost
Trade-off
You are now operating GPU infrastructure: capacity planning, driver versions, model updates and on-call. Below substantial and steady volume, a hosted API is almost always cheaper once staff time is counted honestly.
Ollama runs open-weight models locally with a single command and serves them over a local HTTP API, making a developer laptop a usable model host.
It collapsed local model setup from an afternoon of CUDA and quantization decisions into one command. That matters for offline development, for prototyping against a model with zero marginal cost, and for privacy-sensitive experiments that must never leave the machine.
Best for
Local development without spending on API calls
Privacy-sensitive prototyping on your own hardware
Demos and offline environments with no network access
Trade-off
Optimized for single-user local use, not concurrent production serving — reach for vLLM there. Models that fit a laptop are also markedly weaker than frontier models, so validate quality assumptions before designing around one.
llama.cpp is a C/C++ inference engine that runs quantized open-weight models efficiently on CPUs and consumer hardware, with no GPU required.
The engine underneath much of the local-model ecosystem, including tools that never mention it. Its GGUF quantization formats are what make multi-billion-parameter models fit in consumer memory, and it runs on hardware from servers to phones.
Best for
CPU-only or edge deployments with no GPU available
Embedding inference directly into a native application
Squeezing the largest possible model onto fixed hardware
Trade-off
A low-level engine with a steep learning curve — quantization formats, context settings and build flags are all yours to choose. Most teams should use something built on top of it rather than it directly.
Portkey is an AI gateway combining routing, caching, retries, guardrails and observability behind one endpoint, aimed at teams running models in production across several providers.
Bundles concerns most teams otherwise assemble from three or four tools: semantic caching to cut repeat cost, conditional routing by request attributes, and request-level tracing. A self-hosted deployment option exists for teams that cannot route through a vendor.
Best for
Production traffic across multiple model providers
Cutting cost on repetitive queries via caching
Central governance without building a gateway in-house
Trade-off
Bundling means the individual pieces are less deep than best-of-breed alternatives, and the gateway sits on your critical path. Verify the failure mode when the gateway itself is unavailable.
Input and output filtering: PII redaction, prompt-injection defense, policy enforcement and schema validation. Necessary in any system where untrusted text reaches a model that holds real permissions.
Guardrails AI
Guardrails AI · Validation framework
Open source
Guardrails AI validates model input and output against composable checks — schema conformance, PII, toxicity, competitor mentions — and can re-ask the model when a check fails.
Validation is expressed as reusable validators from a shared hub rather than bespoke regex scattered through application code. The re-ask loop is the useful part: a failed check can trigger a corrective retry rather than surfacing an error to the user.
Best for
Enforcing output schemas before results reach downstream code
Blocking PII or policy-violating content in user-facing replies
Applying consistent validation policy across several features
Trade-off
Every validator adds latency, and re-ask loops multiply cost on exactly the requests that were already failing. Measure the p99, and cap retries.
NeMo Guardrails constrains conversational AI using Colang, a dedicated modeling language for defining permitted dialogue flows and topic boundaries.
Distinct from output filters: rather than checking a finished response, it constrains the conversation's shape — which topics are in scope, which flows are permitted, when to hand off to a human. Suits regulated conversational products where off-topic answers are a compliance issue.
Best for
Customer-facing bots that must stay inside a defined scope
Regulated domains where off-topic advice creates liability
Enforcing consistent escalation and handoff behavior
Trade-off
Colang is another language to learn and maintain, and rail evaluation adds latency to every turn. Justified for regulated conversational products; heavy for a general assistant.
Llama Guard is an open-weight classifier that labels prompts and responses against a configurable safety taxonomy, deployable as a self-hosted filter on both sides of a model call.
Because it is a model rather than a rule set, it generalizes to phrasings a keyword filter misses, and the taxonomy is editable to your own policy categories. Self-hosting means content being screened never leaves your infrastructure — often the reason a moderation API is not an option.
Best for
Screening user input before it reaches an expensive model
Moderation where content cannot be sent to a third party
Custom safety categories a generic API does not cover
Trade-off
A second model on every request adds latency and compute, and classifier accuracy varies by category and language. Measure false positives on your own traffic — over-blocking is a real product cost.
Presidio detects and anonymises personally identifiable information in text and images, letting sensitive fields be redacted or reversibly tokenized before a prompt leaves your systems.
Combines named-entity recognition, regex patterns and checksum validation, with country-specific recognizers for identifiers like national insurance and tax numbers. Anonymisation is pluggable — redact, hash, or reversibly encrypt so a response can be re-identified after the model call.
Best for
Stripping PII before prompts reach a third-party model
Redacting logs and traces that capture prompt content
Meeting data-minimization obligations in a regulated pipeline
Trade-off
Detection is never complete — unusual formats and free-text disclosure slip through, so treat it as risk reduction rather than a compliance guarantee. Custom recognizers for your own identifier formats are usually required.
Four rules that decide more than the tool you pick
Tooling churns every few months. These do not — they are what we keep relearning across client builds, and they are worth more than any individual choice in the list above. Curious what a site already runs on? Try the free website tech stack checker or the free SEO checker.
01
Start with the loop, not the framework
A tool-calling loop against a model API is around fifty lines: send messages, check whether the model asked for a tool, run it, append the result, repeat. Write that first. Adopt a framework only once you can name the thing it solves that your loop cannot — durable state across restarts, a human approval pause, genuinely branching control flow. Framework-first is how teams end up debugging an abstraction instead of their product.
02
Context beats model choice
Most production AI failures are context failures. The model was not given the right information, was given too much of the wrong kind, or was handed a document chunked so badly the answer was split across two fragments. Before upgrading a model, fix retrieval, chunking and the system prompt — that work is cheaper, and it compounds across every model you use afterward.
03
Treat every tool result as untrusted
A web page, an issue comment, a Slack message, a database row — anything an agent reads can carry instructions aimed at the model. The defense is architectural, not textual: scope credentials to the minimum each task needs, keep a human approval step on irreversible actions, and never let content an agent read authorize an action it could not otherwise take.
04
You cannot improve what you do not measure
These systems are non-deterministic, so a prompt change that looks better on three hand-tried examples is indistinguishable from luck. Build a dataset of real inputs with known-good outputs, define scorers for what actually matters, and run them on every change. This is the least glamorous item on this page and the one that most reliably separates AI features that survive contact with users from the ones quietly turned off.
FAQ
Building with AI, answered directly
01
What is an MCP server?
An MCP server is a program that exposes a system — a filesystem, a database, an API, a browser — to AI assistants through the Model Context Protocol, an open standard. Because the interface is standard, one server works with every MCP-compatible client, so an integration is built once rather than rebuilt for each assistant. A server advertises the tools it offers, the arguments each accepts, and the results it returns; the client decides which to call.
02
What is the difference between an AI agent, a skill and an MCP server?
They occupy three different layers. An agent is the loop — the program that sends a prompt to a model, executes whatever tools the model asks for, feeds results back, and repeats until the task is done. An MCP server is a capability that loop can call, giving the agent access to a system it otherwise could not reach. A skill is packaged procedural knowledge — instructions and reference files the model loads only when a task needs them — which changes how the agent does a job rather than what it can reach. A typical production agent uses all three at once.
03
Do I need an agent framework, or is a plain loop enough?
For most first systems, a plain loop is enough and finishes sooner. A tool-calling loop against a model API is roughly fifty lines: send messages, check whether the model requested a tool, execute it, append the result, repeat. Reach for a framework when you have a specific need it solves — durable state that survives a restart, human approval steps that pause mid-run, or branching control flow that is genuinely hard to express. Adopting a framework before you have that need buys abstraction you must learn, debug, and eventually work around.
04
Which vector database should I use for RAG?
Start with the database you already operate. If you run PostgreSQL, pgvector keeps embeddings beside relational data, so a single query can filter by tenant, permission and date while doing similarity search — and you add no new service to back up or monitor. Move to a dedicated vector database such as Qdrant, Weaviate or Pinecone when you have measured a specific limitation: collection size, query latency under load, or filtering behavior that pgvector cannot meet. The scale at which that happens is far higher than most teams assume.
05
How do I evaluate an AI feature before shipping it?
Build a dataset of real inputs with known-good outputs, define scorers that measure what actually matters for your use case, and run the suite on every prompt or model change — the same discipline as any regression test. Tools such as Promptfoo, Braintrust, Langfuse and LangSmith automate the running and comparison, but none of them can tell you what good looks like; curating the dataset and writing the scorers is the real work and the part that cannot be bought. Without this, a prompt change that appears better is indistinguishable from one that got lucky on the three examples you tried by hand.
06
What are the main security risks when giving an AI agent tools?
Three dominate. Prompt injection: any content an agent reads — a web page, an issue comment, a document, a channel message — can contain instructions, so tool output must be treated as untrusted data and never as a command. Over-broad credentials: an agent inherits the full permissions of the token it holds, so scope each credential to the minimum the task needs rather than reusing an administrator key. Data egress: prompts, error traces and retrieved documents are sent to whichever model provider you use, which extends your data-processing boundary — redact sensitive fields before the call, and confirm the provider's retention terms.
07
Should I self-host models or use a hosted API?
Use a hosted API unless a specific constraint rules it out. Self-hosting with vLLM or Ollama makes sense when data residency prohibits sending content to a provider, when volume is high and steady enough that per-token pricing exceeds hardware cost, or when you need a model no provider serves. Against that, count the real cost honestly: GPU capacity, driver and model updates, on-call, and the engineering time that stops going into your product. Below substantial sustained volume, hosted APIs are usually cheaper once staff time is included.
Free Engagement
Knowing the tools is the easy half.
The hard half is choosing between them for your constraints, then getting the result into production with evals, guardrails and someone on call. That is the work we do. Tell us what you are building and we will tell you straight whether it needs an agent at all.