> ## Documentation Index
> Fetch the complete documentation index at: https://redop.useagents.site/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Middleware vs Hooks vs Plugins

> Choose the right composition primitive in Redop instead of forcing everything into handlers.

Redop gives you five main ways to shape behavior around tools, resources, and prompts.

## Use middleware when

* you need to block or allow execution
* you need to wrap `next()`
* you want request-aware control flow such as auth, rate limiting, or caching

## Use hooks when

* you want observability
* you want lightweight pre- or post-processing
* you need to choose between pre-response hooks such as `onAfterHandle` and post-response hooks such as `onAfterResponse`
* you do not need to control execution flow

## Use plugins when

* you want to package reusable behavior
* you want to ship a group of tools plus middleware or hooks
* you want one installable unit that multiple servers can reuse

## Use `.use(...)` for feature modules when

* you are organizing one larger server into folders
* each feature area should own its own registrations
* you want the root `src/index.ts` to stay small
* you want composition to be explicit and easy to trace

The common pattern is:

* one feature folder exports one `Redop` instance
* that instance registers feature-local tools, resources, prompts, hooks, and middleware
* the root server imports each feature module and attaches it with `.use(...)`

## Build custom composition when

* built-in plugins get you close, but not all the way
* you want reusable middleware with your own defaults
* you want to publish a plugin other Redop servers can consume

See [Build a plugin or middleware](/docs/guides/build-plugin-or-middleware) for step-by-step examples.

## Naming matters

Since Redop does not rewrite names for you, prefer explicit names that reflect the feature area:

* tools: `notes.list`
* prompts: `notes.summarise`
* resources: `notes://{id}`