Skip to main content
Glama
ShellFrameAI

AgentSecure Community

Official
by ShellFrameAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

agentsecure.send_message

Send a policy-checked message to another agent in the local Community Mesh store, storing only a redacted body and summary. Returns delivery status or a blocked reason with the next allowed step.

Instructions

Create a new unread message in the local Community Mesh store for another agent. Checks the sender's send_message policy and resource approval requirements. Returns blocked=false and message (including message_id/thread_id), or blocked=true with reason and allowed_next_step. Stores/audits a redacted body, digest, and heuristic summary, not the full text; never put secrets in the input. Does not launch/wake the recipient, contact a remote service, or prove the recipient read it. Use agentsecure.reply_message to respond in an existing thread. Example: {"from_agent": "frontend-agent", "to": "backend-agent", "body": "Please review src/app.py."}.

Input Schema

NameRequiredDescriptionDefault
toYesNon-empty recipient Mesh agent ID, not an email address. Local registration is not required; delivery means a record in the shared local store.
bodyYesMessage text to summarize/hash. The body field is stored as [redacted], but a heuristic summary of up to 120 characters may remain. Do not include secrets; full text cannot later be retrieved.
typeNoMessage category; defaults to question. Supported: question, reply, approval_request, approval_decision, policy_denial, system_notice, ownership_request, resource_comment, task_handoff. A category alone does not create or resolve an approval.
subjectNoOptional subject, default empty. Whitespace is collapsed and text is truncated to 120 characters or redacted by heuristics. Do not include secrets.
resourceNoOptional resource metadata; defaults to {}. Stored/returned fields are limited to action, environment, id, path, provider, repo, team, and type. Use non-secret scalar values or lists; other keys and top-level object-valued fields are dropped; list items are converted to scalars, and strings are truncated/redacted. Example: {"type": "code_file", "path": "src/app.py"}. For policy checks, the entire supplied object is examined for sensitive-action markers.
from_agentYesNon-empty Mesh agent ID, e.g. backend-agent. Pass this session's AGENTSECURE_AGENT_ID value when set; it is not read automatically. IDs are caller-supplied local labels, not authentication credentials.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / body / description
      Added value: +"Message text to summarize/hash. The body field is stored as [redacted], but a heuristic summary of up to 120 characters may remain. Do not include secrets; full text cannot later be retrieved."
    • addedInput schema / properties / from_agent / description
      Added value: +"Non-empty Mesh agent ID, e.g. backend-agent. Pass this session's AGENTSECURE_AGENT_ID value when set; it is not read automatically. IDs are caller-supplied local labels, not authentication credentials."
    • addedInput schema / properties / resource / description
      Added value: +"Optional resource metadata; defaults to {}. Stored/returned fields are limited to action, environment, id, path, provider, repo, team, and type. Use non-secret scalar values or lists; other keys and top-level object-valued fields are dropped; list items are converted to scalars, and strings are truncated/redacted. Example: {\"type\": \"code_file\", \"path\": \"src/app.py\"}. For policy checks, the entire supplied object is examined for sensitive-action markers."
    • addedInput schema / properties / subject / description
      Added value: +"Optional subject, default empty. Whitespace is collapsed and text is truncated to 120 characters or redacted by heuristics. Do not include secrets."
    • addedInput schema / properties / to / description
      Added value: +"Non-empty recipient Mesh agent ID, not an email address. Local registration is not required; delivery means a record in the shared local store."
    • addedInput schema / properties / type / description
      Added value: +"Message category; defaults to question. Supported: question, reply, approval_request, approval_decision, policy_denial, system_notice, ownership_request, resource_comment, task_handoff. A category alone does not create or resolve an approval."
  2. First observed

TDQS

A4.6/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 it well: it discloses both response branches (blocked=false with message/message_id/thread_id, blocked=true with reason and allowed_next_step), the redaction/audit behavior (redacted body, digest, heuristic summary retained), and the security warning about secrets. It stops short of covering failure modes such as unknown recipient IDs or policy-denial specifics, which keeps it at 4 rather than 5.

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?

Behavior (what is stored) and the safety warning are front-loaded before the sibling pointer and example, which is the right ordering. It is dense but readable; the secrets warning and redaction detail are stated twice (description and body/from_agent schema), a minor redundancy in an otherwise tight definition.

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?

There is no output schema, and the description compensates by describing the exact return shape for both success and blocked outcomes. With a nested 'resource' object and six parameters, it covers the operational picture an agent needs: policy gating, non-delivery semantics, and irreversibility of the stored body.

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 description coverage is 100%, so baseline is 3. The description still adds value by supplying a concrete worked example ({"from_agent": "frontend-agent", "to": "backend-agent", "body": ...}) and by reinforcing the secrets constraint on body that the schema also flags. It does not, however, explain the 'type' enum's effect on policy/approval beyond what the schema lists.

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?

Opens with a specific verb+resource+scope: 'Create a new unread message in the local Community Mesh store for another agent.' It immediately separates itself from the closest sibling by naming agentsecure.reply_message as the in-thread alternative, so an agent can route without opening either 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?

Explicitly names the alternative (reply_message) and the condition selecting it, and gives concrete exclusions: does not launch/wake the recipient, contact a remote service, or prove read. It also states the policy/approval check that runs before a send, which is the key precondition an agent needs.

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

This server cannot be deployed

Other Tools