Events & Test Cases

When you build a tool on Rival, two related concepts show up everywhere: events and test cases. They sound similar, but they play different roles - one is the input your tool receives, the other is how you prove your tool works before publishing.

---

Event

An event is the JSON input that gets passed to your tool when it runs. Every time someone executes your tool - from the app, through the Marketplace, or over the API - they’re sending an event.

The shape of an event is up to you. A few examples:

• A Function event: { "texts": ["Summarize this article..."] }
• An MCP event: { "jsonrpc": "2.0", "method": "tools/list", "params": {} }
• A Storm event: { "texts": ["classify this dataset"] } paired with a topic file reference

You create and save events in the Preview tab inside the Tool Editor. Each saved event has a name and a JSON body. Saving an event makes it reusable - you can run it again with one click, import it in the upcoming versions of the same tool, and use it as the basis for a test case.

Tip

Give your events descriptive names that reflect the input they represent - e.g. short_text_sample or batch_of_10_tickets. This makes it easier to manage many events as your tool evolves.

---

Test case

A test case is a saved event paired with the expected output. It’s how you verify your tool behaves the way you expect before publishing.

When you create the Event (the input JSON), and pair it with its name and the expected output, it is called a Test case.

This matters because events or test cases are part of publish readiness. The Automatic Validation Pipeline checks that you have at least one runnable test case before letting you publish. A tool with no test case can’t go live.

Note

Every test case is built on an event. The difference is what you do with it: an event is the input; a test case is the event plus the result you expect to see.

---

Where they live in the Tool Editor

Events or Test Cases live inside the Preview tab of the Tool Create/Edit flow:

• The Events list lets you add, name, edit, and save event payloads.
• A Run button next to each one executes it against your current code.

When you publish, the test cases you’ve defined become the runnable examples on your tool’s Marketplace detail page. Users browsing your tool can hit “Run” and see it work with real input.

---

Why this matters

Rival’s Marketplace is built around executable examples - users on a tool’s detail page can run the tool right there, with real inputs. The events and test cases you save during development are exactly what shows up there.

The practical loop while building:

1. Sketch the input shape your tool expects.
2. Save an event with realistic data.
3. Run it from the Preview tab, confirm the output looks right.
4. Save the event.
5. Repeat for any edge cases that matter.
6. Publish.

By the time you ship, your test cases double as the working demos that sell your tool to users.