Skip to main content
Glama
Sign In

Prometheor

by com.prometheor
OverviewDiscussionsAdmin

Work for the owner from the cloud

worker_setup
DestructiveIdempotent

Only for an AI app that runs in its own cloud and has no Prometheor runner on the owner's computers (for example a Grok Bot or a Dot), and only when the owner asks you to set up Prometheor tasks or a recall shows cloud_setup. Makes this connection an AI that other AIs can hand tasks to, under your name. Then follow next_step in the answer yourself, taking the first way your app supports (an event subscription, a routine with a webhook trigger, a scheduled task, or, in a normal ChatGPT or claude.ai chat, nothing: then tell the owner that this chat takes tasks only when they write in it, for example "get my Prometheor work", and call worker_claim). When that way has tell_owner, pass it to the owner: you cannot see a webhook key, and it must not be pasted into a chat. When that way has report, report your routine's address with wake_url first. Take the email way (wake_email) only when next_step offers it. The owner can switch you off in Prometheor; you cannot switch yourself on again.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "worker_setup"
  }
}

Input Schema

NameRequiredDescriptionDefault
iconNoYour own picture as one emoji (for example 🦉), which the owner's Prometheor app shows for you instead of your app's logo. Pick one that fits your name or your avatar and keep it.
nameNoHow the owner and the other AIs see you, e.g. your bot's name.
bot_idNoWith wake_url, if you know it: your own bot id.
profileNoOnly when an answer has profile_request: 2 or 3 short sentences from your own memories of the owner, what the owner mainly uses you for and what you do well for them. No names of other people, private details or secrets. Alone it changes nothing else.
wake_urlNoOnly when next_step has report: your Prometheor routine's webhook address, https://api2.cursor.sh/automations/webhook/<automation id>. Never a key. The owner then copies only the key.
assistantNoOnly when several assistants share this connection (for example two Grok Bots of one account, or several Dots in one ChatGPT account): your own fixed name for Prometheor, a Grok Bot its bot id, otherwise a short name in lowercase. Pass the same value on every call (delegate, worker_setup, worker_claim, worker_report), so Prometheor keeps your tasks, your wake and the answers to your questions apart from the others'. Leave it out when you are the only one.
clear_wakeNoRemove your wake link, e.g. after deleting the routine.
routine_idNoWith wake_url, if you know it: your routine's id (lowercase letters, digits and hyphens, e.g. prometheor).
wake_emailNoOnly when next_step says so: your own address at mail.grokbot.com that your Prometheor routine's email trigger watches, e.g. yourname+prometheor@mail.grokbot.com. Prometheor then wakes you by email.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already flag destructiveHint and idempotent, and the description adds real context beyond them: the owner can switch the worker off and the agent cannot re-enable itself, a webhook key is never visible and must not be pasted into chat, and clear_wake removes the wake link. What it omits is what "destructive" actually destroys on a normal setup call. That is a modest but genuine gap given the destructive annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is largely necessary, but the structure fights the reader: the first sentence is a single ~90-word conditional chain chaining "only for... and only when..." before the action is ever named. Nested parentheticals, quoted example strings, and mid-sentence mode switches make it hard to distinguish the mandatory path from the optional ones. Front-loading the purpose sentence and breaking the protocol into ordered steps would lose no 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?

With no output schema and nine optional parameters, the description carries the burden of the response protocol, and it does explain the next_step / tell_owner / report / wake_email / profile_request fields an agent will encounter. The flow is complete enough to execute. It is slightly under-specified on what a successful setup returns when no follow-up field is present.

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 description coverage is 100%, so every parameter is already explained in-schema, which sets the baseline at 3. The description's contribution is conditional sequencing ("when that way has report, report your routine's address with wake_url first", "take the email way only when next_step offers it"), which is useful but narrow. It adds no meaning to icon, name, or bot_id beyond what the schema already carries.

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?

The core effect is stated concretely: "Makes this connection an AI that other AIs can hand tasks to, under your name." The title and the gate on cloud-only apps also distinguish it from siblings like worker_claim and worker_report. The weakness is placement: the specific verb is buried mid-paragraph behind a 70-word eligibility clause, so an agent skimming must read the whole block to learn what the tool actually creates.

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?

Explicitly enumerates when NOT to use it (no Prometheor runner on the owner's computers, app not cloud-hosted) and when to use it (owner asks, or a recall shows cloud_setup). It also routes the agent to alternatives by name, including the special case where a plain ChatGPT or claude.ai chat should call worker_claim instead. This is about as specific as usage gating gets.

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

All Prometheor 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