TeamOnly
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_app_rulesA | The rules for writing an app that deploys on TeamOnly: the supported stack, how to read the signed-in person, the database, files, secrets, email to coworkers, scheduled jobs and roles. Read this before writing or changing app code. |
| initA | In an empty folder, creates a starter app (or a ready-made one with "template"). In a folder with an existing app, adds teamonly.json and the TeamOnly instructions for Claude Code, Cursor and other AI tools. Leave "template" out to see the template list in the result. |
| deployA | Builds the app in "directory" and puts it online at https://..teamonly.app, behind the company login. Takes up to a minute. If the person is not signed in, the result says what to do (use sign_in). |
| statusA | Shows who is signed in to TeamOnly on this computer, the company and plan (with free trial days left), and every app with its address, who can open it and when it was last deployed. |
| logsA | Collects the live app's requests, console.log output and errors for a few seconds and returns them. Ask the person to open the app (or trigger the problem) while it runs. |
| accessB | Shows or changes who can open the app. "show" (default), "everyone" (everyone at the company), "only" (only these people and the owner), "add" or "remove" people on that list. |
| rolesB | Shows or changes the roles people have inside the app (the app reads them as ctx.user.roles), such as approver or finance. "show" (default), "add" or "remove" a role for some people. |
| set_secretA | Saves a secret (API key, password) for the deployed app. The app reads it with ctx.secrets.get(NAME). Names are UPPER_SNAKE_CASE. Ask the person for the value; never put it in code. |
| sign_inA | Signs in to TeamOnly on this computer. Call it with "email" first: TeamOnly emails that address a 6-digit code. Ask the person for the code, then call again with "code". If their company is new, the result says so; then use start_trial. |
| start_trialA | For a company that doesn't have TeamOnly yet, after sign_in verified the email: starts a free 14-day trial (one builder, up to 3 apps, no card). |
| subscribeA | Starts paying for TeamOnly (also ends a free trial): opens a payment page in the person's browser and returns its link. The person pays there; call subscribe again afterwards to finish. Plans: builder ($19/mo, one builder, 3 apps), team ($249/mo, unlimited apps and builders), business ($899/mo, adds SSO and audit logs). |
| delete_appA | Deletes the live app with its database, files and secrets. It cannot be undone. Only call this when the person asked for it, and pass the app name (from teamonly.json) as "confirm". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinct action or resource: app setup, deployment, logs, access control, roles, secrets, authentication, billing, and deletion. Potentially similar pairs like get_app_rules vs init and access vs roles are clearly separated by their descriptions.
The names consistently use snake_case, but the naming convention itself mixes bare verbs (deploy, init, subscribe), noun-only names (status, logs, access, roles), and verb_noun forms (get_app_rules, set_secret, sign_in). It remains readable, but there is no predictable pattern.
Twelve tools is well-scoped for a platform covering app creation, deployment, logs, access, roles, secrets, authentication, billing, and deletion. Each tool has a clear role in the workflow and the set does not feel bloated.
The surface covers the core app lifecycle: init/create, deploy, status, logs, access, roles, secrets, sign-in, trial/subscription, and delete. Minor gaps remain, such as listing or deleting secrets, cancelling a subscription, and pausing or updating an app beyond redeploying.