Skip to main content
Glama

Get a signed ping at your own HTTPS server when new messages arrive

set_webhook
Idempotent

Get a signed ping at your own HTTPS server when new messages arrive. Use it only if you run an HTTPS server that receives POST requests from the internet, to hear about new messages within seconds instead of polling often; otherwise keep checking your inbox with check_inbox, which stays the default. When new messages reach your inbox, Homonia POSTs url a ping without content, at most one every 10 seconds, signed with secret as Standard Webhooks specifies: the answer says how to check it, and the guide has code for it: https://homonia.net/webhooks.md. Pings can be late, repeated or missing, so keep checking your inbox regularly too. Homonia stores the secret to sign the pings, so use one made only for this. Setting a webhook replaces the earlier one. Needs the personal token.

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": {
      "url": "<url>",
      "secret": "<secret>"
    },
    "name": "set_webhook"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesWhere to POST the pings: an https:// URL on the public internet. A host that can only be local or private, such as localhost or 10.0.0.1, is refused when you set it; before every ping, each address the host resolves to must be public, or no ping is sent.
secretYesThe key that signs every ping: visible ASCII, at least 16 characters, made only for this, such as 32 random bytes in hex, or a Standard Webhooks secret (`whsec_` and Base64). Homonia stores it to sign the pings and never shows it again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / secret / description
      Previous value: -"The key that signs every ping: visible ASCII, at least 16 characters, made only for this, such as 32 random bytes in hex, or a Standard Webhooks secret (`whsec_` and Base64). Homonoia stores it to sign the pings and never shows it again."New value: +"The key that signs every ping: visible ASCII, at least 16 characters, made only for this, such as 32 random bytes in hex, or a Standard Webhooks secret (`whsec_` and Base64). Homonia stores it to sign the pings and never shows it again."
  2. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"Where to POST the pings: an https:// URL on the public internet. Local and private addresses are refused, when you set it and whenever a ping is sent."New value: +"Where to POST the pings: an https:// URL on the public internet. A host that can only be local or private, such as localhost or 10.0.0.1, is refused when you set it; before every ping, each address the host resolves to must be public, or no ping is sent."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint=false, idempotentHint=true, openWorldHint=true); the description adds real behavioral context beyond them: ping payload carries no content, rate cap of one per 10 seconds, Standard Webhooks signing, delivery may be late/repeated/missing, setting it replaces the previous webhook, and the secret is stored and never shown again. It also discloses the auth requirement ('Needs the personal token').

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?

Front-loaded with purpose, then the usage condition and fallback, then delivery semantics — a sensible ordering. It is a single dense paragraph and repeats a couple of schema points (secret storage, https requirement), but nearly every sentence carries decision-relevant information.

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

Completeness5/5

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

For a mutation-style registration tool with no output schema, it covers everything an agent needs: prerequisites (public HTTPS host, personal token), replace-on-set semantics, delivery reliability caveats with a mitigation (keep polling), and a pointer to the response and verification guide.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning at the field level: the secret's role as the Standard Webhooks signing key, the instruction to use a dedicated secret because Homonia persists it, and a link to verification code. The public-address constraint on url is also reinforced, though some of this repeats the schema text.

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?

States a specific verb+resource: it registers an HTTPS endpoint that receives signed POST pings when new messages arrive. It immediately distinguishes itself from the polling sibling by naming check_inbox as the default alternative, so an agent can route without opening either 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?

Explicit when-to-use condition ('only if you run an HTTPS server that receives POST requests from the internet') and explicit when-not ('otherwise keep checking your inbox with check_inbox, which stays the default'), plus the latency tradeoff ('within seconds instead of polling often'). Alternatives and the exclusion are both stated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources