Last Price

update_routing_policy

DestructiveIdempotent

Change a routing policy. Only the fields you send change; config replaces the whole config. The strategy must still be usable with the config that results. Needs a Last Price credential with routing write scope. Needs a claimed workspace: a sandbox key from self-registration is refused (403) until a person claims the workspace.

Input Schema

Name	Required	Description
`name`	No	A new name.
`config`	No	What the strategy needs. weights gives each function id a share (weighted). rules each send requests whose field matches to a function (policy). fallback_chain lists function ids to try in order when the strategy picks none. experiment runs an A/B test inside the policy, one function per arm.
`strategy`	No	A new strategy.
`policy_id`	Yes	The routing policy UUID: id on a list_routing_policies result.
`is_default`	No	Make this the workspace default.
`fallback_function_id`	No	A function to use when the strategy picks none. Null clears it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

changedInput schema / properties / config / description

Previous value: -"What the strategy needs. weights gives each function id a share (weighted). rules each send requests whose field matches to a function (policy). fallback_chain lists function ids to try in order when the strategy picks none."New value: +"What the strategy needs. weights gives each function id a share (weighted). rules each send requests whose field matches to a function (policy). fallback_chain lists function ids to try in order when the strategy picks none. experiment runs an A/B test inside the policy, one function per arm."

addedInput schema / properties / config / properties / experiment

Added value: +{
+  "additionalProperties": false,
+  "description": "Run an experiment inside the policy: each call the policy routes is put in a stable arm (by metadata.user_id, else the product id), runs that arm's function and is recorded for the experiment's results; once a winner is promoted every call runs the winner's function. Applies while experiment recording is released for your workspace; saved either way.",
+  "properties": {
+    "arms": {
+      "description": "Each arm and the function it runs. One arm must be named control.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "function_id": {
+            "description": "The pricing function this arm runs.",
+            "format": "uuid",
+            "type": "string"
+          },
+          "variant": {
+            "description": "The arm name, for example control or experiment.",
+            "pattern": "^[a-z][a-z0-9_]{0,39}$",
+            "type": "string"
+          }
+        },
+        "required": [
+          "variant",
+          "function_id"
+        ],
+        "type": "object"
+      },
+      "maxItems": 10,
+      "minItems": 2,
+      "type": "array"
+    },
+    "key": {
+      "description": "The experiment key, as in /api/experiments/{key}. Created on the first routed call when there is none.",
+      "maxLength": 100,
+      "minLength": 1,
+      "pattern": "^[a-z0-9_]+$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "key",
+    "arms"
+  ],
+  "type": "object"
+}

AddedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavior: partial field updates, full config replacement, strategy-config compatibility validation, required routing write scope, and the 403 behavior for unclaimed sandbox workspaces. This is substantial operational context for a destructive mutation.

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 front-loaded and compact: purpose first, then update semantics, then prerequisites. Every sentence contributes useful information without repetition.

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 complex nested update tool, it covers the critical update model, config replacement behavior, strategy compatibility, auth scope, and workspace-claim prerequisite. Although it does not describe the response, the schema and annotations carry enough of the remaining context.

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 100%, so the baseline is 3. The description still adds meaningful cross-parameter semantics by noting that omitted fields are preserved, config is replaced entirely, and the resulting strategy must remain usable with the resulting config.

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 and resource: 'Change a routing policy.' It distinguishes the operation from create/get/list/delete siblings through the verb and also clarifies partial-update semantics immediately.

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?

It gives clear usage context: only supplied fields change, config is replaced wholesale, and the resulting strategy/config combination must remain valid. It also states credential and workspace prerequisites, though it does not explicitly name create/delete/get alternatives.

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

All Last Price 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?