Directory

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.

Independently curated
Trade-off on every entry
No sponsored listings
Reviewed September 2026

How do I give an AI agent access to my systems?

MCP Servers & Connectors8

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.

GitHub MCP Server

GitHub · MCP server

Open source

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

Microsoft · MCP server

Open source

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.

PostgreSQL MCP Server

MCP community · MCP server

Open source

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.

Sentry MCP Server

Sentry · MCP server

Open source

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.

Slack MCP Server

MCP community · MCP server

Open source

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.

Fetch MCP Server

Anthropic · MCP server

Open source

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.

Memory MCP Server

Anthropic · MCP server

Open source

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.

Back to filters

What should I build the agent loop on?

Agent Frameworks & SDKs8

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.

Anthropic SDK Tool Runner

Anthropic · SDK helper

Open source

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

LangChain · Framework

Open source

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.

OpenAI Agents SDK

OpenAI · Agent SDK

Open source

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

Pydantic · Framework

Open source

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.

Vercel AI SDK

Vercel · TypeScript SDK

Open source

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

CrewAI · Framework

Open source

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

Mastra · Framework

Open source

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.

Back to filters

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

Anysphere · AI editor

Proprietary

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

GitHub · IDE assistant

Proprietary

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

Aider · CLI agent

Open source

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

Cline · IDE agent

Open source

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

Continue · IDE extension

Open source

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.

Back to filters

How do I feed the right context to a model?

Skills, Context & Standards5

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

Anthropic · Capability format

Open source

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

Community standard · Web standard

Open source

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

Repomix · Context packer

Open source

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

Tree-sitter · Parser library

Open source

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.

Back to filters

Where do I store embeddings for RAG?

Retrieval & Vector Search6

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

Qdrant · Vector database

Open source

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

Weaviate · Vector database

Open source

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

Chroma · Vector database

Open source

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

LlamaIndex · Data framework

Open source

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

Pinecone · Managed vector database

Managed service

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.

Back to filters

How do I know the AI system still works?

Evals & Observability6

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

LangChain · LLM observability

Managed service

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

Braintrust · Eval platform

Managed service

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.

Arize Phoenix

Arize AI · Observability tool

Open source

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.

OpenTelemetry GenAI Conventions

OpenTelemetry · Standard

Open source

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

Promptfoo · Eval and red-team CLI

Open source

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.

Back to filters

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

OpenRouter · Managed gateway

Managed service

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

vLLM project · Inference server

Open source

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

Ollama · Local runtime

Open source

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

llama.cpp project · Inference engine

Open source

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

Portkey · AI gateway

Managed service

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.

Back to filters

How do I stop the model doing something harmful?

Guardrails & Safety4

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

NVIDIA · Guardrail toolkit

Open source

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

Meta · Safety model

Source available

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.

Microsoft Presidio

Microsoft · PII toolkit

Open source

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.

Back to filters

How to choose

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.

No commitment. No sales pitch. Straight answers.