Skip to main content
Glama

Nối nhóm Zalo

monapay_create_zalo_group

Create a Zalo group linked to the Mona bot using a 10–25 digit group_id from MONA Account/PMS, then set events and a plain-text message template.

Instructions

Nối nhóm có bot Gấu Mona bằng group_id 10–25 chữ số lấy từ MONA Account/PMS; Zalo không parse Markdown, nên template phải là text thuần.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
eventsNoCác sự kiện gửi vào nhóm Zalo
group_idYesgroup_id gồm 10–25 chữ số, lấy từ MONA Account/PMS
is_activeNo
friendly_nameYesTên dễ nhớ của nhóm
message_templateNoText thuần; hỗ trợ {amount}, {description}, {virtual_account_number}, {transaction_code}, {transfer_date} và dạng {{...}}
virtual_account_idNoChỉ nhận thông báo cho VA này; bỏ trống = mọi tài khoản

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly=false, idempotent=false, openWorld=true, destructive=false, so the safety profile is covered. The description adds a real behavioral constraint — Zalo does not parse Markdown, so template must be plain text — but says nothing about failure modes, permission/auth needs, or what creation returns.

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?

Two tight clauses, front-loaded with the core action before the format caveat. No waste, though the group_id digit range is redundantly echoed from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with no output schema; the description covers the action, id source, and one template constraint, but leaves events, is_active, and virtual_account_id behavior to the schema and doesn't describe outcomes. Adequate but with visible gaps for a 6-param creation 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 83% so baseline is 3, but the description adds genuinely new meaning beyond the schema by warning that message_template must be plain text (no Markdown), a constraint absent from the schema description. The group_id format note largely repeats the schema's pattern/description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: connecting ('Nối') a Zalo group to the Gấu Mona bot, with the group_id source (MONA Account/PMS) named. This clearly distinguishes it from list/update/delete/test siblings by intent, though it never names those alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a prerequisite (group_id must come from MONA Account/PMS), which implies when the tool is usable, but gives no explicit when-to-use vs monapay_update_zalo_group or monapay_test_zalo_group, and no when-not guidance.

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