Skip to main content
Glama
Sign In

Dropyour

by io.dropyour
OverviewDiscussionsAdmin

Store a secret for an app

dropyour_secret_set
DestructiveIdempotent

Store a SECRET for a graduated app (tier 4), bound to a host pattern. The value is encrypted at rest and NEVER readable back — by anyone, ever. The platform's egress membrane attaches it on outbound requests to the declared host, so your server code calls the API WITH NO KEY and never sees it. The membrane sits ABOVE the socket: it does not terminate your TLS and injects no certificate authority into your sandbox — we attach a header, we never open your connection. form says HOW it is attached: bearer (default, Authorization: Bearer), header (X-Api-Key and friends), basic (key as username), or query (?api_key=). The form belongs to the secret, not to your code — changing how an API authenticates never means editing your app. Writing an existing name rotates it: omit form and the secret KEEPS the form it already has (give form only to change it; a new name defaults to bearer). dropyour_secrets_list shows each secret's form (type and field name, never the value). The value cannot contain control characters (line break, tab, NUL). Name: UPPERCASE_WITH_DIGITS (≤32). Host: lowercase domain, leading *. wildcard allowed. Value ≤ 4096 bytes, 16 secrets per app. Requires ownership (account token or managementToken). THIS TOOL TAKES THE VALUE AS A PARAMETER, SO IT PASSES THROUGH THIS CONVERSATION. When the value must not be seen here, do NOT ask the user to paste it: point them to a way that keeps it out. Either the app's page on dropyour.io (Settings, Secrets: a masked field), or one command they run themselves, the value read from their keychain or a file and sent as the request BODY: curl -sS -X PUT --data-binary @- --config <account token header, read from the keychain> "https://dropyour.io/api/drops/<dropId>/secrets/<NAME>?host=<host>" (optional &form=basic, &form=header:X-Api-Key, &form=query:api_key; without form, a replaced secret keeps its form). The exact command is at https://dropyour.io/en/docs/operate#secrets. Same vault, same rules; the response returns the name, host, date and form only. The account token is a secret too: it is read from the keychain in that same command, never pasted here, and passed through --config, never as a command-line argument.

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": "<name>",
      "host": "<host>",
      "value": "<value>"
    },
    "name": "dropyour_secret_set"
  }
}

Input Schema

NameRequiredDescriptionDefault
formNoHow the key is attached at the network boundary. Omitted: a new secret gets bearer (Authorization: Bearer), a rotated one keeps its current form. Use header for X-Api-Key style APIs, basic for key-as-username, query for ?api_key=. Your code never sends the key in ANY of these forms.
hostYesHost pattern the secret is bound to, e.g. api.stripe.com or *.example.com
nameYes
valueYes
dropIdYes
managementTokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / form / description
      Previous value: -"How the key is attached at the network boundary. Default: bearer (Authorization: Bearer). Use header for X-Api-Key style APIs, basic for key-as-username, query for ?api_key=. Your code never sends the key in ANY of these forms."New value: +"How the key is attached at the network boundary. Omitted: a new secret gets bearer (Authorization: Bearer), a rotated one keeps its current form. Use header for X-Api-Key style APIs, basic for key-as-username, query for ?api_key=. Your code never sends the key in ANY of these forms."
  2. Changed1 schema field changed
    • addedInput schema / properties / form
      Added value: +{
+  "description": "How the key is attached at the network boundary. Default: bearer (Authorization: Bearer). Use header for X-Api-Key style APIs, basic for key-as-username, query for ?api_key=. Your code never sends the key in ANY of these forms.",
+  "oneOf": [
+    {
+      "properties": {
+        "type": {
+          "const": "bearer",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "nom": {
+          "description": "Header name, e.g. X-Api-Key",
+          "maxLength": 64,
+          "type": "string"
+        },
+        "type": {
+          "const": "header",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type",
+        "nom"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "type": {
+          "const": "basic",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "type": "object"
+    },
+    {
+      "properties": {
+        "nom": {
+          "description": "Query parameter name, e.g. api_key",
+          "maxLength": 64,
+          "type": "string"
+        },
+        "type": {
+          "const": "query",
+          "type": "string"
+        }
+      },
+      "required": [
+        "type",
+        "nom"
+      ],
+      "type": "object"
+    }
+  ]
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say idempotentHint and destructiveHint; the description goes far beyond them, explaining that the value is write-only and never readable back, that an egress membrane attaches it above the socket without terminating TLS or injecting a CA, that reuse of a name rotates (and keeps the prior form if `form` is omitted), quota limits (16 per app, 4096 bytes), and exactly what the response returns. All of this is consistent with destructiveHint=true, since rotation overwrites a prior value.

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

Conciseness3/5

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

Purpose and security caveat are front-loaded, but the text is roughly 300 words and repeats itself: the `form` attachment semantics are explained in the body, again in the curl parentheticals, and again in the schema, and the 'your code never sends the key' point is made twice. The material is valuable, but it is not tightened.

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 destructive, no-output-schema mutation tool, the description covers the auth requirement, the write-only nature of the value, the return payload (name, host, date, form only), all limits, and the rotation semantics. Nothing an agent needs in order to call it correctly, or to advise a user safely, is missing.

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

Parameters5/5

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

Schema description coverage is only 33%, but the description compensates for nearly every gap: `form` variants with concrete header/query examples, `host` lowercase-and-wildcard rules, `name` uppercase/digit constraint, `value` control-character and size limits, and ownership via account token or managementToken. This is meaning well beyond the JSON Schema, which for `form` alone is a nested oneOf that would otherwise be hard to parse.

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 and resource ('Store a SECRET ... bound to a host pattern') plus the precondition (graduated app, tier 4), and separates itself from the read path by naming dropyour_secrets_list for inspection. An agent can identify what this does versus the sibling list/delete tools without opening the 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?

Gives explicit when-to-use behavior ('writing an existing name rotates it') and, unusually, an explicit when-NOT-to-use-the-tool path: if the value must not be seen in the conversation, point the user to the app page or a self-run curl command instead of having them paste it. That is a concrete routing decision, not implied guidance.

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

All Dropyour toolsInspect
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