Skip to content
Rival Docs

Creating a Tool

Overview

Creating a tool on Rival lets you package executable logic - whether it’s an AI-powered function, MCP server, or Storm workflow - and make it available for execution via the platform or API.

The tool builder provides a structured, step-by-step interface that guides you through defining your tool’s behavior, testing it, and publishing it as a reusable, versioned endpoint.

Before you start

Before creating a tool, make sure:

  • You have access to an organization
  • You understand what your tool is meant to do
  • You have your logic, prompts, or workflow ready
  • You know which runtime (Python, JavaScript, or Lua) you’ll use

Opening the tool builder

To start creating a tool:

  1. Log in to Rival
  2. Navigate to My Tools
  3. Click Create New Tool

This opens the tool builder, which walks you through each step required to define and publish your tool.

Tool building steps

Step 0 - Review

This step provides a high-level overview of what you are about to configure. It is only visible once the tool has been published.

It summarizes key concepts such as tool types, runtime behavior, versioning, pricing, and how reviews and Q&A work on your tool after publishing.

Step 1 - Basic Info

This step defines your tool’s identity and how it will be discovered across the platform.

You will configure the tool name (unique within your organization), a short description for listings, and classify the tool using category, sectors, and tags. These fields directly influence how your tool appears in marketplace search and filtering.

You will also select the runtime and compute type. These are important architectural decisions - once set, they cannot be changed for that tool.

Step 2 - Code & Test

This is the core development environment where your tool’s logic is implemented, configured, and validated.

Events and test cases

Each tool can define one or more execution events. These represent different ways the tool can be triggered.

When creating events or test/use cases, you can choose between a JSON editor for precise structured input or a form builder for a more guided configuration experience. Both approaches produce the same underlying schema.

Input schema

The input schema defines how your tool receives data. It specifies parameter names, types, and validation rules, ensuring consistent execution and predictable behavior.

Environment variables

Environment variables allow you to securely manage configuration such as API keys, tokens, or reusable constants.

They are managed globally from Workspace Settings, and can be attached or removed from individual tools as needed. This makes it easy to reuse configuration across tools while keeping control at the organization level.

Working with code

The code editor is where you implement your tool logic.

Python runtime supports adding multiple files to your tool, enabling more complex structures. JavaScript and Lua runtimes are limited to single-file execution.

Testing

You can test your tool directly within this step by providing inputs and executing it. This allows you to verify behavior before publishing.

Step 3 - Icon & Branding

This step controls how your tool appears visually.

You can upload a custom icon or generate one using AI. While optional, good branding improves visibility and recognition in the marketplace.

Step 4 - Overview

Here, you describe your tool at a conceptual level.

This includes explaining what the tool does, when it should be used, and any limitations or strengths it has. This section helps users quickly understand whether your tool fits their needs.

You can generate this automatically using AI.

Step 5 - Documentation

This section allows you to write detailed markdown documentation for your tool.

It should cover inputs and outputs, example usage, and edge cases or expected behavior.

Step 6 - Publish

This is where your tool is finalized and released.

Versioning

Instead of manually entering version numbers, you select the type of update: Patch for small fixes, Minor for backward-compatible improvements, or Major for breaking changes. Rival automatically generates the version name based on your selection.

Pricing

For public tools, you can define pricing such as free usage or paid execution.

What happens when you publish

Publishing creates a new version of your tool and makes it callable via API.

If the tool is public, it becomes visible in the marketplace for discovery and usage.

At the same time, Rival triggers an automatic tool verification pipeline. This system evaluates whether the tool behaves as described, checks for security issues, and validates execution correctness. Based on this process, the version is either approved or flagged. Only approved versions should be exposed for public usage.

Versioning after publishing

Each published version represents a fixed snapshot of your tool.

Once a version is published, it cannot be modified. Existing versions remain unchanged, and any updates require publishing a new version. This ensures stability for users integrating your tool.

Managing your tool after launch

After publishing, your tool becomes a living product that you can continue to improve and manage.

You can update metadata, create new versions, monitor usage, adjust pricing, or deprecate older versions when needed.

Next steps

After creating your tool, you can test it with real inputs, explore similar tools in the marketplace, integrate it into your applications via API, and debug issues using logs and execution insights.