Skip to main content
Glama

Dropyour

by io.dropyour
OverviewDiscussionsAdmin

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

dropyour_link
Idempotent

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

Input Schema

NameRequiredDescriptionDefault
cibleNoThe app to be called. Must belong to the same account. Required except for action='consommateurs'.
actionYeslier = open (with an optional contract), delier = revoke, retirer_contrat = drop the contract and keep the link, consommateurs = list the apps relying on dropId.
dropIdYesThe app that will CALL (for action='consommateurs': the app being called).
contratNoWhat the calling app relies on in the called app. Only with action='lier'.
managementTokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • 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"
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only tell the agent this is idempotent and non-destructive; the description carries far more: a hard cap of eight links, that revocation also removes the contract, that the called app sees signed caller identity (app.caller) that cannot be forged while other requests see null, and that contract failures roll back published versions via dropyour_release/replace/patch. These are consequences an agent cannot infer from the schema or 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?

The purpose, constraints, and contract mechanics are front-loaded and each paragraph carries load. It is longer than strictly necessary, though — rhetorical asides ('that refusal is the platform's isolation, not an oversight', 'taking a right back cannot be harder than granting it') consume space that a denser phrasing could save without losing information.

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 five-parameter nested-schema tool with no output schema, the description covers everything an agent needs to call it correctly: account scoping, the eight-link ceiling, per-action requirements, contract semantics, revision behavior, and error behavior ('the answer names the consumer and the route'). Nothing material is left to inference.

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 already 80%, so the baseline is 3, but the description adds genuine meaning on top: `contrat` accepts at most 8 READ routes, write methods are refused, expected status defaults to 200, response schemas are minimal with extra fields allowed, and re-passing a contract bumps its revision rather than duplicating. It also clarifies that dropId is the caller except for consommateurs, where it is the callee.

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 title and opening sentence state a specific verb and resource: let one graduated app call another over the network, opened by dropId. It immediately distinguishes itself from the platform default ('no app can reach another') and from other capabilities by stating that it grants no token and no shared storage, so an agent can tell exactly what this tool is for.

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?

It enumerates the four actions with their conditions (lier opens and optionally attaches a contract, delier revokes, retirer_contrat drops the contract but keeps the link, consommateurs lists dependents), states the same-account constraint ('a link never crosses two accounts'), and gives an explicit exclusion — no token, no shared storage, the called app's guards still apply. This is when-to-use and when-not-to-use guidance in one place.

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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources