Comunio MCP

Set the lineup

set_lineup

Idempotent

Set your Comunio formation and starting eleven by tactic and player IDs, replacing the current lineup. Empty slots cost four points each, and the result reports unavailable or out-of-position players.

Instructions

Set the manager's formation and starting eleven.

This replaces the current lineup. Confirm the formation and the players with the user before calling it.

tactic is one of: 442, 343, 352, 433, 451 — read as defenders, midfielders, strikers. Players are given by position and ids come from get_squad; the slot numbers Comunio wants are worked out here.

A partial lineup is allowed. Comunio deducts four points for every empty slot, and the result says how many were left and what that costs.

Players who are injured or suspended can still be fielded — Comunio permits it — so they are not refused, but the result lists them under unavailable. Check status in get_squad before choosing.

A player can likewise be put in a slot they do not normally play. That is Comunio's call to accept or refuse, not this tool's: the result lists them under out_of_position, and ok says what Comunio decided.

Refused before anything is sent if the formation is not one Comunio accepts, if there are more players than the formation has room for (the extras would be dropped in silence), if a player is not in the squad, or if one appears twice.

The lineup can be set again until the matchday starts.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`keeper`	No
`tactic`	Yes
`strikers`	No
`defenders`	No
`midfielders`	No

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether Comunio accepted the lineup
`tactic`	Yes	Formation the lineup was set to
`fielded`	Yes	Who ended up in which slot
`empty_slots`	Yes	Slots left unfilled
`unavailable`	Yes	Fielded players who were not ACTIVE — injured, suspended and the like
`penalty_points`	Yes	What those empty slots cost, by Comunio's own stated rule of four points each
`out_of_position`	No	Fielded players put in a slot other than the position they play. Reported, not refused: Comunio decides whether it accepts them

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.2Sep 9, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses extensive real behavior: the lineup is replaced, empty slots cost four points each, injured/suspended players can still be fielded, out-of-position selections are passed to Comunio, and certain invalid payloads are refused before being sent. This goes far beyond what annotations alone could convey.

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 dense but efficiently organized: purpose and warning first, then each consequential behavior in its own short paragraph. No sentence is padding, and the length is justified by the number of meaningful edge cases and side effects.

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?

Given the tool's complexity, the description is complete enough for an agent to call it safely. It covers prerequisites, failure conditions, allowed-but-flagged situations, scoring consequences, and timing limits. The existing output schema covers return details such as `ok`, `unavailable`, and `out_of_position`.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the parameter meaning, and it does. It explains that `tactic` values are read as defenders/midfielders/strikers, that players are provided by position, that ids come from `get_squad`, and that a partial lineup is allowed through omitted/nullable position arrays.

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 action and resource: 'Set the manager's formation and starting eleven.' It also immediately disambiguates its effect by saying 'This replaces the current lineup,' which separates it from the many get_* and market tools listed as siblings.

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?

It gives explicit preconditions: confirm with the user before calling, get player ids from `get_squad`, and check `status` in `get_squad` before choosing players. It also gives a temporal boundary ('The lineup can be set again until the matchday starts') and explains rejection cases, so an agent knows when a call would fail.

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