Skip to main content
Glama
Yomiracle

Yomiracle

by Yomiracle
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Trinity Lite

Tests Python 3.10+ License: MIT Release PyPI Yomiracle/trinity-lite MCP server

Local AgentOps for cross-vendor CLI coding agents. Route work, recover state, and accept only with evidence.

Trinity Lite is a local control plane for Codex, Claude Code, Hermes, and custom CLI agents. It connects the tools you already use; it does not ask you to rebuild them inside another framework.

中文 README · Docs · Why Trinity Lite? · Recipes

The problem

You already use more than one capable coding agent. The hard part is no longer starting another agent; it is preserving task truth across tools, recovering after a client disconnects, preventing duplicate work, and deciding when a result is actually accepted. Trinity Lite is that local operations layer.

Related MCP server: BrowserStack MCP server

What it does

  • Route by capability, not name. You describe the task. The router matches it to the right agent — no hardcoded agent names, no fragile dispatch logic. "Implement a rate limiter" lands on the agent you tagged implement. "Review the auth module" goes to the agent tagged review.

  • Give every agent a pull queue. Workers read pending tasks from the shared bus, execute them via CLI, and write results back. Each agent polls on its own schedule. You never copy-paste an output between terminals again.

  • Remember every decision. Every task, status change, result, error, and inter-agent message lands in a local SQLite database. Query who did what, when, and what happened — without setting up a logging pipeline.

  • Review, verify, then accept. orchestrate runs primary work, routes the required review, runs local verification, and writes acceptance evidence back to SQLite.

  • Block footguns before they fire. Self-routes become explicit local-work decisions instead of creating loops. Delegation depth has a hard cap. Working directories must be in the allowlist.

Quick start

30 seconds, no agents required:

pip install trinity-lite
trinity-lite doctor
trinity-lite orchestrate "implement a hello-world function"

Mock agents are built in. You see the full route → work → review → verify → accept cycle before you wire up anything real.

Not another framework

Trinity Lite does not build agents. It operates the agents you already have.

LangGraph and CrewAI give you primitives for building agents from scratch — graph definitions, role abstractions, and tool wrappers. Trinity Lite starts from the opposite end: Claude Code is running in one terminal, Codex is running in another, and their work needs reliable handoff, recovery, independent review, and an acceptance trail. No new agent abstraction. Just local AgentOps for the CLIs you already use.

Who this is for

You are...

Trinity Lite helps you...

An advanced solo developer using two or more agent CLIs

Replace manual terminal handoffs with one durable workflow and evidence trail

A small AI-native engineering team

Separate implementation, review, verification, and acceptance without deploying a control server

A local-first or privacy-sensitive developer

Keep task state in an inspectable SQLite database on your machine

An agent-tool integrator

Connect existing CLIs through a neutral bus and MCP surface

Features

  • Route by capability. Tag agents with implement, review, audit — the router matches tasks to the agent that can do them. No agent names in your dispatch logic.

  • Dispatch directly when you need control. Bypass the router and send a task straight to claude_code or codex. Best of both worlds.

  • Persist everything in SQLite. Tasks, statuses, results, errors, and messages in one local file. Query it with sqlite3 or any tool that speaks SQL.

  • Accept with evidence, not vibes. The review flow records route decisions, review links, verification results, acceptance reasons, and accepted_at in SQLite. A reviewed task is accepted only after the local verifier passes.

  • Isolate agent code edits with git worktrees. Released as a v0.6 preview: trinity-lite worktree creates managed branches and checkouts, records the base commit, and returns diff evidence without touching your main checkout.

  • Run CLI workers on demand. trinity-lite worker codex --once pulls one queued task, executes the agent's command, and writes the result. Run it in a loop, in cron, or by hand.

  • Execute safely, no shell injection. Agent commands are JSON arrays run with shell=False. No string interpolation into a shell. No surprises.

  • Test with mock agents. Mock agents simulate the full cycle without real CLIs. Prototype routing, persistence, and review handoffs first. Wire up real agents later.

  • Guard against runaway delegation. Self-delegation is blocked. Delegation depth is capped. Working directories are allowlisted. Safe by default.

  • Check health in one pass. trinity-lite doctor verifies Python, SQLite, route config, agent config, and publish readiness.

  • Zero core dependencies. The default runtime is Python standard library only. YAML pipelines are available through an optional extra.

  • 150+ tests guarding the surface area. Mock workflows, safety checks, routing, persistence, MCP, and acceptance gates — all covered.

  • Optional model selection hints. Select from your declared model pool with transparent task, tier, and capability rules; no claim of a universal best or cheapest model.

Install

pip install trinity-lite

Python 3.10+. Zero core runtime dependencies. Standard library only unless an optional extra is installed.

Optional extras

pip install "trinity-lite[yaml]"          # YAML pipeline files
pip install "trinity-lite[mcp]"           # MCP server — 13 tools + 3 resources
pip install "trinity-lite[agent-skill]"   # agent-skill-system integration

Workflow example

Route primary work → run the worker → run the reviewer → verify → accept. One command, one audit trail.

trinity-lite orchestrate "implement a rate limiter for the API"

The primary task row records route_json, review_task_id, verification_json, acceptance_status, acceptance_reason, and accepted_at.

Ready for real CLIs when you are:

cp examples/agents.command.example.json agents.local.json
trinity-lite orchestrate "implement a rate limiter for the API" --agents agents.local.json

Prefer manual control? Use the lower-level bus commands:

trinity-lite dispatch-auto "implement a parser"
trinity-lite worker codex --once
trinity-lite tasks

Worktree Preview

This is a v0.6 preview. It manages isolated worktree lifecycle and diff evidence while keeping automatic merge-back out of scope.

Create an isolated checkout for an agent:

trinity-lite worktree create "fix parser bug" --repo . --agent codex
trinity-lite worktree list
trinity-lite worktree diff <task_id>
trinity-lite worktree cleanup <task_id>

Worktree preview records branch, base commit, path, agent id, task id, and diff evidence. It does not merge branches or delete branches by default. See Worktree Parallelism Preview.

MCP server

Turn the task bus into an MCP server. Let any MCP client dispatch, query, and route tasks.

pip install trinity-lite[mcp]
trinity-lite mcp serve

13 tools:

Tool

What it does

trinity_dispatch

Dispatch a task to a specific agent

trinity_dispatch_auto

Dispatch and let the capability router pick the agent

trinity_orchestrate

Run the default review flow or a YAML pipeline

trinity_status

Get the state and result of any task by ID

trinity_latest

Recover the latest task submitted by an agent

trinity_tasks

List recent tasks, filterable by agent

trinity_worker

Run one worker cycle for an agent

trinity_worker_daemon

Start, stop, or inspect a daemon worker

trinity_doctor

Run health and diagnostic checks

trinity_inbox

Read durable messages for an agent

trinity_send

Send a message from one agent to another

trinity_skill_search

Search agent-skill-system for relevant skills

trinity_skill_load

Load the full content of a named skill

3 resources: trinity://health, trinity://tasks/recent, trinity://tasks/{task_id}

If an MCP client disconnects or times out before it displays the task id, call trinity_latest for the source agent, then call trinity_status with the returned primary task id. By default trinity_latest skips secondary review children so recovery lands on the user-facing task.

Acceptance Evidence

trinity-lite orchestrate now writes a local acceptance trail to the task row:

  • route_json: JSON-encoded route decision used for primary dispatch

  • review_task_id and parent_task_id: links between primary work and secondary review

  • gate_status: primary_pending, review_pending, review_passed, review_attention, verification_failed, or accepted

  • verification_json: JSON-encoded local verifier result, defaulting to trinity-lite doctor

  • acceptance_status, acceptance_reason, and accepted_at

If the reviewer reports P0/P1 findings, the flow stops at review_attention. If local verification fails, it stops at verification_failed. accepted_at is written only after the required review and verification pass.

Optional Model Selector

Select from a model pool you control using task complexity and declared capabilities. This is a transparent routing helper, not a universal cost optimizer:

# Auto-detect your available models (zero config)
trinity-lite detect-models

# Or set up interactively (no JSON needed)
trinity-lite setup-models

How it works: Define your model pool with tiers (budget / standard / premium) and strength tags. The selector picks automatically:

Task

→ Tier

→ Model

"Fix typo in README"

budget

cheap model

"Add search endpoint"

budget

cheap model

"Refactor auth module"

standard

mid-tier

"Design microservice architecture"

premium

strongest

Manual call (API usage):

from trinity_lite.model_selector import select_model

result = select_model("Design a rate limiter", task_type="architecture_design")
print(result["model"])  # → a premium model from your configured pool
print(result["reason"]) # → hard_signal:architecture

Custom pool — create ~/.trinity/model_pool.json:

{
  "your-cheap-model": {"tier": "budget", "strengths": ["coding"], "api_type": "anthropic"},
  "your-strong-model": {"tier": "premium", "strengths": ["reasoning", "architecture"], "api_type": "openai"}
}

Works with 1 model, 2 models, or 10 models. No agent names hardcoded.

Links

License

MIT

Available Tools

12 tools
trinity_dispatchA

Create a durable task for one explicit Trinity agent and run one worker cycle for that agent. Use this when the caller already knows the target agent; use trinity_dispatch_auto when routing should choose the agent. This writes to the local task database and may execute the configured agent command; with wait=true it returns the final compact task or a timeout error.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory passed to the task; defaults to the user's home directory.
taskYesTask prompt to persist and deliver to the target agent.
waitNoIf true, block until the task reaches a terminal state or wait_timeout expires.
task_typeNoOptional task type metadata for routing and audit records.
source_agentNoOriginating agent id recorded on the task; defaults to mcp.
target_agentYesExact recipient agent id, such as codex, claude_code, or hermes.
wait_timeoutNoMaximum seconds to wait when wait=true; defaults to the server wait timeout.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false, destructiveHint=false, so the description adds value by disclosing that it writes to the local task database and may execute the agent command. Also mentions wait behavior with return of final task or timeout error. Does not cover all edge cases but sufficient beyond annotations.

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?

Two sentences, front-loaded with core purpose, then usage guidance, then additional behavioral context. No waste, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 params, 2 required, no output schema), the description covers the main behavior, wait functionality, and differentiation. Could mention return format when wait=false, but annotations mitigate the need somewhat.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description does not add meaningful parameter semantics beyond what the schema already provides (e.g., target_agent as 'exact recipient agent id').

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 clearly states it creates a durable task for an explicit Trinity agent and runs one worker cycle. The verb 'create' and the resource 'durable task' are specific. It differentiates from the sibling trinity_dispatch_auto by noting this is for when the caller knows the target agent.

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?

Explicitly states when to use this tool: 'Use this when the caller already knows the target agent; use trinity_dispatch_auto when routing should choose the agent.' This provides clear guidance on tool selection among siblings.

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

trinity_dispatch_autoA

Resolve the best Trinity agent with the local route table, create a durable task, and run one worker cycle. Use this when the caller has a task but should not pick the agent manually; use trinity_dispatch for an explicit target. This writes route evidence and task state to the local database and may execute the selected agent command; the result includes compact task and route metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory passed to the selected agent; defaults to the user's home directory.
taskYesTask prompt used for route selection and delivery.
waitNoIf true, block until the routed task reaches a terminal state or wait_timeout expires.
task_typeNoOptional task type hint that can override or narrow route matching.
source_agentNoOriginating agent id recorded on the task; defaults to mcp.
wait_timeoutNoMaximum seconds to wait when wait=true; defaults to the server wait timeout.
previous_agentNoAgent id to avoid when resolving opposite-review or retry routes.

TDQS

A4.4/5.0
Behavior4/5

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

Discloses that it writes to the database and may execute an agent command, which aligns with annotations (readOnlyHint=false, destructiveHint=false). Adds context beyond annotations, though could elaborate on execution side effects.

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?

Three concise sentences front-load the core purpose and usage guidance without extraneous detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main behavior, usage guidance, and result information. Lacks details on error cases or failure modes, but annotations and schema partially compensate.

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

Parameters3/5

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

Schema description coverage is 100%, providing descriptions for all parameters. The tool description adds no additional parameter-level meaning beyond what the schema already provides.

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 clearly states the tool's action: resolve an agent, create a task, and run a worker cycle. It distinguishes itself from sibling trinity_dispatch by noting automatic vs explicit agent selection.

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?

Explicitly guides when to use this tool (caller has a task but should not pick agent manually) and when to use the alternative trinity_dispatch (explicit target).

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

trinity_doctorA
Read-onlyIdempotent

Run Trinity Lite health, configuration, database, publish-readiness, and runtime hygiene checks. Use this before release, after setup changes, or when routing and worker behavior looks wrong. This is read-only: it scans configured files, database state, optional repository roots, and retired ports, then returns a structured health report.

ParametersJSON Schema
NameRequiredDescriptionDefault
scan_rootNoOptional repository root for publish-readiness and packaging checks.
runtime_rootNoOptional runtime directory to inspect for local hygiene checks.
retired_portsNoOptional TCP ports that should be unused; listening ports are reported as hygiene issues.

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already indicate readOnly=true and destructive=false. The description adds that it scans configured files, database state, and returns a health report, but does not elaborate on side effects or limitations beyond the annotations.

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?

Three focused sentences: first states action, second gives usage guidance, third confirms read-only nature and scope. No unnecessary words, front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all essential aspects: what checks are performed, when to use, read-only nature, and return type (structured health report). No output schema is present, but the description sufficiently describes outcomes. Slight gap in not detailing the report structure.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already describes each parameter. The description adds minimal extra meaning, only mentioning 'optional repository roots' and 'retired ports' which map to parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool performs health, configuration, database, and runtime checks. It distinguishes itself from sibling tools by focusing on diagnostics rather than dispatch, orchestration, or skill operations, but does not explicitly name siblings.

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?

Explicitly recommends use before release, after setup changes, or when behavior seems wrong. Provides clear context but does not mention when to avoid using the tool or list alternatives.

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

trinity_inboxA

Read durable inter-agent messages addressed to one agent from the local Trinity database. Use this to recover completed work, review notes, or follow-up messages; use trinity_send to create a new message. By default it reads unread messages, but mark_read=true updates message read state; it returns message records.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentYesRecipient agent id whose inbox should be read.
limitNoMaximum messages to return; defaults to 20 and is capped by the server.
mark_readNoWhen true, mark returned messages as read after fetching them.
unread_onlyNoWhen true, return only unread messages; defaults to true.

TDQS

A4.4/5.0
Behavior4/5

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

Discloses that mark_read=true updates message read state, which is a mutation beyond the primary read operation. However, does not mention other potential side effects or implications like authentication requirements or data persistence details.

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?

Three sentences cover purpose, usage guidance, and default behavior. No wasted words; information is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately describes the tool's functionality and return of 'message records' given no output schema. Could improve by indicating the structure of returned records or error conditions, but sufficient for a simple read tool.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description restates default behavior for unread_only and mark_read, but adds no new semantic information beyond what the schema already provides.

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?

Clearly states the verb 'Read', resource 'durable inter-agent messages', and source 'local Trinity database'. Explicitly contrasts with sibling 'trinity_send' to avoid confusion.

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?

Provides explicit use cases: 'recover completed work, review notes, or follow-up messages' and directs to 'trinity_send' for creating new messages. Also clarifies default behavior for unread messages.

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

trinity_orchestrateA

Run a multi-step Trinity workflow from a pipeline file or the built-in implement-then-review flow. Use this for work that needs sequencing, review gates, or multiple task records; use dispatch tools for a single agent task. This creates and updates local task records and may execute one or more configured agent commands; it returns pipeline or review-flow evidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory used by pipeline steps or review flow; defaults to home.
taskYesTop-level task prompt for the pipeline or review flow.
waitNoReserved for wait-aware clients; pipeline workers run in-process.
pipelineNoPath to a YAML pipeline file; omit to run the default review flow.
task_typeNoOptional task type hint for the default review flow route.
source_agentNoOriginating agent id recorded on created tasks; defaults to mcp.
wait_timeoutNoReserved wait timeout in seconds for wait-aware orchestration clients.
previous_agentNoAgent id to avoid when resolving reviewer or retry routes.

TDQS

A4.8/5.0
Behavior5/5

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

Discloses key behaviors: creates/updates local task records, may execute agent commands, returns evidence. Annotations already indicate readOnlyHint=false and openWorldHint=true, but description adds specific context about local records and commands, with no contradictions.

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?

Concise and front-loaded: first sentence defines core function, second gives usage guidance, third adds behavioral details. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, behavioral effects, and return value ('evidence'). Without an output schema, more detail on evidence format would be helpful, but given open-worldHint and complexity, it is adequate for agent selection and 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?

Schema coverage is 100%, so baseline is 3. The description adds extra context beyond schema descriptions, such as 'reserved for wait-aware clients' for wait/wait_timeout and 'agent id to avoid' for previous_agent, providing useful nuance.

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 clearly states the tool runs a multi-step Trinity workflow, distinguishes two modes (pipeline file or review flow), and explicitly contrasts with dispatch tools for single tasks. The verb 'orchestrate' aligns with the description.

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?

Provides explicit guidance: 'Use this for work that needs sequencing, review gates... use dispatch tools for a single agent task.' This clearly defines when and when not to use, with named alternatives.

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

trinity_sendA

Write a durable message from one Trinity agent to another agent's inbox. Use this for follow-up context, review handoffs, or task-linked notes; use trinity_dispatch to create executable work. This writes to the local message database, does not run a worker, and returns the stored message record.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesMessage body to persist in the target inbox.
task_idNoOptional associated task id for threading or audit context.
source_agentNoSender agent id recorded on the message; defaults to mcp.
target_agentYesRecipient agent id that will receive the inbox message.

TDQS

A4.6/5.0
Behavior5/5

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

Annotated with readOnlyHint=false and destructiveHint=false; the description adds that it 'writes to the local message database, does not run a worker, and returns the stored message record,' which clarifies its safe, non-destructive write nature beyond what annotations provide.

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?

Two sentences that efficiently convey purpose, usage, and behavioral notes. Front-loaded with the primary action, no redundant or extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the core action, differentiation, and behavioral transparency. Since no output schema exists, the description mentions the return value ('stored message record'). It does not address error conditions or prerequisites (like agent existence), but for a simple tool, it is largely complete.

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

Parameters3/5

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

Schema coverage is 100% so baseline is 3. The description does not add additional meaning or constraints beyond the parameter descriptions already in the schema. It mentions 'message' and 'target_agent' but no extra format, defaults, or behavior details.

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 clearly states the action ('Write a durable message') and the target ('to another agent's inbox'). It distinguishes from the sibling 'trinity_dispatch' by specifying that 'trinity_send' is for follow-up context, while 'trinity_dispatch' creates executable work.

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?

Explicitly provides when to use ('follow-up context, review handoffs, or task-linked notes') and when not to use ('use trinity_dispatch to create executable work'), with a clear alternative sibling tool named.

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

trinity_skill_loadA
Read-onlyIdempotent

Load the full SKILL.md, memory, schema, keywords, and generated system prompt for one exact skill name. Use this after trinity_skill_search identifies the correct skill; do not use it for broad discovery. This is read-only and returns the skill bundle, or a not-found response with available skill names when possible.

ParametersJSON Schema
NameRequiredDescriptionDefault
skill_nameYesExact skill name to load from the local skill bank.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds context about return values ('skill bundle' or 'not-found response with available skill names'), which goes beyond the annotations. No contradictions.

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?

Three sentences, each serving a distinct purpose: action, usage guidance, and outcome. No wasted words, front-loaded with the primary function.

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 simplicity (one parameter, no output schema, rich annotations), the description fully covers purpose, usage, and return behavior. It is complete and leaves no ambiguity.

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

Parameters3/5

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

Schema coverage is 100% and the parameter description 'Exact skill name to load from the local skill bank' is already clear. The tool description adds minimal extra meaning beyond reinforcing 'exact' and 'local skill bank', so baseline 3 is appropriate.

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 clearly states the verb 'Load' and the resource 'full SKILL.md, memory, schema, keywords, and generated system prompt for one exact skill name'. It distinguishes from sibling tools by mentioning 'after trinity_skill_search identifies the correct skill; do not use it for broad discovery'.

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?

Explicitly states when to use: after trinity_skill_search identifies the correct skill. Also provides an exclusion: 'do not use it for broad discovery', and implicitly references the sibling tool for discovery.

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

trinity_statusA
Read-onlyIdempotent

Read the current state, result, route evidence, and acceptance metadata for one task id. Use this after dispatch or orchestration to poll progress or recover a result after a timeout. This is read-only and does not run workers or mark messages as read; it returns a compact task object or task-not-found error.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesTask identifier returned by dispatch, orchestration, or task listing.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context by stating it returns a compact task object or task-not-found error, and confirms it does not run workers or mark messages. No contradiction.

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 two sentences, each adding value. First sentence states purpose, second gives usage and behavioral constraints. No wasted words.

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?

The tool has one parameter and no output schema. The description covers what it returns (compact task object or error), its read-only nature, and its place in the workflow (after dispatch/orchestration). Complete for a simple read tool.

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

Parameters3/5

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

Schema coverage is 100%, so the parameter 'task_id' is fully described in the schema. The description adds minimal extra meaning beyond referencing the source of the identifier ('returned by dispatch, orchestration, or task listing'), which is helpful but not essential. Baseline 3 is appropriate.

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 the specific verb 'Read' and identifies the resource as 'current state, result, route evidence, and acceptance metadata for one task id'. It clearly distinguishes from siblings by stating it is for after dispatch or orchestration, not for dispatching or running workers.

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?

Explicitly states 'Use this after dispatch or orchestration to poll progress or recover a result after a timeout.' Also clarifies that it is read-only and does not run workers or mark messages as read, helping the agent choose the right tool.

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

trinity_tasksA
Read-onlyIdempotent

List recent durable task records, optionally filtered by source or target agent. Use this to inspect queue history or find a task id before calling trinity_status. This is read-only, does not run workers, and returns compact task objects in recent-first order.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentNoOptional agent id to match against source_agent or target_agent.
limitNoMaximum tasks to return; defaults to 20 and is capped by the server.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. The description adds that it returns compact task objects in recent-first order, which is useful behavioral context beyond annotations.

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?

Two sentences, no wasted words. First sentence states purpose and filtering, second sentence gives usage guidance and behavior. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool, the description covers return order and compactness. No output schema exists, but the description provides adequate context. Could mention more about the task object fields, but not necessary for basic use.

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

Parameters3/5

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

Schema coverage is 100%, and the description does not add any parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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 'list' and resource 'durable task records', with optional filtering. It distinguishes from siblings by mentioning it's read-only, does not run workers, and can be used before trinity_status.

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 explicit use cases: inspect queue history, find task id before calling trinity_status. It also clarifies it's read-only and does not run workers. However, it does not explicitly state when not to use or name alternative tools.

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

trinity_workerA

Run one local worker cycle for a named agent and process one queued task if available. Use this to manually drain the queue or retry a specific queued task; use trinity_worker_daemon for a background worker. This may execute the agent command and update task state; it returns no_task or the compact processed task.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentYesAgent id whose queue should be processed.
task_idNoOptional specific queued task id to process instead of the next task.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations indicate non-readonly, non-idempotent, non-destructive, and open world. The description adds behavioral context: 'may execute the agent command and update task state' and specifies return values ('no_task or the compact processed task'), which goes beyond the basic hints.

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 two sentences, each serving a purpose: the first states the core function, the second adds usage guidance and outcome. It is front-loaded and contains no unnecessary words.

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 simple parameter set (2 params, 100% schema coverage, no output schema), the description covers all important aspects: what the tool does, when to use it, and what it returns (no_task or processed task). No gaps are evident.

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

Parameters3/5

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

Schema description coverage is 100%, so the description adds no new information about parameters beyond what the schema already provides. The description restates that 'agent' is the agent id and 'task_id' is optional for specific task, but this does not enhance understanding beyond the schema.

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 specific verbs 'run' and 'process' to describe the tool's action on a named agent and queued task. It clearly distinguishes from the sibling trinity_worker_daemon by stating 'use trinity_worker_daemon for a background worker', making the purpose unambiguous.

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 explicitly states when to use this tool: 'Use this to manually drain the queue or retry a specific queued task' and provides an alternative: 'use trinity_worker_daemon for a background worker'. This gives clear guidance on context.

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

trinity_worker_daemonA

Start, stop, or check the local background worker process for one agent. Use status for a process check, start to keep an agent queue draining, and stop to terminate that daemon. Start and stop modify local process state and PID files; responses include running, started, stopped, pid, and pid_file fields.

ParametersJSON Schema
NameRequiredDescriptionDefault
agentYesAgent id whose worker daemon should be controlled.
actionYesDaemon action: status checks process state, start launches, stop terminates.

TDQS

A4/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false, and the description discloses that start/stop modify local process state and PID files. It also lists response fields (running, started, stopped, pid, pid_file). This adds meaningful context beyond annotations, though it could mention side effects or required permissions.

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 extremely concise—two sentences that front-load the purpose and quickly elaborate on actions and effects. No superfluous words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description adequately covers the core behavior. It mentions response fields, which partially compensates for missing output schema. However, it could describe the process state lifecycle or interactions with other tools.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are already well-documented. The description rephrases the action enum values (status, start, stop) but does not add substantial new meaning beyond what the schema provides. Baseline score of 3 is appropriate.

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 clearly states the tool's purpose: starting, stopping, or checking a local background worker process. It uses specific verbs (start, stop, status) and identifies the resource (local background worker process for one agent). This distinguishes it from sibling tools like trinity_worker, which likely manage other worker aspects.

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

Usage Guidelines3/5

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

The description provides usage guidance for each action (status for check, start for queue draining, stop for termination) but does not explicitly compare to sibling tools or indicate when not to use this tool. Context is present but limited.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 12 tool updatesv0.5.3
    • Changedtrinity_dispatch7 fields changed
      • changedInput schema / properties / cwd / description
        Previous value: -"Working directory (default: $HOME)"New value: +"Working directory passed to the task; defaults to the user's home directory."
      • changedInput schema / properties / source_agent / description
        Previous value: -"Originating agent id (default: mcp)"New value: +"Originating agent id recorded on the task; defaults to mcp."
      • changedInput schema / properties / target_agent / description
        Previous value: -"Agent id to receive the task"New value: +"Exact recipient agent id, such as codex, claude_code, or hermes."
      • changedInput schema / properties / task / description
        Previous value: -"Task prompt"New value: +"Task prompt to persist and deliver to the target agent."
      • changedInput schema / properties / task_type / description
        Previous value: -"Task type for routing"New value: +"Optional task type metadata for routing and audit records."
      • changedInput schema / properties / wait / description
        Previous value: -"Block until task completes"New value: +"If true, block until the task reaches a terminal state or wait_timeout expires."
      • changedInput schema / properties / wait_timeout / description
        Previous value: -"Timeout in seconds for wait"New value: +"Maximum seconds to wait when wait=true; defaults to the server wait timeout."
    • Changedtrinity_dispatch_auto7 fields changed
      • changedInput schema / properties / cwd / description
        Previous value: -"Working directory (default: $HOME)"New value: +"Working directory passed to the selected agent; defaults to the user's home directory."
      • changedInput schema / properties / previous_agent / description
        Previous value: -"Previous agent for avoidance"New value: +"Agent id to avoid when resolving opposite-review or retry routes."
      • changedInput schema / properties / source_agent / description
        Previous value: -"Originating agent id (default: mcp)"New value: +"Originating agent id recorded on the task; defaults to mcp."
      • changedInput schema / properties / task / description
        Previous value: -"Task prompt"New value: +"Task prompt used for route selection and delivery."
      • changedInput schema / properties / task_type / description
        Previous value: -"Task type hint"New value: +"Optional task type hint that can override or narrow route matching."
      • changedInput schema / properties / wait / description
        Previous value: -"Block until task completes"New value: +"If true, block until the routed task reaches a terminal state or wait_timeout expires."
      • changedInput schema / properties / wait_timeout / description
        Previous value: -"Timeout in seconds for wait"New value: +"Maximum seconds to wait when wait=true; defaults to the server wait timeout."
    • Changedtrinity_doctor3 fields changed
      • changedInput schema / properties / retired_ports / description
        Previous value: -"Ports that should not be listening"New value: +"Optional TCP ports that should be unused; listening ports are reported as hygiene issues."
      • changedInput schema / properties / runtime_root / description
        Previous value: -"Runtime directory for hygiene checks"New value: +"Optional runtime directory to inspect for local hygiene checks."
      • changedInput schema / properties / scan_root / description
        Previous value: -"Repository root for publish-readiness scan"New value: +"Optional repository root for publish-readiness and packaging checks."
    • Changedtrinity_inbox4 fields changed
      • changedInput schema / properties / agent / description
        Previous value: -"Agent whose inbox to read"New value: +"Recipient agent id whose inbox should be read."
      • changedInput schema / properties / limit / description
        Previous value: -"Maximum messages to return (default: 20)"New value: +"Maximum messages to return; defaults to 20 and is capped by the server."
      • changedInput schema / properties / mark_read / description
        Previous value: -"Mark returned messages as read"New value: +"When true, mark returned messages as read after fetching them."
      • changedInput schema / properties / unread_only / description
        Previous value: -"Return only unread messages (default: true)"New value: +"When true, return only unread messages; defaults to true."
    • Changedtrinity_orchestrate8 fields changed
      • changedInput schema / properties / cwd / description
        Previous value: -"Working directory (default: $HOME)"New value: +"Working directory used by pipeline steps or review flow; defaults to home."
      • changedInput schema / properties / pipeline / description
        Previous value: -"Path to pipeline YAML file"New value: +"Path to a YAML pipeline file; omit to run the default review flow."
      • changedInput schema / properties / previous_agent / description
        Previous value: -"Previous agent for avoidance"New value: +"Agent id to avoid when resolving reviewer or retry routes."
      • changedInput schema / properties / source_agent / description
        Previous value: -"Originating agent id (default: mcp)"New value: +"Originating agent id recorded on created tasks; defaults to mcp."
      • changedInput schema / properties / task / description
        Previous value: -"Task prompt"New value: +"Top-level task prompt for the pipeline or review flow."
      • changedInput schema / properties / task_type / description
        Previous value: -"Task type hint"New value: +"Optional task type hint for the default review flow route."
      • changedInput schema / properties / wait / description
        Previous value: -"Block until task completes"New value: +"Reserved for wait-aware clients; pipeline workers run in-process."
      • changedInput schema / properties / wait_timeout / description
        Previous value: -"Timeout in seconds for wait"New value: +"Reserved wait timeout in seconds for wait-aware orchestration clients."
    • Changedtrinity_send4 fields changed
      • changedInput schema / properties / message / description
        Previous value: -"Message body"New value: +"Message body to persist in the target inbox."
      • changedInput schema / properties / source_agent / description
        Previous value: -"Sender agent id (default: mcp)"New value: +"Sender agent id recorded on the message; defaults to mcp."
      • changedInput schema / properties / target_agent / description
        Previous value: -"Recipient agent id"New value: +"Recipient agent id that will receive the inbox message."
      • changedInput schema / properties / task_id / description
        Previous value: -"Associated task id"New value: +"Optional associated task id for threading or audit context."
    • Changedtrinity_skill_load1 field changed
      • changedInput schema / properties / skill_name / description
        Previous value: -"Exact name of the skill to load"New value: +"Exact skill name to load from the local skill bank."
    • Changedtrinity_skill_search2 fields changed
      • changedInput schema / properties / limit / description
        Previous value: -"Maximum results (default: 5, max: 20)"New value: +"Maximum results to return; defaults to 5 and is capped at 20."
      • changedInput schema / properties / query / description
        Previous value: -"Task description or keyword query"New value: +"Task description or keywords used to rank matching skills."
    • Changedtrinity_status1 field changed
      • changedInput schema / properties / task_id / description
        Previous value: -"Task identifier"New value: +"Task identifier returned by dispatch, orchestration, or task listing."
    • Changedtrinity_tasks2 fields changed
      • changedInput schema / properties / agent / description
        Previous value: -"Filter by agent (source or target)"New value: +"Optional agent id to match against source_agent or target_agent."
      • changedInput schema / properties / limit / description
        Previous value: -"Maximum tasks to return (default: 20)"New value: +"Maximum tasks to return; defaults to 20 and is capped by the server."
    • Changedtrinity_worker2 fields changed
      • changedInput schema / properties / agent / description
        Previous value: -"Agent id to run worker for"New value: +"Agent id whose queue should be processed."
      • changedInput schema / properties / task_id / description
        Previous value: -"Process a specific queued task"New value: +"Optional specific queued task id to process instead of the next task."
    • Changedtrinity_worker_daemon2 fields changed
      • changedInput schema / properties / action / description
        Previous value: -"Action to perform"New value: +"Daemon action: status checks process state, start launches, stop terminates."
      • changedInput schema / properties / agent / description
        Previous value: -"Agent name"New value: +"Agent id whose worker daemon should be controlled."
  2. 12 tool updatesv0.5.2
    • First observedtrinity_dispatch
    • First observedtrinity_dispatch_auto
    • First observedtrinity_doctor
    • First observedtrinity_inbox
    • First observedtrinity_orchestrate
    • First observedtrinity_send
    • First observedtrinity_skill_load
    • First observedtrinity_skill_search
    • First observedtrinity_status
    • First observedtrinity_tasks
    • First observedtrinity_worker
    • First observedtrinity_worker_daemon
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Every tool has a clear, distinct purpose. Dispatch pair (explicit/auto) is well-differentiated by naming and descriptions. Other tools like doctor, inbox, send, status, tasks, etc. are uniquely scoped with no overlap.

Naming Consistency5/5

All tools follow the 'trinity_' prefix with a consistent verb_noun pattern (e.g., trinity_dispatch, trinity_skill_load, trinity_worker_daemon). No mixed conventions or ambiguous names.

Tool Count5/5

With 12 tools, the set is well-scoped for a multi-agent orchestration server. It covers dispatching, messaging, skills, health, worker management without being excessive or thin.

Completeness4/5

The tool surface covers the core lifecycle: task creation, dispatching, orchestration, messaging, skill management, and monitoring. Minor gaps exist (e.g., no explicit task cancellation or message deletion), but these are not critical for the domain.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yomiracle/trinity-lite'

If you have feedback or need assistance with the MCP directory API, please join our Discord server