MCP tools, webhooks and limits

A reference for developers and AI agents: the 27 MCP tools grouped by job, how outbound webhooks are signed and retried, how the hosted MCP endpoint and API keys are secured, and the request limit for each plan. Install steps are not repeated here.

• 27 MCP tools
• Security primitives
• Rate limits
• Links and packages

Looking for setup? REST API and MCP reference · Setup guides for 15 AI tools · Full input schemas for every tool · LazyRelay for developers

The 27 MCP tools

Names and descriptions below are generated from the server's own tool definitions, so they are exactly what an AI agent receives. Each name links to its full input schema in the MCP tool reference. The hints are the MCP annotations each tool declares, so a client can decide what to confirm with you.

Security primitives

Only what the code does today.

Outbound webhooks

LazyRelay can send an HTTP POST to an endpoint you register when something happens to a post or a connected account. You can register up to 5 endpoints in the dashboard under Settings, Webhooks; each has its own secret, shown once when it is created, and can be limited to chosen events and channels.

The JSON body holds event, eventId and createdAt plus the details of the event. The dashboard's Send test button sends webhook.test, once, with no retries.

Headers on every delivery

• X-LazyRelay-Signature: the HMAC-SHA256 of the raw JSON body, keyed with the endpoint secret, as lowercase hex with no prefix.
• X-LazyRelay-Event: the event name, for example post.verified.
• X-LazyRelay-Delivery: the event id. It is the same on every retry of one event, so use it to ignore a repeat.
• X-LazyRelay-Attempt: 1 on the first try, up to 6.

Delivery and retries. Each attempt times out after 10 seconds. A 2xx answer counts as delivered. A 408, a 429, any 5xx and a connection error or timeout are retried; any other answer, including a redirect (redirects are never followed), is a final failure you can read in the delivery log. There are 6 attempts in total, over about 9 hours, with these waits after each failed attempt:

Verify the signature against the raw body, before any JSON parsing, because re-serialising parsed JSON can change whitespace or key order. With the Node SDK (@lazyrelay/sdk), which compares in constant time:

import express from "express";
import { verifyWebhookSignature } from "@lazyrelay/sdk";

const app = express();

app.post("/lazyrelay-webhook", express.raw({ type: "application/json" }), (req, res) => {
  const ok = verifyWebhookSignature({
    secret: process.env.LAZYRELAY_WEBHOOK_SECRET,
    rawBody: req.body, // the raw bytes, before any JSON parsing
    signature: req.get("X-LazyRelay-Signature"),
  });
  if (!ok) return res.status(401).end();

  const event = JSON.parse(req.body.toString("utf8"));
  // X-LazyRelay-Delivery is the same on every retry of one event: use it to ignore a repeat.
  console.log(req.get("X-LazyRelay-Event"), event.eventId);
  res.status(200).end();
});

Without the SDK, the same check with Node's built-in crypto:

import { createHmac, timingSafeEqual } from "node:crypto";

function isValid(secret, rawBody, signatureHeader) {
  const received = String(signatureHeader || "").trim().toLowerCase();
  if (!/^[0-9a-f]{64}$/.test(received)) return false;
  const expected = createHmac("sha256", secret).update(rawBody).digest();
  return timingSafeEqual(expected, Buffer.from(received, "hex"));
}

The hosted MCP endpoint

• Transport. https://lazyrelaylazyrelay-backend.onrender.com/mcp speaks MCP over Streamable HTTP in stateless mode: every request gets a fresh server and transport, so concurrent calls never share state.
• Authentication. OAuth 2.1 bearer tokens only. Each token is verified against the identity provider's published signing keys (JWKS), with the algorithm pinned to ES256, and must have been issued for the MCP server itself. An ordinary dashboard session token is rejected there.
• Discovery. The OAuth protected resource metadata (RFC 9728) is published under /.well-known on the same host, and an unauthenticated call gets a 401 with a WWW-Authenticate header pointing to it, which is how an MCP client finds the sign-in flow.
• Rate limit. Applied after authentication, per account, using the ladder below.

REST API keys

• Keys start with lzr_live_ and are sent as Authorization: Bearer. They work on the REST API and in the local @lazyrelay/mcp-server package, not on the hosted /mcp endpoint.
• A key is shown once, when you create it. LazyRelay stores only its SHA-256 hash.
• A key cannot create or revoke keys: that always needs a direct dashboard sign-in.

Rate limits

Requests are counted per account in a one minute window. The same ladder applies to authenticated REST API requests and to the hosted MCP endpoint. Over the limit, the API answers HTTP 429, and an MCP tool reports the error kind rate_limited with retryable set to true. A plan change can take up to a minute to apply.

This limits request volume only. Plan limits on accounts, brands and posts are separate; see pricing.

Links and packages