Dropyour

Link one app to another, and state what it relies on

dropyour_link

DestructiveIdempotent

Let one of your graduated apps call ANOTHER of your apps over the network. By default no app can reach another — that refusal is the platform's isolation, not an oversight. This opens exactly the app you name, by its dropId, and only if it belongs to the SAME account: a link never crosses two accounts. action='delier' revokes it (and its contract), and revoking asks nothing — taking a right back cannot be harder than granting it. To put a revoked link back, call 'lier' again with the same contrat (and 'subscribe' again with the same routes for the subscriptions it carried): dropyour_system action='view' shows the revocation, its contract, the subscriptions it removed and who did it, for 30 days; the owner can also put it back from the activity, after the same compatibility check. Eight links at most: beyond that it is not a contract between apps any more, it is a network, and it gets decided differently. Over a link, the called app knows who calls: its server code sees app.caller = { dropId } of the calling app, signed by the platform and impossible to forge; every other request sees null. CONTRACT (optional, recommended): pass contrat with action='lier' to state what the calling app relies on — up to 8 READ routes (GET or HEAD), each with the status it expects (default 200) and, for GET, a MINIMAL JSON Schema of the response (extra fields are always allowed). From then on, every new version of the called app published with dropyour_release, dropyour_replace or dropyour_patch is checked against it BEFORE it stays live: if a route breaks, the version is refused, the previous one is put back, and the answer names the consumer and the route. Calling 'lier' again with a new contrat replaces it (its revision goes up); action='retirer_contrat' removes it and keeps the link. Write methods are refused in a contract: the checks run against the called app's REAL data. action='consommateurs' (dropId = the CALLED app, no cible) lists which apps rely on it and under which contract. What a link does NOT do: it grants no token and no shared storage. Your app calls the other one over plain HTTP, and the other one's own guards apply unchanged: it decides what a linked caller may do.

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>",
      "action": "<action>"
    },
    "name": "dropyour_link"
  }
}

Input Schema

Name	Required	Description
`cible`	No	The app to be called. Must belong to the same account. Required except for action='consommateurs'.
`action`	Yes	lier = open (with an optional contract), delier = revoke, retirer_contrat = drop the contract and keep the link, consommateurs = list the apps relying on dropId.
`dropId`	Yes	The app that will CALL (for action='consommateurs': the app being called).
`contrat`	No	What the calling app relies on in the called app. Only with action='lier'.
`managementToken`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 12, 2026

changedInput schema / properties / action / description

Previous value: -"lier = open, delier = revoke."New value: +"lier = open (with an optional contract), delier = revoke, retirer_contrat = drop the contract and keep the link, consommateurs = list the apps relying on dropId."

changedInput schema / properties / action / enum

Previous value: -[
-  "lier",
-  "delier"
-]New value: +[
+  "lier",
+  "delier",
+  "retirer_contrat",
+  "consommateurs"
+]

changedInput schema / properties / cible / description

Previous value: -"The app to be called. Must belong to the same account."New value: +"The app to be called. Must belong to the same account. Required except for action='consommateurs'."

addedInput schema / properties / contrat

Added value: +{
+  "description": "What the calling app relies on in the called app. Only with action='lier'.",
+  "properties": {
+    "routes": {
+      "items": {
+        "properties": {
+          "expectStatus": {
+            "description": "Default 200.",
+            "maximum": 599,
+            "minimum": 100,
+            "type": "integer"
+          },
+          "method": {
+            "description": "GET (default) or HEAD. Write methods are refused.",
+            "maxLength": 10,
+            "type": "string"
+          },
+          "path": {
+            "description": "Path in the CALLED app, starting with '/'.",
+            "maxLength": 2048,
+            "type": "string"
+          },
+          "responseSchema": {
+            "additionalProperties": {},
+            "description": "Minimal JSON Schema of the response body (GET only, 4KB for the whole contract, no 'pattern').",
+            "propertyNames": {
+              "type": "string"
+            },
+            "type": "object"
+          }
+        },
+        "required": [
+          "path"
+        ],
+        "type": "object"
+      },
+      "maxItems": 8,
+      "minItems": 1,
+      "type": "array"
+    }
+  },
+  "required": [
+    "routes"
+  ],
+  "type": "object"
+}

changedInput schema / properties / dropId / description

Previous value: -"The app that will CALL."New value: +"The app that will CALL (for action='consommateurs': the app being called)."

changedInput schema / required

Previous value: -[
-  "dropId",
-  "cible",
-  "action"
-]New value: +[
+  "dropId",
+  "action"
+]

AddedSep 3, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare idempotentHint and destructiveHint; the description adds the same-account constraint, the 8-link limit and its rationale, the fact that revocation needs no confirmation, the app.caller identity injected into the called app's server code, and, importantly, the negative scope: 'it grants no token and no shared storage' and the called app's own guards still apply. That is behavioral context structured fields cannot carry, and nothing contradicts the annotations.

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?

Purpose is front-loaded and nearly every sentence carries operational information (limits, revocation semantics, caller identity, contract checks). It is, however, a dense unbroken block of roughly 300 words with parenthetical asides that could be split into scannable clauses rather than one wall of text.

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 tool with a nested contract object, no output schema and destructive actions, the description covers what happens on grant, replace and revoke, what the publish-time check returns ('the answer names the consumer and the route') and where to inspect revocation history. The missing pieces are the managementToken/auth requirement and the shape of the 'consommateurs' listing.

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 80%, so many fields are already documented, but the description adds real meaning: contrat caps at 8 READ routes with expected status and a minimal response Schema, write methods are refused because checks run against real data, re-passing contrat bumps the revision, and dropId's role flips for 'consommateurs'. The one gap is managementToken, which is undocumented in both the schema and the description.

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?

The opening sentence gives a precise verb and resource ('Let one of your graduated apps call ANOTHER of your apps over the network') and immediately frames it against the platform's default isolation, which no sibling tool does. An agent can tell this apart from dropyour_call, dropyour_egress_deny or dropyour_delegate without opening a 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 per-action guidance: 'lier' opens, 'delier' revokes, 'retirer_contrat' drops the contract and keeps the link, and 'consommateurs' takes dropId as the CALLED app with no cible. It also states the 8-link ceiling, points at dropyour_system action='view' for revocation history, and names dropyour_release/dropyour_replace/dropyour_patch as the tools that trigger contract checks.

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

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