Skip to main content
Glama
Sign In
Fmarzochi

EGC

by Fmarzochi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

session_send

Send an intent or pointer to another live session or broadcast it to every project session; keep large context in project state and send a reference because payloads cap at 16KB.

Instructions

Send an event to another live session (direct) or to every session in the project (broadcast, by omitting to_session). Events carry intents and pointers, not bulk content: payloads are capped at 16KB, so store large context in project state and send a reference. Delivered once per receiving session, kept for 24h.

Input Schema

NameRequiredDescriptionDefault
kindYesShort event type, e.g. 'handoff', 'heads-up', 'done', 'request'.
payloadNoEvent body (max 16KB). Any string including JSON.
session_idNoLeave out: events are always sent as this server's own session, and any other id is refused.
to_sessionNoTarget session id from session_peers; it must be live in this session's project. Omit to broadcast to the whole project.
project_pathNoDefaults to the project this session joined; a different project is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.1.23
    • changedInput schema / properties / project_path / description
      Previous value: -"Project scope for broadcast delivery. Defaults to unscoped."New value: +"Defaults to the project this session joined; a different project is refused."
    • changedInput schema / properties / session_id / description
      Previous value: -"Sender session id. Defaults to the current session."New value: +"Leave out: events are always sent as this server's own session, and any other id is refused."
    • changedInput schema / properties / to_session / description
      Previous value: -"Target session id from session_peers. Omit to broadcast to the whole project."New value: +"Target session id from session_peers; it must be live in this session's project. Omit to broadcast to the whole project."
  2. Addedv1.1.17

TDQS

A4.4/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 well: 16KB payload cap, exactly-once delivery per receiving session, 24h retention, and the fact that a foreign session_id or project_path is refused. It omits any mention of what the call returns or error behavior on a dead target, keeping it short of a 5.

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 tight sentences that front-load the primary action, then delivery modes, then payload constraints and lifetime. Every clause carries operational information; nothing is padding.

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 5-parameter, no-annotation, no-output-schema mutation tool, the description covers mode selection, payload limits, retention, and refusal semantics. The main remaining gap is the response shape / confirmation behavior, which the agent must infer.

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, but the description adds real meaning beyond the schema: omitting to_session means project-wide broadcast, and the 16KB cap is framed as a design constraint with a recommended workaround (send a reference into project state). That is guidance the schema does not supply.

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 ("Send an event to another live session") and immediately distinguishes the two modes — direct vs. broadcast — plus the payload philosophy (intents and pointers, not bulk content). An agent can tell exactly what this does and how it differs from read-side siblings like session_events or session_wait.

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?

Explains the broadcast trigger ("by omitting to_session") and steers large content elsewhere ("store large context in project state and send a reference"). It does not name sibling alternatives for reading or waiting on events, so routing guidance is clear but not complete.

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