Handsome Hosting

Form mail endpoint

form_mail

Read-only

The form relay endpoint of an existing service, for a contact form on the site: the URL to POST to and the rules the form must follow (submit with fetch, the email and _gotcha fields, the success check, the limits). A new project's forms post to the same full address with the literal HH_FORM_TOKEN as the token; the site's own server does not answer a relative /f/ path.

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": {
      "serviceId": "<serviceId>"
    },
    "name": "form_mail"
  }
}

Input Schema

Name	Required	Description	Default
`serviceId`	Yes	the id of a service on this account

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	No
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

changedInput schema / properties / serviceId / description

Previous value: -"the service id from list_services"New value: +"the id of a service on this account"

First observedOct 23, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds substantive operational context: fetch-based submission, the email and _gotcha fields, the success check, limits, and the HH_FORM_TOKEN placeholder. These details go beyond what the annotations provide without contradicting them.

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?

The description is dense but appropriately sized: it front-loads the resource and then adds the important token and relative-path caveats. The long parenthetical rule list is slightly heavy, but the sentences generally earn their place.

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 read-only lookup with one parameter and an output schema, the description supplies the relevant behavioral and submission-rule context an agent needs. The main omission is explicit routing relative to sibling form tools.

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% for the single serviceId parameter, so the schema already carries the parameter semantics. The description only indirectly reinforces it by referring to 'an existing service'.

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?

The description identifies the exact resource: the form relay endpoint for an existing service, including the URL and submission rules. It is clear enough for tool selection, but it does not explicitly distinguish this lookup from related form-configuration siblings such as set_form_recipients.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by 'for a contact form on the site' and the note about new projects posting to the same address. However, there is no explicit when-to-use guidance and no comparison to alternatives like set_form_recipients.

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

All Handsome Hosting tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?