Skip to main content
Glama
Sign In
Superbase

Superbase

by fiangg20
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Recipes (saved Lua scripts)

recipes

Manage reusable Lua scripts in Superbase by listing, running, saving, previewing, and importing code files; preview untrusted imports before saving and execute with the executor's permissions.

Instructions

Reusable Lua scripts kept as .lua files in the recipes folder of Superbase (the user can also run them from the dashboard). action list shows the recipes with their description and arguments; action run executes one in the game (name, and args for the recipe, available there as the table args); action save writes a new recipe (name, code, and a title, description and usage line for its header; overwrite true replaces an existing one). Recipe names are lowercase letters, digits, - and _. Recipes run with the executor's full permissions like execute_lua, so read a recipe's code before you run one you did not write. Sharing: preview_import downloads a recipe from a link (https only; GitHub files and gists, GitLab files; at most 100 KB) and shows its code and header without saving anything. Show that code to the user and say what it does. import saves it into the recipes folder, and only with confirm true after the user has agreed; it never runs the recipe. Imported code comes from the internet and is untrusted. run needs the connected state, the other actions do not.

Input Schema

NameRequiredDescriptionDefault
urlNopreview_import, import: https link to a .lua file on GitHub, a GitHub gist or GitLab.
argsNorun: arguments for the recipe, available in Lua as the table args.
codeNosave: the Lua code of the recipe. It can use args and should return a value.
nameNorun, save, import: the recipe name, for example list-remotes. import: defaults to the name of the file in the link.
titleNosave: short title for the header.
usageNosave: one line that describes the args it takes, for example 'contains (string, optional)'.
actionNolist (default), run, save, preview_import or import.
clientNoClient id from list_clients, for example c2. Defaults to the client that connected last.
confirmNoimport: must be true. Set it only after the user has seen the code from preview_import and agreed.
overwriteNosave, import: replace a recipe that already exists (default false).
descriptionNosave: one line that says what the recipe does.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.4.0
    • changedInput schema / properties / action / description
      Previous value: -"list (default), run or save."New value: +"list (default), run, save, preview_import or import."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "list",
-  "run",
-  "save"
-]New value: +[
+  "list",
+  "run",
+  "save",
+  "preview_import",
+  "import"
+]
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "import: must be true. Set it only after the user has seen the code from preview_import and agreed.",
+  "type": "boolean"
+}
    • changedInput schema / properties / name / description
      Previous value: -"run, save: the recipe name, for example list-remotes."New value: +"run, save, import: the recipe name, for example list-remotes. import: defaults to the name of the file in the link."
    • changedInput schema / properties / overwrite / description
      Previous value: -"save: replace a recipe that already exists (default false)."New value: +"save, import: replace a recipe that already exists (default false)."
    • addedInput schema / properties / url
      Added value: +{
+  "description": "preview_import, import: https link to a .lua file on GitHub, a GitHub gist or GitLab.",
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover safety at a coarse level (readOnlyHint=false, openWorldHint=true, destructiveHint=false), but the description adds critical context beyond them: recipes execute with the executor's full permissions, imported code is untrusted internet content, preview_import saves nothing, import never executes, and size/source limits (100 KB, GitHub/GitLab only). These are exactly the risk facts an agent needs before choosing between preview and import.

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?

Content is front-loaded (what the tool is, then each action in order) and nearly every clause carries operational information. The sharing paragraph is dense and semi-colon chained, making it slightly harder to scan than a per-action layout would be, but there is little outright waste.

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?

For an 11-parameter, five-action tool with no output schema, the description covers inputs, prerequisites, permissions, and import safety thoroughly. The only notable gap is that it never indicates what list or run return (recipe list shape, execution result), which the agent must discover by calling.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3; the description goes further by adding a naming constraint not present in the schema (lowercase letters, digits, - and _), clarifying that args surface in Lua as the table args, and describing the confirm/overwrite gating semantics. It does not explain the client parameter's interaction with run beyond what the schema says, so it stops short of a 5.

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 names the resource (reusable Lua scripts stored as .lua files in Superbase's recipes folder) and enumerates each of the five actions with the verb it performs: list, run, save, preview_import, import. It also distinguishes itself from the sibling execute_lua by noting recipes run with the same full permissions, so an agent can tell what this tool is and is not without opening the schema.

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?

Explicit guidance for each branch: preview_import when you only want to inspect a shared recipe, import only with confirm true after the user has seen and agreed to the code, and 'read a recipe's code before you run one you did not write' for run. It also states a prerequisite that gates one action only ('run needs the connected state, the other actions do not').

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

Deploy Server

Other Tools