Skip to main content
Glama
Sign In
@t4dhg/mcp-holded

@t4dhg/mcp-holded

by t4dhg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Holded webhooks

holded_webhooks

Manage webhooks and monitor API usage: list, get, create, update, enable, disable, delete webhooks, view supported events, and check monthly quota.

Instructions

Webhooks and API usage. Actions: list, get, events (supported event types), create, update, enable, disable, delete, usage (API quota for the current month).

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": {
      "action": "<action>"
    },
    "name": "holded_webhooks"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoRecord id (24 hex characters)
dataNoPayload for create and update actions, following the Holded v2 request contract
limitNoPage size, 1 to 200 (default 50)
actionYes
cursorNoCursor from the previous page to continue listing
confirmNoRequired for gated actions. The first call without it sends nothing and explains what would happen.
usage_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.1

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavior. It mentions that 'usage' provides API quota for the current month, but it does not disclose destructive nature of delete, side effects of enable/disable, confirmation requirements, or any auth or rate-limit considerations. The list of actions is present but lacks any behavioral context beyond the bare action names.

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?

The description is concise, using a single sentence with a list of actions. It front-loads the resource and then lists actions, which is efficient. However, the list format is a bit cryptic and could be more readable with separators or short explanations. It is not verbose, but the structure could be improved for clarity.

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

Completeness2/5

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

Given the tool has 7 parameters, a nested data object, no output schema, and no annotations, the description is significantly incomplete. It does not explain return formats, pagination behavior, error conditions, or how actions map to parameters. The 'confirm' parameter behavior is only in the schema, not the description. The agent lacks enough context to call this tool correctly across all actions.

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 71%, and the schema already documents most parameters clearly (id, data, limit, cursor, confirm). The description adds no parameter-specific meaning; it only repeats the action names. Since the schema covers the parameters well, the description does not need to compensate, but it also does not enhance understanding. The 'usage' action hint about API quota is in the description but not linked to the usage_type parameter, leaving a minor ambiguity.

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

Purpose3/5

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

The description states the resource (webhooks and API usage) and lists actions, but it is a generic enumeration rather than a specific verb+resource statement. It does not clearly distinguish itself from sibling tools beyond the resource name, and the inclusion of 'API usage' is a separate concern that muddies the focus. The description is adequate but not precise.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description implies that webhook management or API quota checks should use this tool, but it does not name any sibling or condition for selection. There are no exclusions or alternative recommendations, leaving the agent to infer usage from the resource name.

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