Skip to main content
Glama
Sign In

LexQ

by io.lexq
OverviewDiscussionsAdmin

Update Policy Group

lexq_groups_update
Destructive

Update a policy group. Only provided fields are updated; omitted fields remain unchanged. A deleted group cannot be updated (409 P-059).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "groupId": "<groupId>"
    },
    "name": "lexq_groups_update"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoNew name
statusNoDISABLED stops production execution of this group: execution calls return 403 (P-009), and a composite call that includes the group is rejected in full. The deployed version and any A/B test are kept, and dry run, Impact Simulation, and Decision Replay keep working, so a fix can be verified before setting ACTIVE again. To go back to the previous version, use lexq_deploy_rollback. To take the version out of production, use lexq_deploy_undeploy.
groupIdYesPolicy group ID
descriptionNoNew description
activationModeNoConflict resolution mode
executionLimitNoHow many policy groups sharing this activationGroup may run. Counts groups, not rules.
activationGroupNoActivation group (Execution Group) cluster key. Policy groups sharing this key compete, and group priority picks the winners.
activationStrategyNoRanking used to pick the winning groups

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavior: PATCH-style semantics (omitted fields unchanged) and a specific failure mode with status code 409 / P-059 for deleted groups. It does not say whether an update takes effect in production immediately or requires a republish, which matters for a destructive flag.

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?

Three short sentences, front-loaded with the action, then the update semantics, then the error condition. No filler, no repetition of the title.

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 eight-parameter mutation tool with no output schema, the definition covers the core semantics (partial update, deleted-group rejection) and the schema richly documents every field. The remaining gap is what a successful call returns and whether changes are staged or live, which an agent would want before invoking a destructive operation.

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 100%, so the schema already carries the meaning of all eight parameters, including the detailed DISABLED side effects, enum values, and executionLimit bounds. The description body itself adds nothing parameter-specific, so the baseline 3 applies.

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?

"Update a policy group" states a specific verb and resource, and the partial-update sentence clarifies the mutation model. It does not distinguish this from its obvious siblings (lexq_groups_create, lexq_groups_delete, lexq_rules_update); that differentiation only appears incidentally in the status parameter description via the rollback/undeploy pointers.

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

Usage Guidelines3/5

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

The description implies when to use it (partial edits; omit fields to leave them unchanged) and gives one hard precondition (deleted group returns 409 P-059). It never states when to prefer a different tool, e.g. lexq_deploy_rollback or lexq_deploy_undeploy for production changes, which are only mentioned inside the status enum description rather than as routing guidance.

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

All LexQ toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources