Redop gives you five main ways to shape behavior around tools, resources, and prompts.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.
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
onAfterHandleand post-response hooks such asonAfterResponse - 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.tsto stay small - you want composition to be explicit and easy to trace
- one feature folder exports one
Redopinstance - 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
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}