Skip to main content
Glama

Homespun

by dev.homespun
OverviewDiscussionsAdmin

Manage App Ownership Transfer

transfer
Destructive

A v2 app's ownership transfer (issue #1847): handing the app, and the quota and billing responsibility that come with it, to a different human. This is two steps, and start completing is only the first one. start mints a pending offer and emails the named person an accept link; the app is still owned here when the call returns, stays owned here while the offer is pending, and only moves once that person opens the link and accepts it. Reporting the transfer as done after start would be wrong: check status to see whether it is still pending or has dropped to null (accepted, expired, or withdrawn), and the caller's own agent key stops being able to deploy this app only at the moment it actually moves. Actions: start offers the app to an email address, 409ing if a transfer is already pending or the email already owns the app; status returns the pending transfer, or null if none; cancel withdraws a pending transfer and is idempotent, so cancelling with nothing pending is still a success.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNostart only. The email to offer ownership to. The relay sends that address an accept link; ownership moves only when they open it and accept, never at start itself. 409s if a transfer is already pending for this app, or if the email already owns it.
actionYesA v2 app's ownership transfer (issue #1847). start does not move ownership: it only mints a pending offer and emails the named person an accept link, and the app stays owned here until they open it and accept (app_id+email; optional keep_as_member). status: the app's pending transfer, or null if none is pending (app_id). cancel: withdraw a pending transfer; idempotent, so cancelling with none pending is still a success (app_id).
app_idYesThe app id.
keep_as_memberNostart only. Whether the current owner stays on as an ordinary member once the transfer is accepted, losing owner powers but keeping app access. Defaults to true. Has no effect unless and until the transfer is actually accepted.

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 beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true): it discloses the two-step offer/accept flow, that the app remains owned here until acceptance, the exact 409 conditions, the timing of when the caller's agent key loses deploy ability, and that `cancel` is idempotent. The annotation's tool-level idempotentHint=false is consistent since `start` is not idempotent, so no contradiction.

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?

Front-loads the purpose, then the two-step flow, then the per-action breakdown, so the structure is logical. It is a single dense paragraph that would scan better as bullets, and the '(issue #1847)' parenthetical is noise, but almost every sentence carries real information.

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?

Covers the workflow, error conditions, and the null return of `status` for a tool with no output schema. It does not describe the shape of a pending-transfer object returned by `status`, which is the one remaining gap for a mutation tool with no output schema.

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

Parameters3/5

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

Schema coverage is 100% and the schema's own descriptions already carry the 409 semantics, keep_as_member default, and the action-to-parameter mapping. The description largely restates this, so it adds only marginal value beyond the structured fields, matching the baseline 3.

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 ('A v2 app's ownership transfer... handing the app, and the quota and billing responsibility that come with it, to a different human') and enumerates its three actions. An agent can distinguish this from sibling tools like `members`, `grants`, or `deploy_app` without opening any schema.

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?

Gives explicit action-level guidance: `start` offers, `status` checks pending/null, `cancel` withdraws and is idempotent, plus a clear warning not to report the transfer done after `start`. It does not, however, contrast this tool with cross-tool alternatives for changing app ownership.

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

All Homespun toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources