Skip to main content
Glama
Sign In
Yolfi

Yolfi

Official
by yolfinance
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Verify Yolfi Webhook Signature

yolfi_webhooks_verify
Read-onlyIdempotent

Verify the X-Yolfi-Signature HMAC against the raw JSON webhook payload before trusting payment events, using endpoint signing secrets or the configured webhook secret.

Instructions

Verify an X-Yolfi-Signature HMAC over the raw JSON webhook payload before trusting payment events.

Input Schema

NameRequiredDescriptionDefault
payloadYesRaw webhook request body string, before JSON parsing.
signatureYesX-Yolfi-Signature header value.
endpointIdNoWebhook endpoint id whose signing secret was stored locally during create or rotate. YOLFI_WEBHOOK_SECRET takes precedence when set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.1
    • addedInput schema / properties / endpointId
      Added value: +{
+  "description": "Webhook endpoint id whose signing secret was stored locally during create or rotate. YOLFI_WEBHOOK_SECRET takes precedence when set.",
+  "type": "string"
+}
    • removedInput schema / properties / secret
      Removed value: -{
-  "description": "Optional explicit webhook secret. Defaults to YOLFI_WEBHOOK_SECRET or YOLFI_API_KEY.",
-  "type": "string"
-}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds only the header name and the raw-payload requirement, both of which are duplicated in the schema property descriptions, and it says nothing about failure behavior (throw vs. false) or return shape, which matters for a verification primitive with no output schema.

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?

A single front-loaded sentence with no wasted words; the verification target and its purpose are stated immediately. It is efficient rather than padded, though it is terse enough that one more clause on outcome would have fit without bloat.

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

Completeness3/5

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

Given full schema coverage and complete annotations, the main remaining unknown is what the tool actually yields on success or mismatch, and whether it throws. For a boolean-style verification tool with no output schema, that is a real gap an agent must discover empirically.

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 all three parameters, including the endpointId/YOLFI_WEBHOOK_SECRET precedence rule, are already explained in structured data. The description adds no additional semantics beyond repeating 'raw payload', so baseline 3 is correct.

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?

Specific verb (verify) plus specific resource (X-Yolfi-Signature HMAC over the raw webhook payload), with the intent spelled out ('before trusting payment events'). No sibling tool covers signature verification, so an agent can route to it unambiguously.

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?

The phrase 'before trusting payment events' gives a clear trigger condition and implicitly frames this as a precondition step in a webhook-handling flow. It stops short of naming an alternative or an explicit when-not case, but none of the listed siblings is a plausible competing choice.

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