Skip to main content
Glama

ateam_test_notification

Send real notifications to an existing actor's enabled channels (telegram, push, app) for end-to-end testing of system-initiated notification delivery and verification.

Instructions

Fire a REAL notification at an existing actor in a deployed solution — for end-to-end testing of the system-initiated notification path (telegram/push/app channels).

Unlike ateam_test_skill (synthetic test actor with no channels) and ateam_conversation (user-initiated thread), this calls the /api/internal/notify-user path that PCM and other sibling services use — so the actor's real enabled channels actually receive the message.

Use for: • Channel fan-out smoke (does telegram/push/app actually receive it?) • Delivery-result verification (per-channel ok/failed in the response).

Auth: forwards your authed api_key to Core (no master-secret involvement). Tenant is pinned by the key itself — cross-tenant targeting is structurally impossible.

⚠️ SAFETY: • The text is prefixed with [TEST] in the actual notification — visible to the user, anti-phishing. • Rate-limited: 10 calls/min per session. • Every call is audited (caller, tenant, actor, content hash) regardless of outcome. • actor_id is scoped to your tenant — cross-tenant targeting is rejected by Core's per-tenant Mongo isolation. • reply_handler is NOT supported via api-key auth (Core ignores it). Routing the user's next reply to an arbitrary skill is a privilege-escalation surface. For routing/engagement tests, use ateam_test_skill.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
solution_idYesThe solution ID (required for tenant scoping + audit context).
actor_idYesTarget actor ID in your tenant (e.g. 'usr_arie_admin_0001'). Must exist; Core rejects if not found in your tenant.
contentYesNotification text. Will be sent to all of the actor's enabled channels, prefixed with [TEST] for the recipient.
urgencyNoNotification urgency. Default 'normal'.
sourceNoAudit label for message.source. Default 'ateam-test'.
metadataNoOptional metadata merged into message.metadata. Useful for correlation IDs.
Behavior5/5

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

With no annotations provided, the description carries full burden. It comprehensively discloses behavior: real notification, auth forwarding, tenant pinning, safety features ([TEST] prefix, rate limit 10/min, auditing), and limitations (reply_handler not supported).

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?

The description is moderately long but well-structured with sections (purpose, comparison, use cases, auth, safety). It front-loads the key purpose and differentiators. While efficient, some detail (e.g., the reply_handler explanation) could be condensed.

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 has 6 parameters, no output schema, and no annotations, the description covers all crucial aspects: purpose, when to use, safety, behavioral details, and parameter context. It explains the response includes per-channel ok/failed, which is sufficient for an end-to-end testing tool.

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 value beyond the schema by explaining that content is prefixed with [TEST], actor_id is scoped to tenant, and metadata is for correlation IDs. This extra context improves parameter understanding.

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 specific purpose: 'Fire a REAL notification at an existing actor in a deployed solution — for end-to-end testing'. It uses specific verbs and resources and distinguishes itself from siblings by explicitly comparing to ateam_test_skill and ateam_conversation.

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 provides explicit guidance on when to use the tool (channel fan-out smoke testing, delivery-result verification) and when not to (for routing/engagement tests, use ateam_test_skill). It also includes context about auth and tenant scoping.

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

Install Server

Other Tools

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/ariekogan/ateam-mcp'

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