Hey

Thanks for reaching out, Kushank. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

For the LiveKit agents, how should we define the tool? By defining, I mean the tools that we use, their usage, and when and how to use the tool. These instructions—how should we define them? Should we put them where the tool is defined, along with the system prompt of that agent, or is it enough to have them in one place, like the tool definition place, like when we define the function tool?

Thanks — great question. You’re asking whether tool usage instructions for LiveKit agents should live inside each tool’s definition, in the agent’s system prompt, or in a single central place. Here’s a clear recommendation and why. Short answer • Define the detailed instructions for what a tool does, when to use it, and how to call it directly in the tool definition (the tool description/docstring and parameter annotations). This is the preferred and sufficient place. • Optionally include brief, high-level guidance in the agent’s system prompt (e.g., “use tools when needed, collect inputs first”), but do not duplicate detailed usage rules there. Why this approach • The LLM relies on the tool’s structured metadata (description, parameter schemas, docstrings) to decide when and how to call a tool. Putting specifics in the tool definition gives the model a single clear source of truth. • Keeping detailed behavior in the tool definition reduces drift and duplication. If logic or arguments change, you update one place. • The system prompt is useful for broad policy or behavioral guidance, but not for detailed parameter-level rules — those belong with the tool. What to include in the tool definition (make these explicit) • What the tool does (one-line summary). • When to call it — clear conditions and “do not call when” cases. • Parameter descriptions and expected types/format (examples help). • Expected return value shape and semantics (success, error conditions). • Any side effects, limits, or rate assumptions. Example patterns 1. Python (docstring + type hints)

@function_tool()
async def lookup_weather(location: str) -> dict[str, Any]:
    """Look up weather for a given location. Only call when the user explicitly asks for current weather
    or a forecast. Do not call to answer unrelated questions.

    Args:
        location: City and country (e.g. "London, UK").

    Returns:
        { "weather": "...", "temperature_f": ... }
    """
    ...

1. Node.js (description + parameter schema)

const lookupWeather = llm.tool({
  description: 'Look up weather. Call only when user asks about current weather or forecast.',
  parameters: z.object({
    location: z.string().describe("City and country (e.g., 'New York, US')"),
  }),
  execute: async ({ location }) => { ... },
});

When to add system-prompt guidance • Use the system prompt for agent-wide rules such as tone, whether to ask clarifying questions before calling tools, or general ordering (e.g., “collect inputs first”). • Keep that guidance high level — don’t duplicate parameter-level rules. Single source of truth recommendation • Treat the tool definition as the canonical place for tool behavior. • If you need a central registry for documentation, you can generate docs from the tool definitions (so the registry mirrors the canonical definitions rather than becoming a separate writable source). If you want, I can: • Review one of your existing tool definitions and suggest edits to make the usage guidance clearer. • Show how to generate a human-readable tools registry from your code definitions. Which would you prefer: a review of a specific tool definition, or an example registry generation approach? Sources: Tool definition and use | LiveKit Documentation | Prompting guide | LiveKit Documentation | Logic and structure overview | LiveKit Documentation