Skip to main content

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.

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 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}