toli
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| accept_taskA | Take on new work (see list_available_tasks). Returns the request and anything else the peer said. To decline instead, use update_task with rejected. |
| cancel_taskA | Stop a task you delegated. Returns canceled, or the final state it had already reached. |
| delegateA | Start a task on a peer (see list_peers). Returns its task_id, state, and version; if the peer answers right away, the answer is included. Use get_delegated_task_updates to follow it. |
| delete_sessionA | Done with a session: removes it and its tasks, and cancels any still running on their peers. |
| get_delegated_task_updatesA | Where a task you delegated stands: its state, everything the peer said since your last message to it, and its outputs so far. With after_version (the version from the last result you saw), waits up to wait_seconds for something new; no need to if this session gets toli's notifications. For the whole conversation, use get_task_full. |
| get_task_fullB | Everything about a task, delegated or assigned to you: the whole conversation and all outputs. Use it to catch up, not to wait. |
| list_accepted_tasksA | Work you've accepted, newest first: by default what's still in progress, with how many of the peer's messages you haven't responded to. |
| list_available_tasksA | New work peers sent you that you haven't accepted yet, newest first. With wait_seconds, waits for some if there's none. |
| list_delegated_tasksA | Find the tasks you delegated again, newest first, optionally only a session's or only one state (e.g. input-required). |
| list_peersA | The peers you may delegate work to, with what each does and whether it's reachable. |
| replyA | Message the peer on a task you delegated: answer its question (input-required) or tell it something while it works. |
| start_sessionA | Start a session to group related tasks (e.g. "users api"). Pass its session_id to delegate. |
| update_taskA | Everything you tell the peer about work you accepted: post progress (working), ask (input-required: all questions in one message; one open question at a time; with wait_seconds, waits for the answer), finish (completed, with artifacts), or give up (failed). Also declines new work (rejected). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have distinct purposes, and the accepted-vs-delegated direction is well explained, especially for update_task versus reply. Minor overlap remains among get_delegated_task_updates, get_task_full, and list_delegated_tasks, but descriptions distinguish incremental waiting, full catch-up, and listing.
The set mostly follows a predictable snake_case verb_noun pattern: accept_task, cancel_task, delete_session, get_*, list_*, start_session, update_task. The bare verbs reply and delegate are minor deviations but remain understandable.
With 13 tools, the surface is well scoped for multi-agent task delegation, session management, and peer coordination. Each tool covers a distinct lifecycle or discovery operation, and the count stays within a reasonable range.
The set covers peer discovery, session creation/deletion, task delegation, acceptance, updates, messaging, cancellation, and completion/failure. Minor gaps exist around listing or inspecting sessions and possibly viewing task details before acceptance, but core workflows are covered.