Skip to main content
Glama
Sign In

Skysay

by io.github.skysay-ai
OverviewDiscussionsAdmin

Set an AI agent's call variables

set_agent_variables
Destructive

Replace an AI agent's whole call variables config, as PUT /v1/agents/{agent_id}/variables does. It is checked and republished at once, so the next call uses it; nothing is stored on a refusal. Send base_revision from get_agent_variables to be refused, rather than overwrite, when the agent changed since. A refused config returns error.body.issues, each with a code and where it points.

Input Schema

NameRequiredDescriptionDefault
configYesAn agent's call variables, SMS templates and caller lookup. Exported from config_schema.py (the API's copy; tests pin the two equal) for the dashboard and the docs. tests/fixtures/call_variables/config_cases.json is the accept/reject contract.
agent_idYes
base_revisionNoThe revision this edit was based on. When sent and stale, the write is refused with 409 revision_conflict. Omit for last-write-wins.
organization_idNoOptional. Defaults to the authenticated workspace; when supplied it must be that workspace's id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / $defs / field / properties / keypad
      Added value: +{
+  "additionalProperties": false,
+  "description": "The call may enter this value on a phone menu keypad. It is never given to the model or any prompt, only keyed through the keypad.",
+  "properties": {
+    "class": {
+      "enum": [
+        "reference",
+        "card",
+        "pin",
+        "government_id",
+        "date_of_birth",
+        "other"
+      ]
+    }
+  },
+  "required": [
+    "class"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is known. The description adds substantive behavior beyond that: the config is validated and republished atomically so the next call uses it, a refusal persists nothing, and refusals surface error.body.issues with a code and pointer.

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?

Four tightly packed sentences, front-loaded with the PUT-equivalent replacement semantics, then atomicity, then concurrency guidance, then error shape. No filler; each sentence contributes a distinct fact.

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 a destructive, nested-config mutation with annotations present and no output schema, the description covers the write semantics, concurrency contract, and refusal error shape well. It does not mention what a successful response returns (e.g., the new revision), which would help an agent chain subsequent calls.

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

Parameters3/5

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

Schema description coverage is 75% and base_revision/organization_id already carry schema descriptions; the description largely restates the base_revision concurrency semantics rather than adding new meaning, and says nothing about agent_id or the structure of config. Baseline 3 is appropriate when the schema does most of the work.

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?

States a specific verb (replace), the exact resource (an AI agent's whole call variables config), and the scope (whole config, not a partial patch), explicitly equating it to PUT /v1/agents/{agent_id}/variables. This cleanly distinguishes it from the sibling get_agent_variables, which it also names.

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?

Gives clear conditional guidance: send base_revision (obtained from get_agent_variables) to be refused rather than overwrite on a concurrent change, or omit it for last-write-wins. It names the sibling source for base_revision but does not explicitly contrast with other write siblings like update_agent or set_agent_voice_stack.

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

All Skysay toolsInspect
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