Skip to main content
Glama

add_managed_client

Add a client who will not use the app (name + optional WhatsApp number). Counts toward the same client limit as any client. (confirm-gated: previews until confirm: true)

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": {
      "input": "<input>"
    },
    "name": "add_managed_client"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes
confirmNoMust be true to actually execute. If false/omitted, returns a preview only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

The annotations only declare that this is not read-only. The description adds meaningful behavior: it is confirm-gated and only previews unless confirm=true, and the client counts toward the same limit as other clients. It does not cover permissions or duplicate handling, but it adds substantive mutation context beyond the annotation.

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?

The description is compact and front-loaded: type of client, payload hint, quota impact, then confirmation behavior. Every clause adds useful information with no filler.

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 simple mutation tool with no output schema, it covers the key behavioral facts an agent needs: the app-less client scope, quota impact, and the preview-versus-execute gate. It could be slightly fuller about what the preview returns or validation rules, but no critical gap prevents correct invocation.

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 50%: phone and confirm are already documented in the schema. The description reinforces that the optional number is a WhatsApp number and restates the preview/confirm behavior, but it does not fully compensate for the undocumented name field or nested input structure. 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 names a specific action and resource: adding a 'managed client' who will not use the app. That qualifier distinguishes it from ordinary client creation or invitation flows and tells an agent exactly what kind of record is being created.

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

Usage Guidelines4/5

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

It clearly states the usage condition — adding someone who will not use the app — and notes the client-limit consequence. It stops short of explicitly naming alternatives such as invite_client_to_organization or create_prospect, so it lacks full when-not guidance.

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.