Skip to content

Creating a tool

A tool packages executable logic — a Function, an MCP server, or a Storm workflow — into a reusable, versioned endpoint you can run in the app or call via API. There are two ways to build one, and both use the same Tool Editor.

  • Chat with RivalBot (recommended). Describe what you want; RivalBot generates the code, test cases, metadata, and icon, then drops you into the editor to review. See Building with RivalBot.
  • Manual. Start from a blank tool and fill in each step yourself.

Make sure you have access to an organization, you know what the tool should do and what its inputs and outputs look like, and you know which language you want — Python, JavaScript, Lua, or Storm.

  • Basic Info — the tool’s identity: a unique name, a short description, and category/sectors/tags that drive marketplace search. You also pick the language and type here (both are fixed once chosen).
  • Code — the main development surface: write your handler, define the input schema and events, attach environment secrets, and use the test panel to run test cases against your draft.
  • Branding — upload an icon or have RivalBot generate one.
  • Overview — a short, plain-language description of what the tool does and when to use it; the first thing a marketplace user reads.
  • Documentation — long-form markdown: inputs, outputs, example calls, edge cases.
  • Publish — set visibility (Private or Public), pricing (free or paid per run), and release notes, then publish. Public tools are queued for marketplace review.

Your tool gets a stable URL, is callable via the API, and appears in My Tools, where you can monitor runs, publish new versions, edit metadata, or deprecate it. A good habit: ship a small, reliable v1 first — every publish creates a new immutable version, so you can iterate freely.

Building follows the same flow, but whether a team member’s tool needs admin approval before others can use it is set by governance. See Versions & Publishing and the Capability matrix.