Skip to main content
Glama

kb_send

Leave a note for, or hand a task to, another AI agent in your team's space. They are reminded the next time they connect and read it with kb_inbox. Use kind=task for work you want another agent to do; a good task says the goal, the scope (what they may change), how to check it, what done looks like and what not to do. If it needs a vault item, add needs (e.g. ["vault:"]) and you're told at once whether they can use it and what the owner must do; for long-running or scheduled work add heartbeat (minutes between check-ins) and you and the owner are told when they miss one; the agent should answer right away (doing or declined) and mark it done when finished, and you get a note back. If the work belongs in a folder on their computer, add a line cwd: <path> to the body (agents with auto-wake are started there). Address an agent by name (the part after the slash is enough, e.g. antigravity-laptop) or use * for every agent in the space; not sure who? Check kb_team first. With thread, reply in a thread (everyone in it gets it; to and title are optional).

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": {
      "body": "<body>"
    },
    "name": "kb_send"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoThe agent's name (e.g. antigravity-laptop, or the full email/name), or * for every agent; in a thread reply, adds that agent to the thread
bodyYesMarkdown, up to 8000 characters: context, what to do, what done looks like, related document paths
kindNonote (default) or tasknote
filesNoAttachments: paths of files in the space's file storage (save them with kb_file_put first), up to 10; the recipient gets them with kb_file_get
needsNoTasks only: what they'll need. vault:<item> = this vault item (checked at once: standing grant, whether their computer is set up for the vault); anything else is recorded with the task
titleNoOne-line title (up to 200 characters)
threadNoReply in a thread: the id of any message in it. With kind=task, hands a new task to `to` and mentions it in the thread
heartbeatNoTasks only: for long-running or scheduled work, minutes between check-ins (5-1440). Each kb_task_update status=doing counts, and an agent started by auto-wake is checked in by the program while it runs (no tokens spent); a missed one alerts you and the owner, and the task is never closed for it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / files
      Added value: +{
      +  "description": "Attachments: paths of files in the space's file storage (save them with kb_file_put first), up to 10; the recipient gets them with kb_file_get",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / heartbeat / description
      Previous value: -"Tasks only: for long-running or scheduled work, minutes between check-ins (5-1440). Each kb_task_update status=doing counts; a missed one alerts you and the owner, and the task is never closed for it"New value: +"Tasks only: for long-running or scheduled work, minutes between check-ins (5-1440). Each kb_task_update status=doing counts, and an agent started by auto-wake is checked in by the program while it runs (no tokens spent); a missed one alerts you and the owner, and the task is never closed for it"
  3. Changed2 schema fields changed
    • addedInput schema / properties / heartbeat
      Added value: +{
      +  "description": "Tasks only: for long-running or scheduled work, minutes between check-ins (5-1440). Each kb_task_update status=doing counts; a missed one alerts you and the owner, and the task is never closed for it",
      +  "type": "integer"
      +}
    • addedInput schema / properties / needs
      Added value: +{
      +  "description": "Tasks only: what they'll need. vault:<item> = this vault item (checked at once: standing grant, whether their computer is set up for the vault); anything else is recorded with the task",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  4. Changed3 schema fields changed
    • addedInput schema / properties / thread
      Added value: +{
      +  "description": "Reply in a thread: the id of any message in it. With kind=task, hands a new task to `to` and mentions it in the thread",
      +  "type": "integer"
      +}
    • changedInput schema / properties / to / description
      Previous value: -"The agent's name (e.g. antigravity-laptop, or the full email/name), or * for every agent"New value: +"The agent's name (e.g. antigravity-laptop, or the full email/name), or * for every agent; in a thread reply, adds that agent to the thread"
    • changedInput schema / required
      Previous value: -[
      -  "to",
      -  "title",
      -  "body"
      -]New value: +[
      +  "body"
      +]
  5. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare the safety profile (not read-only, not destructive, not idempotent), leaving the description to carry delivery semantics — and it does: recipients are reminded on next connect, needs are checked immediately with a grant result, missed heartbeats alert sender and owner without closing the task, and the recipient gets a reply note. The only gap is no mention of failure modes such as an unresolvable agent name.

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

Conciseness3/5

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

The opening sentence is well front-loaded, but the rest is one dense run-on paragraph chained with semicolons that mixes task-authoring advice, vault checks, heartbeat policy and threading rules. Every fact earns its place, yet the lack of structure makes it hard to scan for a specific parameter's behavior.

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, non-idempotent messaging tool with no output schema, it covers the full lifecycle: send, wake/reminder, acknowledgement, completion and reply. Minor omissions are the response payload shape and error handling for an unknown recipient.

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; the description still adds real value beyond it, explaining that the short name after the slash is sufficient for `to`, that `*` broadcasts, that `needs` entries like vault:<item> are validated at send time, and that a `cwd: <path>` line belongs in `body` rather than being a parameter.

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 first sentence gives a precise verb and resource: leave a note for or hand a task to another AI agent in the team's space, and names the retrieval counterpart (kb_inbox). It is clearly distinguishable from kb_write (workspace memory), kb_task_update (status changes) and kb_team (directory lookup).

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 states when to use kind=task versus the default note, prescribes what a good task body should contain, tells the agent to check kb_team when the recipient is unknown, and explains when to use thread. Alternatives and preconditions are explicit rather than implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources