Skip to main content
Glama

Dodaj do grupy

add_to_group
Idempotent

Add to group

Add existing contacts (ct_…) or phone numbers to a group from list_groups. Missing numbers are created as contacts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group_id": "<group_id>"
    },
    "name": "add_to_group"
  }
}

Input Schema

NameRequiredDescriptionDefault
msisdnsNoNumery: brakujące kontakty zostaną utworzone.
group_idYesId grupy gr_… z list_groups.
contact_idsNoId kontaktów ct_… do dodania.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / group_id / description
      Previous value: -"Id grupy grp_… z list_groups."New value: +"Id grupy gr_… z list_groups."
  2. Changed1 schema field changed
    • changedInput schema / properties / msisdns / description
      Previous value: -"Numery — brakujące kontakty zostaną utworzone."New value: +"Numery: brakujące kontakty zostaną utworzone."
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {},
      +  "type": "object"
      +}
  4. Changed4 schema fields changed
    • addedInput schema / properties / contact_ids / description
      Added value: +"Id kontaktów ct_… do dodania."
    • addedInput schema / properties / group_id / description
      Added value: +"Id grupy grp_… z list_groups."
    • addedInput schema / properties / msisdns / description
      Added value: +"Numery — brakujące kontakty zostaną utworzone."
    • changedInput schema / properties / msisdns / items / description
      Previous value: -"Numer telefonu w formacie E.164, np. +48533991881. Numer 9-cyfrowy bez prefiksu = Polska."New value: +"Phone number in E.164. Example: +48533991881. A 9-digit number without prefix is treated as Polish."
  5. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description discloses a genuine side effect: missing phone numbers are silently created as contacts. That is the key behavior an agent needs before calling. It does not address what happens when a contact is already a member, but the idempotentHint already covers that expectation.

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 short sentences, front-loaded with the purpose and then the accepted inputs; nothing is wasted. The opening line 'Add to group' largely repeats the tool name and title, which is minor redundancy.

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 3-parameter tool with full schema coverage, annotations, and an output schema, the description covers the essentials: input kinds, the group_id source, and the contact-creation side effect. Only duplicate-membership behavior is left unstated, and the idempotent annotation partially fills that gap.

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 description coverage is 100%, so the schema already documents all three parameters, including the E.164 format and the gr_…/ct_… id prefixes. The description restates the same ct_… and list_groups facts rather than adding new meaning, so baseline 3 applies.

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?

The description names a specific verb+resource ('Add ... to a group') and enumerates the two accepted input kinds: existing contacts with ct_… ids or raw phone numbers. It is immediately distinguishable from siblings such as add_to_blacklist or upsert_contacts, though it never explicitly contrasts itself with them.

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?

It points the agent at list_groups as the source of a valid group_id, which is real usage guidance for the required parameter. It does not say when to prefer this over upsert_contacts (creating contacts) or add_to_blacklist, and gives no exclusions or preconditions, so guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.