I made 19 Apify Actor examples readable by humans and AI agents

A useful API is not enough if people and agents cannot evaluate it safely before running it.

That was the problem I worked on across my 15 public Apify Actors. The tools already had input schemas, README files and pay-per-event pricing. But evaluation still required too much interpretation: which input should I use, what will the output look like, and is this example a real measurement or a technical test?

I now have 19 public Actor task examples. Each one has two surfaces:

• an HTML page for humans;
• a Markdown page that agents can read without parsing the full application.

You can browse them from the toolbox:
https://adagasolutions.lu/toolbox/#examples

What a useful public example contains

A good example is not just a saved run with a catchy title. I use this checklist:

1. A specific user intent, such as monitoring website AI-readiness changes.
2. A small, valid input built from the Actor's current input schema.
3. A successful run with a non-empty dataset.
4. A dataset view containing the fields the reader actually needs.
5. A title and description that match the output.
6. A clear dry-run label when the data is only a technical sample.

The last point matters for my AI Brand Visibility Tracker. Its public example does not pretend to measure a real brand. It proves the workflow without calling an AI provider or charging measurement events.

Here is the example:
https://apify.com/travelmonitorlab/ai-brand-visibility-tracker/examples/preview-ai-brand-visibility-measurement

And its Markdown version:
https://apify.com/travelmonitorlab/ai-brand-visibility-tracker/examples/preview-ai-brand-visibility-measurement.md

Why Markdown changes evaluation

An agent can read the example, inspect the input and output, then decide whether the Actor fits the requested workflow. This is more useful than asking it to infer everything from a marketing description.

It also makes the limitations visible. For example, a brand-visibility result belongs to one model, one prompt set and one run date. It is evidence to compare over time, not a universal ranking.

Reliability is still a separate metric

At the time of writing, the public 30-day counters across the 15 Actors show 351 successful runs out of 353. These counters include my own tests and Apify QA. They are useful for reliability monitoring, but they are not customer counts and not proof of recurring adoption.

I track public examples, run outcomes, Store rankings and reviews separately. Combining them into one vanity metric would hide the real bottleneck.

What I am testing next

The technical surface is now complete: 15 public Actors, 19 public examples and a 15-tool MCP facade. The next question is simpler and harder: do these examples help a new user complete a first useful workflow without assistance?

If you try one, send me the point where you hesitate. That is the part I want to fix.