Skip to main content
Glama
okareo-ai

Okareo MCP Server

Official
by okareo-ai
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Create or Update Driver

create_or_update_driver
Idempotent

Create or update a simulated user persona for AI testing, defining scenario details, objectives, and soft tactics. Upserts by name for repeatable simulations.

Instructions

Define a simulated user persona that will interact with your target.

    Creates or updates a Driver by name (upsert). Author ONLY the core
    persona sections in prompt_template, in this order:

    - `## Persona` — who the simulated user is (static character).
    - `## Scenario Details` — contains the scenario reference
      (`{scenario_input}` or a specific path like
      `{scenario_input.objectives}`), placed immediately before
      Objectives. This is how each scenario row's data reaches the
      conversation.
    - `## Objectives` — WHAT the driver is trying to accomplish, written
      from the driver's goal (not from scenario variables).
    - `## Soft Tactics` — HOW the driver probes, escalates, and stops.

    Do NOT author Hard Rules, a Turn-End Checklist, or Conversation
    Behavior sections: the MCP automatically appends the platform's
    canonical versions of those blocks (including the language rule
    matching `language`) — the same blocks the Okareo UI appends to
    generated drivers. Any caller-authored variant of these sections is
    replaced by the canonical text, and repeated updates never duplicate
    the blocks.

    For voice agents, configure how the simulated user speaks with `voice`,
    `voice_profile`, `voice_instructions`, and `language`. Call
    list_driver_voices first to discover valid voice and profile values.

    Args:
        name: Unique name for this driver.
        prompt_template: The core persona prompt (Persona, Scenario
            Details, Objectives, Soft Tactics — see above). Hard Rules and
            Conversation Behavior are appended automatically.
        model_id: Foundation model to power the driver (defaults to project default).
        temperature: Response randomness, default 0.6.
        voice_instructions: Free-text speaking instructions for voice simulations
            (tone, pace, accent). Not validated against the voice catalog.
        voice_profile: Voice profile name for voice simulations. Validated
            against the catalog from list_driver_voices.
        voice: Voice identifier for voice simulations. Validated against the
            catalog from list_driver_voices.
        language: Language the driver responds in, as the bare ISO code
            the voice catalog serves (e.g. "en", "es", "ja"); regional
            variants like "fr-CA" are accepted when their base code
            matches the voice's language. When a `voice` is set and
            language is omitted, it is derived from that voice's catalog
            language (disclosed as `language_derived_from_voice` in the
            response); a value conflicting with the voice's language is
            rejected. Also drives the appended Hard Rules language rule.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
voiceNo
languageNo
model_idNo
temperatureNo
voice_profileNo
prompt_templateYes
voice_instructionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (idempotentHint=true), the description discloses that caller-authored canonical sections are replaced and repeated updates never duplicate blocks. It also reveals language conflict rejection and language derivation behavior with voice, which are non-obvious behavioral traits not inferable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized with an opening summary, explicit authoring rules, voice configuration guidance, and a per-parameter breakdown. Every sentence adds value, and the structure makes scanning easy despite the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is fully complete for a complex tool: it covers all parameters, prerequisites, validation behavior, and automatic append behavior. It even mentions response disclosure (language_derived_from_voice). With an output schema available, no return description is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The 'Args:' section adds rich semantics for all 8 parameters: uniqueness of name, allowed prompt_template sections, model_id default, temperature default, voice validation against the catalog, and language rules including regional variants and derivation. This goes far beyond the bare schema types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear summary: 'Define a simulated user persona that will interact with your target. Creates or updates a Driver by name (upsert).' This is a specific verb+resource statement that distinguishes the tool from siblings like get_driver, list_drivers, and list_driver_voices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance, including a 'Do NOT author Hard Rules...' warning and instructs callers to 'Call list_driver_voices first to discover valid voice and profile values.' This tells when to use a sibling tool first and what not to include, which is explicit when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/okareo-ai/okareo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server