Gerenciar usuários da conta ZapSign. Ações:
create_user (data): adiciona usuário. Campos: email*; opc role (member|admin|self_docs_limited), first_name, last_name, phone_country, phone_number.
delete_user (email): remove usuário (donos não podem ser removidos).
[Flattened action: delete_user]
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| No | |||
| account | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'remove usuário' (delete user), which is a destructive operation. However, annotations declare destructiveHint: false, directly contradicting the description's implied behavior. Additionally, no information is given about permissions, reversibility, or side effects beyond the owner restriction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is not concise; it includes an entire create_user specification that is irrelevant to the actual operation. It is not front-loaded with the delete action, and the 'flattened action' note appears at the end. The structure does not efficiently communicate the intended usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with minimal parameters, the description should explain the delete operation more fully. It mentions only the owner restriction but omits details like account parameter usage, potential errors, or expected outcomes. The inclusion of create_user adds noise without clarifying the actual delete workflow. No output schema is provided, but that alone does not excuse missing essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes 'email', 'data', and 'account' parameters, but the description only explains email for delete_user (used as identifier). The 'data' parameter is explained only for create_user, which is not the flattened action. 'account' is completely undocumented. With 0% schema coverage, the description fails to clarify which parameters are needed for the delete operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists two actions (create_user, delete_user) while the tool name and '[Flattened action: delete_user]' indicate it is specifically for deleting a user. This ambiguity prevents clear identification of the tool's core purpose, making it difficult for an agent to select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling zapsign_account_write_create_user. In fact, the description includes the create_user action, which is misleading since a separate tool exists for that. There is no mention of when deletion is appropriate or any exclusions beyond owners cannot be removed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct name and purpose, with clear separation between read and write actions. However, the high number of similarly-prefixed tools (e.g., zapsign_documents_write_*) and the overlap between create and create_from_template could occasionally cause misselection.
Domain tools follow a consistent zapsign_<resource>_<action> pattern, with writes marked by _write_. However, platform-level tools (authenticate, connect, marketplace) break the pattern, and zapsign_list_accounts deviates from the resource-prefix convention.
35 tools is excessive, especially since many are flattened actions from a smaller set of underlying operations. The inclusion of non-domain platform tools further inflates the count, making the tool list feel heavy and harder to navigate.
The core ZapSign domain is well covered: documents, signers, templates, webhooks, checks, and account management all have CRUD-like operations. Minor gaps exist, such as no listing endpoint for checks and no webhook list (due to API limitations), but these are not fatal for typical workflows.