Comunio MCP

Change an asking price

change_listing_price

Idempotent

Change the asking price for a player you've already listed on the market, setting a new price for your sale. Confirm the player and price before applying.

Instructions

Change what the manager is asking for a player they already have listed on the market.

This changes the manager's team. Confirm the player and the new price with the user before calling it. The player must already be listed — use list_player_on_market first if they are not; this tool cannot put anyone up for sale.

This sets the manager's own asking price. It has nothing to do with the recommended_price that get_market and get_player report, which is Comunio's suggestion and cannot be changed.

Comunio answers with a bare true here rather than any detail, so ok is all there is to go on.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`price`	Yes
`player_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether Comunio accepted the change
`price`	Yes	The asking price that was requested, in euros
`player_id`	Yes	Player whose price was changed

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2Sep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The annotations cover the base mutation profile, but the description adds useful behavioral context: the call changes the manager's team, it cannot list an unlisted player, and the response from Comunio is only a bare `true`. This does not contradict any annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main action and uses short, bolded sections for preconditions, side effects, and output behavior. It is not the shortest possible description, but every section adds relevant information for correctly using the tool.

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 mutation tool, the description covers the operation, the prerequisite, the user-confirmation requirement, the distinction from `recommended_price`, and the actual response shape. Given the annotations and output schema, the agent has enough context to call the tool safely and correctly.

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 description coverage is 0%, so the description carries the semantic load. It explains that `price` is the manager's own asking price and that `player_id` must refer to an already-listed player. It does not mention possible price constraints, but the core meaning of both parameters is covered.

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 first sentence states a specific action and resource: change the asking price for a player already listed on the market. It explicitly distinguishes itself from `list_player_on_market` by saying it cannot put anyone up for sale, so an agent can tell exactly what this tool does.

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

Usage Guidelines5/5

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

The description clearly gives a prerequisite: the player must already be listed, and `list_player_on_market` should be called first if not. It also provides a safety guideline to confirm the player and new price with the user before invoking the tool.

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