Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

signwell_webhook

SignWell webhooks — a URL you control receives every event of the account.

Events include document_sent, document_viewed, document_signed, document_completed, document_declined, document_expired, document_bounced. Each delivery carries event.hash = HMAC-SHA256(key = webhook id, data = "<event.type>@<event.time>") to verify it came from SignWell. oto itself does not receive webhooks.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "signwell_webhook"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNo"list" | "create" (`callback_url`) | "delete" (`webhook_id`).list
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
dry_runNoon create/delete, preview without writing.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
webhook_idNo
callback_urlNo
api_application_idNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does add genuinely useful behavior: the exact event types emitted, the HMAC-SHA256 verification scheme with key = webhook id and data = '<event.type>@<event.time>', and the fact that SignWell delivers to the caller's URL, not to oto. It still omits the mutation consequences of `delete`, whether a create returns a signing secret, and retry/delivery semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact but mis-prioritized: it leads with a conceptual explanation of webhooks and spends most of its length enumerating seven event names, while the tool's actual three operations and their required parameters are never mentioned. Nothing is padded, but the space is spent on background rather than on how to call the tool.

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?

A 10-parameter mutation-capable tool with no annotations and no output schema needs the description to cover operation semantics, return values (webhook id/secret), and delete behavior; instead it covers only the domain concept. An agent knows what SignWell webhooks are but not what this call will do or return.

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 70% and the `op` enum already documents list/create/delete with their companions. The description adds real meaning only for `webhook_id` (implicitly the HMAC key), while `callback_url`, `api_application_id`, and the oto scoping parameters (`_org`, `_project`, `_run_id`, `dry_run`) get no treatment here — those rely on the schema text.

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 opening sentence describes the SignWell webhook resource and what it delivers (HTTP callbacks to a URL you control), which does orient the agent. But it never states the tool's own action — that it lists, creates, and deletes webhook subscriptions — so the verb is only inferable from the `op` enum in the schema, not from the description.

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?

There is no guidance on when to call this versus alternatives such as `signwell_act` or the other webhook tools in the sibling list, and no prerequisites stated (e.g., needing a reachable public callback URL before create). The statement 'oto itself does not receive webhooks' implies the user must supply an endpoint, but that is a constraint, not when-to-use guidance.

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

All Tulina toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources