Skip to main content
Glama
wuapidev

wuapi MCP server

Official
by wuapidev

Update, delete or audit a project

manage_project
DestructiveIdempotent

Change a wuapi project's name, external ID, metadata, account limit, or status; delete it; and list or revoke its API keys.

Instructions

Change a project (rename it, set its external id, metadata or account limit, suspend or resume it), delete it, and list or revoke its API keys. Suspending refuses every send and write in the project while reads and inbound messages keep working. Organization keys only. New project keys are created in the wuapi dashboard: no tool returns an API key.

Actions:

  • update: Change any of name, externalId, metadata, maxAccounts and status. Returns the project.

  • delete: Delete the project: its keys stop working at once, and its numbers are logged out and deleted in the background with its webhook endpoints. Needs confirm: true.

  • list_keys: The project's API keys, revoked ones included: name, last 4 characters, last use. Never the key itself.

  • revoke_key: Revoke one of the project's API keys. It stops working at once. Needs confirm: true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThe project name. Optional for `update`.
limitNoPage size, 1 to 100. Default 20. Optional for `list_keys`.
actionYesWhat to do. See the list of actions in the tool description.
cursorNo`nextCursor` from the previous page, to get the next one. Optional for `list_keys`.
statusNo`suspended` refuses sends and writes; `active` resumes. Optional for `update`.
confirmNoMust be true. This cannot be undone. Only set it after the user asked for this or agreed to it. Required for `delete`, `revoke_key`.
apiKeyIdNoThe API key id, from `list_keys`. Required for `revoke_key`.
metadataNoYour own string values. Replaces the whole metadata object. Optional for `update`.
projectIdNoThe project id or `ext:<externalId>`. Required for every action.
externalIdNoYour id for this customer: letters, digits and `. _ : @ -`. null clears it. Optional for `update`.
maxAccountsNoHow many numbers it may link. null removes the limit. Optional for `update`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint/readOnlyHint/idempotentHint) by spelling out suspend semantics (sends and writes refused, reads and inbound still work), that delete immediately kills keys and background-deletes numbers and webhooks, and that both destructive actions require confirm: true.

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?

Front-loaded with the operation summary and safety-critical constraints, then organized into a scannable per-action list. Every sentence carries information; there is no filler.

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?

For an 11-parameter, nested-object, multi-action mutation tool with no output schema, the description covers per-action requirements, return value of update, pagination-relevant actions, and irreversible consequences. Nothing an agent needs to invoke it correctly is missing.

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 every parameter, including the confirm and status semantics the description restates. The description adds little parameter-level detail beyond the schema, so the baseline of 3 applies.

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?

Names the exact resource (project) and enumerates the four distinct operations it performs (update, delete, list_keys, revoke_key), which cleanly separates it from create_project, get_project, and list_projects. An agent can predict its behavior without opening the schema.

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?

Gives clear context per action plus prerequisites ('Organization keys only') and a boundary condition ('New project keys are created in the wuapi dashboard: no tool returns an API key'). It does not, however, explicitly route read-only inspection to get_project/list_projects.

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