DOS AI

Edit a bot function

dosai_update_function

Change one function of the bot: its name, the description the model reads to decide WHEN to call it, its parameters, whether it is on, the "after this function, say nothing to the client" switch, or the "only looks things up" switch. Send only what changes. The description is the single strongest lever over a function: it is what the model sees. Address, headers, secrets and the action type are NOT editable here, they live in the cabinet. Requires editor role.

Input Schema

Name	Required	Description
`name`	No	Technical name the model calls, latin letters, digits and underscore.
`is_active`	No
`read_only`	No	true = this function only looks things up and changes nothing (product search, stock, price list). When the client writes more while the bot is answering after such a function, the bot waits and answers everything in ONE message, calling the function again. Only for HTTP (webhook) functions, refused for built-in ones and together with "this is a lead", "say nothing", "finish the dialog" or a booking: a function that sends, books or records must never be repeated. false removes the switch.
`parameters`	No	Full new list of parameters: it REPLACES the old one, so send every parameter you want to keep.
`project_id`	Yes	Project id, as returned by dosai_list_projects.
`description`	No	When to call this function and what it does, in the owner's words. This is what the model reads.
`function_id`	Yes	Function id, as returned by dosai_list_functions.
`silent_after_call`	No	true = after this function fires, the bot sends the client NOTHING: no text, no bubble in the dialog, and the chat is marked "reply by hand" for the owner. For a function that calls a human in and a person answers within minutes. Refused together with "this is a lead" (the lead card would not be created). false removes the switch.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / read_only / description

Previous value: -"true = this function only looks things up and changes nothing (product search, stock, price list). When the client writes more while the bot is answering after such a function, the bot waits and answers everything in ONE message, calling the function again. Only for HTTP (webhook) functions, refused for built-in ones and together with \"this is a lead\" or \"say nothing\": a function that sends, books or records must never be repeated. false removes the switch."New value: +"true = this function only looks things up and changes nothing (product search, stock, price list). When the client writes more while the bot is answering after such a function, the bot waits and answers everything in ONE message, calling the function again. Only for HTTP (webhook) functions, refused for built-in ones and together with \"this is a lead\", \"say nothing\", \"finish the dialog\" or a booking: a function that sends, books or records must never be repeated. false removes the switch."

Changed1 schema field changedOct 31, 2026

addedInput schema / properties / read_only

Added value: +{
+  "description": "true = this function only looks things up and changes nothing (product search, stock, price list). When the client writes more while the bot is answering after such a function, the bot waits and answers everything in ONE message, calling the function again. Only for HTTP (webhook) functions, refused for built-in ones and together with \"this is a lead\" or \"say nothing\": a function that sends, books or records must never be repeated. false removes the switch.",
+  "type": "boolean"
+}

AddedOct 28, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds real value beyond that: the editor-role requirement and the scope boundary that addressing/secrets/action type cannot be changed here. It does not state what the call returns or what happens on conflicting switch combinations, though those refusals are covered in the schema fields.

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 the editable surface, then the update semantics, then the scope exclusion and auth requirement — a sensible order. The field enumeration is long but each item maps to a real parameter; the sentence about `description` being the strongest lever is arguably redundant with the schema's own description but still earns its place as guidance.

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

Completeness4/5

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

For an 8-parameter mutation tool with no output schema, the description covers editable scope, partial-update semantics, exclusions and the permission needed. Only the return value and the rejection behavior for invalid switch combinations are unaddressed at the top level, and the latter is documented inside the relevant schema properties.

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?

Schema coverage is already 88%, so the baseline is 3. The description adds interpretive weight beyond the schema: it frames the `description` field as 'the single strongest lever over a function: it is what the model sees', which tells the agent how much care to take there, and 'Send only what changes' clarifies that omitted fields are preserved.

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

Purpose4/5

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

Opens with a specific verb+resource ('Change one function of the bot') and enumerates the exact editable fields: name, description, parameters, active flag, silent switch, read-only switch. It also carves out what is NOT editable here (address, headers, secrets, action type), which separates it from the cabinet UI. It does not distinguish itself from the sibling dosai_set_function_active, which overlaps on the 'whether it is on' field.

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

Usage Guidelines4/5

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

'Send only what changes' gives explicit partial-update guidance, and 'Requires editor role' states a prerequisite. It also points out that non-editable config lives elsewhere. However, no alternative sibling is named (e.g. use dosai_set_function_active for a simple toggle, dosai_get_function to read current values).

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

All DOS AI 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.

Resources

Need Help?