Comunio MCP

Take a player off the market

unlist_player_from_market

Remove one of your players from the transfer market, ending its sale listing. Confirm the player ID from get_market first; any offers already made stay active.

Instructions

Take one of the manager's own players back off the market, so it is no longer for sale.

This changes the manager's team. Confirm which player with the user before calling it. Ids come from get_market, where the manager's own listings are the ones marked is_mine.

Any offers already received for that player are not cancelled by this — check get_offers.

Comunio reports no per-player detail here, only an overall status, so unlisted is what was asked for rather than what was confirmed. Call get_market if it matters.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`player_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes	Whether Comunio reported the request as successful
`unlisted`	Yes	Player ids the request asked to take off sale

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2Sep 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations by warning that the action changes the team, does not cancel existing offers, returns only an overall status rather than per-player confirmation, and suggesting get_market for verification.

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 compact and well-structured: first sentence states the action, then bolded warnings and follow-up guidance are provided in separate short paragraphs. No filler or 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?

It covers the source of the required argument, the pre-action confirmation step, the side effect on offers, the response granularity, and the follow-up call to get_market. The description is sufficient for correct and safe invocation.

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 only parameter (player_id) is not described in the schema, but the description compensates by saying IDs come from get_market and are the manager's own listings marked is_mine. It could add a bit more format detail, but the single parameter is fully actionable.

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 uses a specific verb and resource ('Take a player off the market') and clearly scopes it to the manager's own players, making it easy to distinguish from listing, pricing, and bidding operations.

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?

Provides clear procedural context: confirm the player with the user, use IDs from get_market where is_mine identifies own listings, and check get_offers if relevant. It does not explicitly name exclusions or alternative tools, but the context is unambiguous.

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