Manually update Xbox console IP, Live Device ID, name, or authentication tokens to keep AI controller access current.
Updates console IP, Live Device ID, name, or authentication tokens manually.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | Local IP address of the Xbox. | |
| name | No | Friendly name for the console. | |
| user_hash | No | Xbox Live User Hash (uhs). | |
| xsts_token | No | Xbox Live XSTS Token. | |
| live_device_id | No | Xbox Live Device ID (Settings > System > Console Info). |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a mutation but does not disclose whether partial updates preserve unspecified fields, whether changes persist, what authentication or permissions are required, or what happens on invalid tokens/IPs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted terms. Its brevity is appropriate for the summary level, and the missing details are a completeness issue rather than a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with five optional parameters, no annotations, and no output schema, the description is incomplete. It should clarify partial-update semantics, authentication requirements, and return/error behavior so an agent can invoke it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented with descriptions. The tool description merely enumerates the same fields and adds no additional format, validation, or dependency details beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Updates') and enumerates the configurable resources: console IP, Live Device ID, name, and authentication tokens. It is clearly a setter counterpart to xbox_get_config, but it does not explicitly name or differentiate itself from relevant siblings like xbox_discover or xbox_auth_device_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as xbox_discover or xbox_auth_device_code. The word 'manually' hints at a manual override use case, but it does not specify prerequisites, when automatic discovery/auth is preferred, or any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.