Skip to main content
Glama
Sign In
Yolfi

Yolfi

Official
by yolfinance
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Configure Yolfi Webhooks

yolfi_webhooks_configure

Create a webhook endpoint by reusing matching endpoints and store its signing secret locally. Verify deliveries using the X-Yolfi-Signature header.

Instructions

Create a webhook endpoint only after listing and reusing any matching endpoint. Stores its signing secret locally without returning plaintext. Use an existing app URL and verify X-Yolfi-Signature.

Input Schema

NameRequiredDescriptionDefault
urlYesHTTPS webhook URL in the target app, for example https://example.com/api/yolfi/webhook.
nameNoEndpoint display name, for example Merchant analytics.
adapterNoWebhook adapter output format. Defaults to NONE if omitted.
enabledNoWhether the new webhook endpoint receives deliveries. Defaults to true.
metadataFiltersNoOptional flat key/value metadata filters. A delivery must match every configured string value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.1
    • changedInput schema / properties / adapter / enum
      Previous value: -[
-  "NONE",
-  "STRIPE",
-  "LEMON_SQUEEZY",
-  "PADDLE",
-  "POLAR",
-  "GUMROAD",
-  "DODO"
-]New value: +[
+  "NONE",
+  "STRIPE",
+  "LEMON_SQUEEZY"
+]
    • addedInput schema / properties / enabled
      Added value: +{
+  "description": "Whether the new webhook endpoint receives deliveries. Defaults to true.",
+  "type": "boolean"
+}
    • addedInput schema / properties / metadataFilters
      Added value: +{
+  "additionalProperties": {
+    "maxLength": 255,
+    "type": "string"
+  },
+  "description": "Optional flat key/value metadata filters. A delivery must match every configured string value.",
+  "maxProperties": 10,
+  "propertyNames": {
+    "maxLength": 100
+  },
+  "type": "object"
+}
    • addedInput schema / properties / name
      Added value: +{
+  "description": "Endpoint display name, for example Merchant analytics.",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds genuinely non-obvious behavior: the signing secret is persisted locally and never returned in plaintext, and the caller is expected to verify X-Yolfi-Signature. It does not explain failure modes for a duplicate URL.

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?

Three short sentences, each carrying a distinct fact (precondition, secret handling, verification), with the most important constraint front-loaded. Slightly telegraphic phrasing ('Use an existing app URL') costs a point but there is 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 5-parameter creation tool with no output schema, the description covers the prerequisite, the secret-handling side effect and the post-create verification step. It leaves the response shape and duplicate-URL behavior unstated, but the core call path is complete.

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 100%, so url, name, adapter, enabled and metadataFilters are all documented in the schema itself, which sets the baseline at 3. The description only adds the constraint that the URL must already exist in the app; it says nothing extra about adapter output formats or how metadataFilters interact with deliveries.

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

Purpose4/5

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

Opens with a specific verb+resource: 'Create a webhook endpoint.' It implicitly distinguishes itself from the read/update siblings by naming the listing step as a prerequisite, though it never explicitly names yolfi_webhooks_list or yolfi_webhooks_update. An agent can still tell what this tool does 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 Guidelines5/5

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

'Create a webhook endpoint only after listing and reusing any matching endpoint' is an explicit precondition plus an alternative action (reuse) when the condition is met. Combined with 'Use an existing app URL,' the agent knows both when to call and when not to.

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