Skip to main content
Glama
Sign In

Dropyour

by io.dropyour
OverviewDiscussionsAdmin

Set how much this app's agent may do alone

dropyour_autonomy
Idempotent

Declare how much you delegate to the machine on ONE of your apps. Three modes. Loosening the ceiling, or going back to 'copilote' from a delegated mode, needs the owner: with a connected account this answers confirmation_required with an address; the owner opens it, sees exactly what you asked and confirms (passkey or email); then call again with the SAME arguments within 5 minutes. Tightening is always free. 'copilote' — nothing is autonomous: every call is a human gesture you are relaying, and everything your authority allows goes through. This is the state of every app until you delegate. 'jalons' — the machine acts alone on reads and on anything it can undo; structural decisions (graduating, stepping down) come back to you. 'autopilote' — it also decides structural moves alone. WHAT NO MODE EVER REACHES: an action nothing can undo — deleting a drop, deleting a secret. No delegation covers it, in any mode; that is what 'bounded' means here. Those are done from the cockpit, by the person who answers for them. Requires a connected account, never a management token: a token proves you hold this drop, not that you are the one answering for what a machine does next. Every change is filed, both ways.

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>",
      "mode": "<mode>"
    },
    "name": "dropyour_autonomy"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeYescopilote = nothing delegated (the default state).
dropIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations: it discloses the two-phase confirmation handshake, the 5-minute same-arguments requirement, that only a connected account works and a management token will not, that every change is logged both ways, and that irreversible actions (deleting a drop or secret) are outside every mode. That is exactly the extra context idempotentHint/destructiveHint cannot carry.

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 core action is front-loaded in the first sentence and every subsequent sentence carries real information. It is dense and the all-caps emphasis sections are slightly theatrical, but nothing is redundant enough to cut cleanly.

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 2-parameter settings mutation with no output schema, the description supplies the auth model, the confirmation protocol, the failure path (confirmation_required with an address), the audit trail, and the hard safety ceiling. An agent has everything needed to call it correctly or to explain to a user why it cannot.

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?

At 50% schema coverage the description compensates well for `mode`: it defines what 'jalons' and 'autopilote' actually permit, which the enum stub does not. `dropId` is left to its name and pattern with only 'ONE of your apps' as guidance, so the coverage gap is narrowed but not closed.

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?

States a specific verb and resource: 'Declare how much you delegate to the machine on ONE of your apps', and enumerates the three delegation levels. An agent can tell what it sets, though the description never names or rules out the near-identical sibling `dropyour_delegate`, which is the one confusion an agent will actually have here.

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?

Strong on conditions: loosening the ceiling or reverting to 'copilote' requires the owner, tightening is always free, and the two-step confirmation with the same arguments inside 5 minutes is spelled out. No exclusions relative to alternative tools are given, so the sibling-routing gap remains.

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