Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.
Call match_tasks_to_agents
Supply unique nonempty agent IDs and an object mapping each nonempty task ID to its eligible agents. Eligibility lists must contain unique known agents. Each task and agent can appear in at most one assignment. The algorithm maximizes assignment count; it does not minimize cost, prioritize tasks, balance workload or infer skills. It may reassign an earlier task along an alternating path to fit a later task. Input task and eligibility-list order break choices between equally large matchings; outputs follow task input order and unassigned agents follow agent input order. Empty lists and empty task sets are allowed. A task with no eligible agents remains unassigned. This is a stateless matching calculation, not dispatch, reservation, authentication, consent or a shared lock. Eligibility must already reflect your own availability and policy. It does not schedule durations, dependency order or multiple tasks per agent.
The HTTP and MCP interfaces execute the same implementation. Validation errors are returned explicitly. See the tool notes above for its supported inputs and behavior.
An alternating assignment avoids a greedy eligibility dead end
Read the explanation
The fixture lists three agents: generalist, builder and reviewer, with four tasks. Build accepts generalist or builder, deploy only generalist, review only reviewer, and audit no agent. Four eligibility edges connect the task and agent sets. At sixty pixels per count tasks measure two hundred forty, agents one hundred eighty and eligibility edges two hundred forty. The input declares eligibility; the tool does not infer skills or actual availability, obtain permission or reserve an agent. Empty eligibility explicitly leaves a task unmatched. A greedy choice assigning generalist to build blocks deploy. Reassigning build to builder frees generalist for deploy, while reviewer handles review. This creates three matches rather than the greedy example two, adding one. At eighty pixels per match greedy two measures one hundred sixty, maximum three two hundred forty and improvement one eighty. This alternating-path example is manually derived from the fixture, not a backend execution. It maximizes cardinality only and does not optimize cost, balance workload or choose the best quality agent. Three matched tasks out of four leave audit unassigned, because its eligibility list is empty. At sixty pixels per task matched three measures one hundred eighty, unassigned one sixty and total four two hundred forty. All three agents can be assigned in this example. Input ordering breaks ties among equally large solutions and outputs retain task input order. Matching is stateless; it does not schedule durations, prerequisites or multiple tasks per agent. The shared local client is missing, so no HTTP result, MCP response or real dispatch is claimed; native argument editing and original layout remain independently checkable.
Understanding Maximum One-to-One Task Matching
How does the tool find the maximum number of task-agent assignments when simple greedy matching would leave eligible tasks unassigned?
The tool solves maximum-cardinality bipartite matching between discrete tasks and agents using explicit eligibility lists. When an eligible task cannot be directly paired because its candidate agents are already occupied, the solver traces an alternating augmenting path using breadth-first search. If an augmenting path ending at an unassigned agent is discovered, the assignments along that path are flipped—reassigning prior tasks to other eligible agents so the incoming task can also be matched.
This endpoint evaluates unweighted maximum bipartite matching; it does not solve minimum-cost assignment, balance agent workload, prioritize tasks, enforce temporal concurrency, or schedule duration dependencies. Each agent accepts at most one task per invocation, and all eligibility lists must be pre-filtered with unique, valid agent IDs.
Try a worked example
Submit the default arguments by clicking Run tool. The solver attempts to pair build, deploy, review, and audit across generalist, builder, and reviewer. Deploy can only be fulfilled by generalist, while build is eligible for either generalist or builder. Rather than trapping generalist on build, the alternating path shifts build to builder, allowing deploy to claim generalist and review to take reviewer. The result updates to matched_count of 3, leaving audit unassigned and zero unassigned agents.
Bipartite Augmentation Mechanism
The implementation processes tasks in the order provided under eligibility. For each task, a breadth-first queue searches reachable agent candidates. If a candidate agent is already matched to another task, the algorithm visits that task's alternatives, recording predecessors in a parent mapping until an unassigned agent is found.
Once an unassigned agent terminates the path, the algorithm walks backward through the parent tree, swapping previous pairings to their newly discovered alternatives. If no path reaches an open agent, the current task remains unassigned without altering existing pairings.
Stateless Processing Scope
Execution is stateless and synchronous: the service does not persist assignments, establish mutual exclusion locks, or trigger background job queues. Callers are responsible for converting output pairings into live task dispatches and handling execution lifecycle.