Skip to main content
Glama
Sign In

Dropyour

by io.dropyour
OverviewDiscussionsAdmin

Check a drop's status

dropyour_status
Read-only

Get a drop's status: URL, visibility, expiration, size, approximate view count, and its private name (if set). With an account token, owned drops need no managementToken. This reads the DROP's record, not its running app: for a graduated app's live state — is it frozen, when does its clock ring, what did the last runs do — call dropyour_schedule, which asks the app itself. For a server app, dossier is its proof dossier (pending, ready or failed, with the reason and the step where it stopped); a ready one carries verdict: the runward verdict (clean or gaps), the runward version, the number of decisions (ADR) in the app's mission, the number of gaps, and when it was produced. Read it after you change the app, and tell the owner what it says. For a server app, usageDuMois is this month's usage (owner only): page views, the views included in its plan (plafond, fair use), and its state: sous_le_plafond; a_prevenir (at 80 %, or earlier when the month's pace would pass the included views, depassementVers being that day of the month); depasse (with the consecutive months). Nothing is ever cut, whatever the state: tell the owner that first. To go further, the owner replies to the usage email or writes to support: a person answers, with a custom quote if needed.

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_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
dropIdYes
managementTokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

The readOnlyHint annotation already establishes the safety profile, and the description adds substantial context beyond it: authentication behavior, the record-versus-running-app distinction, dossier states, usage states, and the fact that usage is never cut. These details help the agent interpret results correctly.

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?

The core purpose is front-loaded, but the description is dense and includes policy and escalation details, such as replying to the usage email or contacting support, that are not necessary for invoking the tool. The return-field detail is useful without an output schema, but the prose is longer than needed.

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?

Because there is no output schema, the description appropriately explains the important returned fields and states for dossier and usageDuMois. It is largely complete for a read-only status tool, though it leaves the dropId parameter's format and required nature implicit.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It only partially explains managementToken by noting that owned drops need none with an account token; it does not explain dropId's purpose, required status, or the eight-character lowercase pattern.

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 description states a specific verb and resource, "Get a drop's status," and enumerates the returned fields: URL, visibility, expiration, size, approximate view count, and private name. It also explicitly distinguishes itself from dropyour_schedule by saying this reads the DROP's record, not the running app.

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 gives explicit usage conditions: with an account token, owned drops need no managementToken, and live app state should use dropyour_schedule instead. It also says to read status after changing the app and tell the owner what it says, which provides clear operational context.

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