Dialyne

Read or change how the voice agent introduces itself

configure_agent_identity

Idempotent

Read or change how the voice agent introduces itself on the user's calls: name, tone, opening line, answer to "who is calling?", introduction and the AI mention in the opening. Compliance: the recommended settings (default) say "Hello, this is Léa, 's virtual assistant. I'm calling about…" and answer yes when asked if it is an AI (EU AI Act art. 50); the agent never denies being an AI, whatever the settings.

Call it with no argument to read the current identity, a preview of what the agent will say, and the warning. Name and tone can be changed freely. Any other change is a deviation from the recommended settings: the first attempt returns the warning (error responsibility_acceptance_required) and changes nothing. Show the warning text to the user word for word; only if the user explicitly accepts, call again with the same changes plus accept_responsibility=true and warning_version. The acceptance is logged with a timestamp and the user becomes responsible for those settings. Refused whatever the acceptance: texts claiming the agent is human, or presenting it as police, government or a bank.

When to use: the user asks to rename the agent, change how it introduces itself or its tone. When not to use: a one-off greeting for a single call (put it in place_phone_call's task instead). Side effects: changes the settings for every new call of the account (calls already scheduled keep their identity). Idempotent.

Input Schema

Name	Required	Description
`tone`	No	Tone of voice: 'warm' (recommended), 'neutral', 'formal' or 'upbeat'. Stays within the recommended settings.
`first_name`	No	Name the voice agent gives (e.g. 'Lea'). Omit to keep the current one. Stays within the recommended settings.
`introduction`	No	Custom answer when the callee asks who the agent is. Empty string = recommended. DEVIATION.
`opening_line`	No	Custom opening line, spoken word for word when the callee answers, before the purpose of the call; may use {prenom} (agent name) and {operateur} (user's announced name). Write it in the language of the calls. Empty string = back to the recommended line. DEVIATION: needs the user's acceptance.
`warning_version`	No	The warning.version the user accepted (from a previous call of this tool).
`reset_to_recommended`	No	true: drop every deviation (keeps first_name and tone).
`accept_responsibility`	No	Set true ONLY after you showed the user the warning text returned by this tool and the user explicitly accepted it in their own words. Never set it on your own initiative.
`ai_mention_in_opening`	No	true (recommended): the opening line says the agent is a virtual assistant. false = DEVIATION. Either way the agent says yes if asked whether it is an AI.
`who_is_calling_answer`	No	Custom answer when the callee asks who the agent is calling for. Empty string = recommended. DEVIATION.

Output Schema

Name	Required	Description	Default
`preview`	No
`warning`	No
`identity`	No
`next_step`	No
`deviations`	No
`fixed_rule`	No
`responsibility_accepted_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it discloses the two-step responsibility-acceptance flow, the error code responsibility_acceptance_required, the fact that the first attempt changes nothing, that acceptance is logged with a timestamp, hard refusals (human-impersonation, police/government/bank), and account-wide side effects with scheduled calls retaining their identity. The only minor gap is that annotation-level claims like idempotency are restated rather than expanded, but the compliance workflow is far richer than the annotations.

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

Conciseness4/5

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

Front-loaded with purpose, then compliance context, then invocation mechanics, then when/when-not and side effects — a logical progression with no filler sentences. It runs long, and the compliance paragraph could be tightened, but nearly every clause carries operational information the agent needs.

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?

For a 9-parameter mutation tool with compliance implications, the description covers read mode output (current identity, preview, warning), the acceptance handshake, refusal cases, and side-effect scope. An output schema exists, yet it still explains what the no-argument call returns, so nothing essential is missing.

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

Parameters4/5

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

With 100% schema coverage the baseline is 3, but the description adds workflow meaning the schema alone does not convey: which parameters are free (name, tone) versus deviations, and the required pairing of the same changes with accept_responsibility=true plus warning_version on retry. It reinforces reset_to_recommended keeping name and tone, though it does not restate each parameter individually.

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 specific verb pair (read/change) and resource (how the voice agent introduces itself), then enumerates the exact editable facets: name, tone, opening line, 'who is calling?' answer, introduction, AI mention. It is unmistakably distinct from siblings like place_phone_call or transfer_call_to_user.

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?

It gives an explicit 'When to use' (rename the agent, change introduction or tone) and an explicit 'When not to use' that names the alternative: a one-off greeting belongs in place_phone_call's task. It also tells the agent how to invoke read mode (no argument).

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

All Dialyne tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.