Skip to main content
Glama

Change a drop's settings

dropyour_update_settings
Idempotent

Change a drop's visibility (private = link-only + noindex, public = indexable), its expiration, or remove the "Hosted on Dropyour" badge (badgeHidden — Pro account token required), or its private name (name — empty string clears it), or email notifications to its owner and collaborators on each NEW record of an app with a server (notifications: on/off, each time / hourly / daily digest, link only, which collections, which fields are sensitive and never emailed). or the per-visitor write limit of an app with a server (limiteVisiteur: eteinte = off, normale = 30 writes per minute, stricte = 5 writes per minute, counted per app and per visitor BEFORE your server.js runs; beyond it the visitor gets 429 with Retry-After and your code is not called). It exists because your server code never receives the visitor's IP address: it cannot tell two anonymous visitors apart, and a robot flooding a public form would fill the app's data with junk and use up its ceilings. Every request other than GET, HEAD and OPTIONS counts; reads are never limited, so a GET route that writes is not protected. A signed-in visitor is counted by their visitor id and also by their address (120 writes per minute for all signed-in visitors of one address), an anonymous one by their network address, which is used only as the short-lived key of the counter: never logged, never stored, never passed to the app. An app that becomes a server app for the first time starts at normale; an app that already had its server before this setting existed stays off until its owner sets it. Switching to public triggers a stricter content re-scan and may be rejected. With an account token, owned drops need no managementToken.

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": {
      "dropId": "<dropId>"
    },
    "name": "dropyour_update_settings"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoA private name for this drop (only you see it). Empty string clears it.
tagsNoPrivate tags — replaces all tags. Empty array clears them.
dropIdYes
publishAtNoScheduled go-live (ISO datetime) — the drop returns 404 until then (future, before expiration). Empty string = publish now.
visibilityNo
badgeHiddenNoRemove the Dropyour badge — requires a Pro account token
notificationsNoEmail notifications on new records (owner and collaborators only ; requires the app to belong to an account)
limiteVisiteurNoPer-visitor write limit of an app with a server: eteinte (off), normale (30 writes/min), stricte (5 writes/min). Refused on an app without a server.
managementTokenNo
expiresInSecondsNoExpiration in seconds (1h..2592000) or "default" (your tier's default)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / limiteVisiteur
      Added value: +{
      +  "description": "Per-visitor write limit of an app with a server: eteinte (off), normale (30 writes/min), stricte (5 writes/min). Refused on an app without a server.",
      +  "enum": [
      +    "eteinte",
      +    "normale",
      +    "stricte"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / notifications
      Added value: +{
      +  "description": "Email notifications on new records (owner and collaborators only ; requires the app to belong to an account)",
      +  "properties": {
      +    "actif": {
      +      "description": "Turn email notifications on or off",
      +      "type": "boolean"
      +    },
      +    "champsSensibles": {
      +      "description": "Field names never put in the email (in addition to the ones detected by name : passwords, payment, identity, health, attachments)",
      +      "items": {
      +        "type": "string"
      +      },
      +      "maxItems": 50,
      +      "type": "array"
      +    },
      +    "collections": {
      +      "description": "Collections to watch ; empty or absent = all",
      +      "items": {
      +        "type": "string"
      +      },
      +      "maxItems": 20,
      +      "type": "array"
      +    },
      +    "frequence": {
      +      "description": "chaque = each new record (grouped, at most one email per 5 minutes) ; heure = hourly digest ; jour = daily digest around 7-8 am Paris",
      +      "enum": [
      +        "chaque",
      +        "heure",
      +        "jour"
      +      ],
      +      "type": "string"
      +    },
      +    "lienSeulement": {
      +      "description": "true = no record content in the email, only the count and a link",
      +      "type": "boolean"
      +    }
      +  },
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / tags
      Added value: +{
      +  "description": "Private tags — replaces all tags. Empty array clears them.",
      +  "items": {
      +    "maxLength": 32,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 8,
      +  "type": "array"
      +}
  4. Changed3 schema fields changed
    • changedInput schema / properties / expiresInSeconds / anyOf
      Previous value: -[
      -  {
      -    "const": 3600,
      -    "type": "number"
      -  },
      -  {
      -    "const": 86400,
      -    "type": "number"
      -  },
      -  {
      -    "const": 604800,
      -    "type": "number"
      -  },
      -  {
      -    "const": 2592000,
      -    "type": "number"
      -  },
      -  {
      -    "const": "default",
      -    "type": "string"
      -  }
      -]New value: +[
      +  {
      +    "maximum": 2592000,
      +    "minimum": 3600,
      +    "type": "integer"
      +  },
      +  {
      +    "const": "default",
      +    "type": "string"
      +  }
      +]
    • addedInput schema / properties / expiresInSeconds / description
      Added value: +"Expiration in seconds (1h..2592000) or \"default\" (your tier's default)"
    • addedInput schema / properties / publishAt
      Added value: +{
      +  "description": "Scheduled go-live (ISO datetime) — the drop returns 404 until then (future, before expiration). Empty string = publish now.",
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / name
      Added value: +{
      +  "description": "A private name for this drop (only you see it). Empty string clears it.",
      +  "maxLength": 80,
      +  "type": "string"
      +}
  6. Changed1 schema field changed
    • changedInput schema / properties / expiresInSeconds / anyOf
      Previous value: -[
      -  {
      -    "const": 3600,
      -    "type": "number"
      -  },
      -  {
      -    "const": 86400,
      -    "type": "number"
      -  },
      -  {
      -    "const": 604800,
      -    "type": "number"
      -  },
      -  {
      -    "const": 2592000,
      -    "type": "number"
      -  }
      -]New value: +[
      +  {
      +    "const": 3600,
      +    "type": "number"
      +  },
      +  {
      +    "const": 86400,
      +    "type": "number"
      +  },
      +  {
      +    "const": 604800,
      +    "type": "number"
      +  },
      +  {
      +    "const": 2592000,
      +    "type": "number"
      +  },
      +  {
      +    "const": "default",
      +    "type": "string"
      +  }
      +]
  7. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only supply idempotentHint=true and destructiveHint=false, and the description goes well beyond them: badgeHidden needs a Pro account token, switching to public triggers a stricter content re-scan and may be rejected, and the account-token path removes the need for managementToken. It also explains the enforcement mechanics of limiteVisiteur in detail (counted before server.js runs, 429 with Retry-After, reads never limited, defaults for first-time vs pre-existing server apps). It stops short of saying what happens on partial failures or invalid values, and omits the tags/publishAt behaviors entirely.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core content sits in one enormous 'or ... or ... or' sentence that chains unrelated settings together and is difficult to parse. Several sentences are devoted to rate-limit rationale ('It exists because your server code never receives the visitor's IP address...') rather than to how to call the tool. Information is not grouped or front-loaded by setting, so an agent must re-read to extract the actionable parts.

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?

For a 10-parameter mutation with a nested notifications object, no output schema, and only weak annotations, the description does a fair job on permissions and rejection risk. However, it leaves tags and publishAt undocumented, does not say what a successful response contains or whether changes are partial, and spends disproportionate space on one setting's rationale rather than covering all editable fields evenly.

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?

With 70% schema coverage and 10 parameters, the description meaningfully enriches several: it names the Pro-token prerequisite for badgeHidden and explains the semantics of each limiteVisiteur value far beyond the enum in the schema. The notifications and name semantics largely restate existing schema descriptions, and tags is not mentioned at all in the description. Net value is real but uneven across the ten parameters.

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 gives a clear verb ('Change') and resource ('a drop's settings') and enumerates the mutable settings: visibility, expiration, badge, name, notifications, and the per-visitor write limit. An agent can identify the tool's domain without opening the schema, but the purpose is buried in a single run-on sentence that makes the scope hard to scan. It also never distinguishes itself from siblings such as dropyour_patch, dropyour_publish, or dropyour_schedule.

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?

There is no explicit when-to-use or when-not-to-use guidance and no routing to alternative tools, even though dropyour_patch and dropyour_schedule are plausible alternatives for adjacent edits. The only actionable usage note is at the very end: 'With an account token, owned drops need no managementToken,' which covers the auth path but not tool selection. Usage must be inferred from the enumerated settings.

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.