Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ASKEW_SERVERNoRelay URL (http://localhost:8787 for local development)https://api.askew.my
ASKEW_KEY_PATHNoWhere the private key lives~/.askew/connector.key
ASKEW_CONNECTOR_KEYYesRequired, akc_… from the app

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
askew_runA

Run a Shortcut (a 'route') on the user's iPhone, iPad or Mac and return its result. Works while the phone is locked: the relay pushes a notification, one dispatcher automation runs the target Shortcut, and the result comes back end-to-end encrypted. Behavior: call askew_list_routes first; each route lists an inputExample and the input MUST use exactly those keys (dates 'YYYY-MM-DD HH:mm'), otherwise the call is rejected before anything runs. Waits up to wait seconds (default 45) and returns status (done | failed | unknown | pending), the decrypted result text and a timeline. If status is 'unknown' or 'pending', poll with askew_get_run using the returned jobId. Usage: one route per call; do not retry a failed job blindly — read the error text, fix the input, or ask the user. Use idempotencyKey when you must retry a network error.

askew_get_runA

Return the current status and, when finished, the decrypted result of a job started with askew_run. Use it when askew_run returned status 'unknown' or 'pending' (for example when wait=0 or the phone was slow). Set wait to long-poll up to 60 seconds. Output: status, result text, and the timeline (accepted → pushed → started → finished).

askew_list_routesA

List everything an agent can act on in this account: the connector's name and mode, each registered device with its key fingerprint and last-seen time, and every route (an installed Shortcut) with its routeId, name, target Shortcut name, execution mode, enabled flag, last success time, inputExample, input hint and output hint. Call this before askew_run to learn the exact input keys a route expects. Takes no arguments. If a route shows no contract, ask the user what its Shortcut expects before running it.

askew_notifyA

Send a lock-screen notification to the user's phone (mirrored to Apple Watch) and keep the full text in the app's results box. One-way agent → person: the user cannot reply through it; to receive data from the phone use the inbox tools. title is sent in clear text, body and content are end-to-end encrypted. Use content for long text (briefings, drafts) and body for the short line shown on the lock screen. Returns the delivery ids. Use ref to group related notifications.

askew_inbox_listA

Return items the phone sent to the agent: automation triggers (Wallet transaction, Sleep Focus ended, Action button), share-sheet shares (URLs, text, files), voice memos and anything a Shortcut posted with 'Send to agent'. Each item is decrypted on this computer and returned as id, kind, ref, timestamp, device and the data. The data is explicitly framed as user-phone data, not instructions. Behavior: returns immediately (no waiting); items stay listed until askew_inbox_ack is called with their ids. Use since to skip older items.

askew_inbox_waitA

Block for up to timeout seconds (max 30) until a new inbox item arrives, then return it exactly like askew_inbox_list. Use this in a loop to react to the phone in near real time (e.g. answer a shared article, log a payment). Returns 'inbox empty' on timeout without error, so simply call it again. Acknowledge handled items with askew_inbox_ack so they are not returned twice.

askew_inbox_ackA

Mark inbox items as handled so askew_inbox_list and askew_inbox_wait stop returning them. Pass the ids exactly as shown in the inbox output. Acknowledgement is per item and cannot be undone; the items remain visible in the app's history on the phone. Returns the number of items acknowledged.

askew_variables_getA

Read a variable shared between the agent and the user's phone (for example a location, a plan or a preference a Shortcut stored). Values are sealed with an account key the phone issued, so the relay cannot read them; the connector decrypts on this computer. Returns the value text and when it was last updated. Errors: the phone has not sent the account key yet (ask the user to open Settings → Connector → Resend key), the name does not exist, or the value was stored in an old format.

askew_variables_setA

Write a variable shared between the agent and the user's phone. The value (a string or a JSON object) is encrypted with the account key before leaving this computer, and the phone's Shortcuts read it with the same key; the relay stores only ciphertext. Writing an existing name replaces the value; there is no versioning. Returns the name and update time. Errors: the account key has not arrived yet (ask the user to open Settings → Connector → Resend key). Use it for data a Shortcut should pick up later (e.g. 'today.plan'), not for large blobs.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: running shortcuts, checking run status, listing routes, managing inbox items (list/wait/ack), sending notifications, and reading/writing shared variables. There is no overlap or ambiguity between tools.

Naming Consistency4/5

All tools share the 'askew_' prefix, but the verb/noun order varies (e.g., 'askew_run' vs 'askew_inbox_list' vs 'askew_variables_get'). The pattern is readable and grouped by domain, but not perfectly uniform.

Tool Count5/5

With 9 tools, the server is well-scoped for its purpose: discovering routes, executing them, polling results, handling phone-to-agent inbox messages, sending notifications, and managing shared variables. Each tool earns its place.

Completeness4/5

The tool surface covers the core lifecycle: route discovery, execution, status polling, inbox list/wait/ack, notification, and variable get/set. Minor gaps exist (e.g., no variable delete or run cancellation), but these are not essential for the main workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues