Skip to main content
Glama
Sign In
kernl

kernl

by fastslack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kernel_agents_post_to_colleague

Sends an async message to another agent's inbox so blockers, clarifications, and hand-backs are delivered the next time that colleague runs.

Instructions

Leave an async message in another agent's inbox. Works ACROSS offices — every agent can reach every other agent. The recipient does NOT run immediately — the message appears as a 'PENDING REQUESTS FROM COLLEAGUES' block in their system prompt the next time they run, then is marked read. Use this for blockers, clarifications and hand-backs between agents. For a doubt that needs a decision from above use kernel_agents_ask_supervisor. For blocking one-shot questions use kernel_agents_invoke; for group deliberation use kernel_agents_call_meeting. To continue a thread, pass in_reply_to_message_id (the conversation-message id of the turn you are replying to) or an explicit conversation_id. To signal disagreement with something the recipient (or a peer) said, set role: "counter" — 2+ counters from different agents on the same conversation auto-opens a debate.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "subject": "<subject>",
      "body": "<body>"
    },
    "name": "kernel_agents_post_to_colleague"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyYesMessage body (markdown OK). Include context and what action you want.
roleNoSemantic role of this turn. Default 'stmt'. Use 'counter' to disagree.
subjectYesOne-line subject. Max 300 chars.
to_agent_idNoUUID of the recipient. Preferred.
to_agent_nameNoExact agent name. Your own office is searched first, then the whole fleet (the name must be unique there).
conversation_idNoExplicit conversation id to append to. Omit to find-or-create by topic+participants.
__caller_agent_idNo[internal] injected by the agent executor when this tool is invoked from an agent run. Not meant to be set by external callers.
in_reply_to_message_idNoConversation-message id you are replying to. Keeps the thread together.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it discloses the asynchronous delivery model, that the recipient will not run immediately, that the message surfaces as a 'PENDING REQUESTS FROM COLLEAGUES' block and is then marked read, and that 2+ counters auto-open a debate. The main gap is that it never says what the caller receives back (message id, conversation id, or delivery status) for a fire-and-forget write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and its async consequence before alternatives and parameters, and every sentence carries information. It is dense and slightly long, with the alternative-tool routing packed into mid-paragraph clauses, but nothing is genuinely redundant.

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 an 8-parameter mutation tool with no output schema, the definition covers delivery timing, thread continuation, role semantics and sibling routing, which is most of what an agent needs. It leaves undefined the caller-visible return value and failure modes (e.g. ambiguous or unknown recipient name given the fleet-wide search).

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 already 100%, so the baseline is 3, but the description adds genuine meaning beyond it: it explains the thread-continuation purpose of in_reply_to_message_id and conversation_id, and the disagreement semantics of role: "counter" including the auto-debate side effect, which the enum alone does not convey.

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?

States a specific verb and resource ("Leave an async message in another agent's inbox") plus the cross-office scope, which is the key differentiator from local-only messaging. It explicitly contrasts itself with kernel_agents_ask_supervisor, kernel_agents_invoke and kernel_agents_call_meeting, so an agent can pick without opening any schema.

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?

Gives concrete when-to-use cases (blockers, clarifications, hand-backs) and names three alternatives with the condition that selects each (decision from above, blocking one-shot, group deliberation). It also explains how to continue a thread and how to signal disagreement, so both routing and invocation choices are covered.

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

Deploy Server

Other Tools