Skip to main content
Glama

DropTheHassle

by io.github.bosmdavid-gif
OverviewDiscussionsAdmin

Connect backend

set_backend
DestructiveIdempotent

(needs account token) Links an HTTPS backend hosted on AWS, Google Cloud, DigitalOcean or your own server to a DropTheHassle name. url is an HTTPS origin with no path, port 443, and a hostname that has an IPv4 address. Paths pass through unchanged. With uploaded files, only the path rules (default /api/*) go to the backend and the rest is served from the files. Without uploaded files, the whole site comes from the backend. Without site, a new site is created in the account. With site, the site is already on the account. An empty url with site removes the link. confirm=true applies a change to an existing site. A new site does not use confirm. Does not charge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe HTTPS origin of the backend, e.g. "https://api.example.com". Empty string (with site) unlinks.
siteNoOptional address of an existing site to link, for example myproject.dropthehassle.app. Absent creates a new site served fully from the backend.
slugNoOptional address label for a NEW site, e.g. "myapp" -> myapp.dropthehassle.app. Errors when taken.
pathsNoOptional path rules for split mode, e.g. ["/api/*", "/webhooks/*"]. Default ["/api/*"].
confirmNoTrue applies a change to an existing site. False leaves that site unchanged and the reply describes the change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Needed with site: true ONLY after the human said yes to this change."New value: +"True applies a change to an existing site. False leaves that site unchanged and the reply describes the change."
    • changedInput schema / properties / site / description
      Previous value: -"Optional: the address of an existing site to link (from list_sites). Omit to create a new free site served fully from the backend."New value: +"Optional address of an existing site to link, for example myproject.dropthehassle.app. Absent creates a new site served fully from the backend."
  2. Changed1 schema field changed
    • changedInput schema / properties / url / description
      Previous value: -"The HTTPS origin of the backend, e.g. \"https://myapp.up.railway.app\". Empty string (with site) unlinks."New value: +"The HTTPS origin of the backend, e.g. \"https://api.example.com\". Empty string (with site) unlinks."
  3. Changed1 schema field changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Needed with site: true ONLY after the human said yes to this change.",
+  "type": "boolean"
+}
  4. Changed3 schema fields changed
    • addedInput schema / properties / site
      Added value: +{
+  "description": "Optional: the address of an existing site to link (from list_sites). Omit to create a new free site served fully from the backend.",
+  "type": "string"
+}
    • removedInput schema / properties / site_id
      Removed value: -{
-  "description": "Optional: an existing site to link (from list_sites). Omit to create a new free site served fully from the backend.",
-  "type": "number"
-}
    • changedInput schema / properties / url / description
      Previous value: -"The HTTPS origin of the backend, e.g. \"https://myapp.up.railway.app\". Empty string (with site_id) unlinks."New value: +"The HTTPS origin of the backend, e.g. \"https://myapp.up.railway.app\". Empty string (with site) unlinks."
  5. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Adds meaningful context beyond annotations: the token requirement, split-mode routing rules, the unlink behavior of empty url, the confirm-only-for-existing-site rule, and 'Does not charge.' Annotations already declare destructive/readOnly/openWorld/idempotent, so the description is not carrying that burden alone. Minor gap: it doesn't describe the response aside from confirm=false returning a change description.

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?

Dense and front-loaded: the auth requirement and core action lead, then usage branches. No filler sentences, though the run-on style (many short clauses) slightly reduces scannability.

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-param, no-output-schema, destructive mutation tool, it covers auth, branching, destruction (unlink via empty url), and cost. Missing only an explicit statement of what the call returns on success and any rate/limit notes.

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 baseline is 3. The description goes beyond the schema by tying parameters together: empty url + site unlinks, confirm applies only to existing sites, paths default to /api/* and only apply in split mode. That cross-parameter semantics is genuinely additive.

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 ('Links an HTTPS backend ... to a DropTheHassle name') and enumerates the hosting providers accepted. Distinguishes itself from siblings like connect_domain or split_domain by naming the backend-linking operation explicitly.

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?

Explains the main branches clearly: with/without uploaded files, with/without site, empty url removes the link, and confirm semantics for existing vs new sites. It does not name sibling alternatives (e.g., connect_domain vs set_backend) for an agent choosing between them, which keeps this at 4.

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

All DropTheHassle toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources