angel-menu-mcp

Overview Schema Source Related Servers Discussions Admin

set_feature

Set a single in-game menu control by passing a boolean for checkboxes or an integer for sliders/comboboxes. Arm writes before changing danger controls; returns the applied value read back for confirmation.

Instructions

Set one menu control. For a checkbox pass value true/false; for a slider or combobox pass an integer (combobox = option index from list_features). Danger controls fail unless writes are armed in the overlay. Returns the value read back after it was applied.

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": {
      "name": "<name>",
      "value": "<value>"
    },
    "name": "set_feature"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	control name
`value`	Yes	boolean for a checkbox, integer for a slider/combobox

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly signals a mutating action, warns that danger controls fail unless writes are armed in the overlay, and states the return value is read back after application. This is rich and useful behavioral context.

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 compact sentences carry all essential information: what the tool does, how to format values, and what to expect from the response. The purpose is front-loaded, and there is no redundant wording.

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 two-parameter setter with no output schema or annotations, the description is complete: it covers intended input semantics, a key safety caveat, and the return behavior. An agent has enough context to invoke the tool correctly in a supported flow.

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?

The schema already covers the parameter basics, but the description adds meaning beyond it: it explains that the combobox value is an option index from list_features and reinforces the boolean/integer expectations. This extra linkage helps an agent select and construct the value correctly.

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: 'Set one menu control.' It clarifies scope and stands apart from siblings such as list_features and get_feature by clearly addressing a write operation. The examples of control types further disambiguate it from the read-oriented sibling tools.

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?

The description gives concrete when-to-use guidance by mapping value types to control kinds and pointing to list_features for combobox option indices. It doesn't explicitly say when not to use this tool versus get_feature, but the context and caveat about armed writes make the usage boundary sufficiently clear.

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

Deploy Server