Should I pass in my entrypoint function into `Work...
# ask-ai
a
Should I pass in my entrypoint function into
WorkerOptions
or use the
@server.rtc_session()
decorator?
t
Thanks for reaching out, Muhammad. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — good question. Use one or the other depending on which pattern you’re using: • If you’re using an AgentServer, use the
@server.rtc_session()
decorator to define the entrypoint.
Copy code
server = AgentServer()

  @server.rtc_session()
  async def entrypoint(ctx: JobContext):
      await ctx.connect()
• If you’re not using AgentServer and are running a standalone worker, pass your entrypoint into
WorkerOptions(entrypoint_fnc=...)
.
Copy code
async def entrypoint(ctx: JobContext):
      await ctx.connect()

  cli.run_app(WorkerOptions(entrypoint_fnc=entrypoint))
Do not use both simultaneously. Use
AgentServer
(decorator) when you need server-level lifecycle hooks and customization; use
WorkerOptions
for a simpler standalone worker. Do you want help converting your current setup to one of these patterns? Sources: Agent server options | LiveKit docs | Building an Automated IVR Menu Caller | LiveKit docs
a
what's the difference between the two?
t
Great — here’s a concise comparison. High-level purpose •
@server.rtc_session()
(AgentServer): for running an agent as a server with lifecycle hooks and richer server-level control. •
WorkerOptions(entrypoint_fnc=...)
(standalone worker): for running a single worker process with a direct entrypoint, simpler/lighter weight. Usage pattern • AgentServer + decorator: ◦ You create an
AgentServer()
instance. ◦ Decorate the entrypoint with
@server.rtc_session()
so the server manages sessions, routing, and lifecycle. ◦ Server provides hooks like
setup_fnc
,
on_request
, and other server-level configuration. • WorkerOptions: ◦ You write an async
entrypoint(ctx: JobContext)
and pass it to
WorkerOptions(entrypoint_fnc=entrypoint)
. ◦ Run via the CLI runner for a straightforward worker process without server scaffolding. Lifecycle & features • AgentServer: ◦ More control over startup, shutdown, request handling, and additional server hooks. ◦ Better for complex agents, multi-endpoint handling, or when you need centralized configuration. • WorkerOptions: ◦ Minimal lifecycle management—just run the worker entrypoint. ◦ Ideal for lightweight, single-purpose workers or simple deployments. When to pick which • Choose
AgentServer
+
@server.rtc_session()
when you need server-level features, multiple hooks, or a more configurable runtime. • Choose
WorkerOptions(entrypoint_fnc=...)
when you want a simple, standalone worker with minimal boilerplate. You shouldn’t use both at once. Want to show me your current code so I can recommend which fits it best?
a
Is it possible to attach an MCP server to my agent after the session is created?
t
Thanks — about attaching an MCP server after session creation: You cannot attach an MCP server to an AgentSession after it’s created. MCP servers must be provided when the session is initialized via the
mcp_servers
parameter (e.g.,
AgentSession(mcp_servers=[mcp.MCPServerHTTP(...)] )
). Tools from MCP servers are loaded at startup and cannot be added or removed at runtime. If you need dynamic tool availability, you can either: • Recreate/reinitialize the session with the updated
mcp_servers
, or • Load tools programmatically by other means (not via adding MCP servers at runtime). Do you want help with reinitializing the session or an alternative approach to load tools dynamically? Sources: Tool definition and use | LiveKit docs