- A client discovers prompts via
prompts/list(each prompt may includeargumentsand metadata). - A client renders a prompt via
prompts/getwith string-valuedarguments. - The server executes your prompt renderer.
- The server returns a
GetPromptResultcontainingmessages(and optionaldescription) per MCP spec.
@prompt(...) and register them with server.collect(...) (or inside with server.binding(): ...).
Decorator signature
prompt(...):prompt(name: str, *, description=None, title=None, arguments=None, icons=None, meta=None)
fn(arguments: dict[str, str] | None)→ returns messages / mapping /GetPromptResult/None
Basic prompt
arguments=[...] defines what the client should pass to prompts/get.
Arguments (required vs optional)
Dedalus MCP treats arguments as required only if you mark themrequired=True in the decorator’s arguments=[...].
INVALID_PARAMS.
Complex argument values (lists/dicts)
MCP prompt arguments are strings. If you need structured values, pass JSON strings and parse them yourself:Return formats
Prompt renderers can return:- A list/iterable of messages, where each item can be:
- a
(role, content)tuple - a mapping like
{"role": "...", "content": ...} - a
PromptMessageinstance
- a
- A mapping with explicit control:
- required:
"messages" - optional:
"description"
- required:
GetPromptResultNone(produces zero messages)
str (Dedalus raises TypeError so you always provide role + content).
Explicit control (mapping)
Message content
For messagecontent, you can use:
- a
str(auto-coerced to text content) - a full content-block mapping (e.g.
{"type": "text", "text": "..."}) - a content-block instance from
dedalus_mcp.types(e.g.TextContent,ImageContent, etc.)
Async prompts
async def for I/O.
Decorator options
Context access
If a prompt is rendered during an MCP request, it can access context viaget_context() (for logging, progress, etc.).
Note: get_context() only works inside an active MCP request handler; calling it outside a request raises LookupError.
Testing
Test prompt renderers like normal functions:prompts/get):