Skip to main content
Glama
ariekogan

ateam-mcp

by ariekogan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.52

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description discloses rate limiting (10 calls/min), audit trail, tenant scoping via Core's Mongo isolation, [TEST] prefix to prevent phishing, and the security rationale for ignoring reply_handler. This far exceeds baseline and fully compensates for missing annotations.

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?

Despite length, the description is organized into clear sections (purpose, usage, auth, safety) and every sentence delivers critical information. No filler or redundancy; the structure makes it easy to scan.

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?

Even without an output schema, the description specifies the delivery-result verification outcome and covers auth, rate limits, tenant isolation, and audit. For a high-stakes testing tool, this is fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters well. The description supplements by explaining tenant scoping, [TEST] prefix, and rejection of cross-tenant actors, but most parameter meaning is already captured in the schema. Baseline 3 is appropriate.

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 opens with a clear verb+resource: 'Fire a REAL notification at an existing actor in a deployed solution' and explicitly contrasts with ateam_test_skill and ateam_conversation, distinguishing its system-initiated real-channel behavior. This fully differentiates it from siblings.

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?

Provides explicit 'Use for' bullets and an explicit alternative: 'For routing/engagement tests, use ateam_test_skill.' Also states when not to use (reply_handler unsupported). Clear context with exclusions and alternatives.

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