feat: simplify call-actor tool and add long rung running task support,

[MQ37]

closes #365

This is quite a large PR but core changes are not that huge and it was quite painful—a lot of circular dependencies, and I had to summon Opus to solve that 😆

🔧 Changes 🔧

• Simplified call-actor tool:

  • Removed the step param
  • Added long-running task support
  • Moved the step=info logic to fetch-actor-details tool

• Updated fetch-actor-details tool:

  • Moved the step=info logic here via the output input param (supports granular output)
  • Added mcp-tools, which uses the previous logic from call-actor (connects to MCP server Actors and lists the tools)
  • It is backwards compatible

• Improved workflow evals and added related test cases

• Moved a few functions and consts to solve circular dependencies—it was really painful

✅ Testing ✅

Also tested fetch-actor-details and call-actor manually with OpenCode, and it works well. 🚀

[jirispilka]

I tested it in claude-desktop. It works great!

With the actor-mcp I had more problems but I don't think it was introduced here.
I've tried playwright and tavily, the both failed.

I made two suggestions.

[jirispilka]

Instead of using an array of enums for selecting output fields, a more idiomatic and user-friendly approach in Zod is to use an object with boolean flags. This change simplifies the internal tool logic because you no longer need to check for inclusion in an array using .includes().

const fetchActorDetailsToolArgsSchema = z.object({
    actor: z.string()
        .min(1)
        .describe(`Actor ID or full name in the format "username/name", e.g., "apify/rag-web-browser".`),
    output: z.object({
        description: z.boolean().default(true).describe("Include Actor description text only."),
        stats: z.boolean().default(true).describe("Include usage statistics (users, runs, success rate)."),
        pricing: z.boolean().default(true).describe("Include pricing model and costs."),
....
    })
    .optional()
    .default({
        description: true,
        stats: true,
        pricing: true,
    .....
    })
    .describe("Specify which information to include in the response to save tokens."),
});

Another option is to use the fields as it is standard in rest API. We are using it when fetching dataset and it worked fine.

const fetchActorDetailsToolArgsSchema = z.object({
    actor: z.string()
        .min(1)
        .describe(`Actor ID or full name in the format "username/name", e.g., "apify/rag-web-browser".`),
    fields: z.string()
        .optional()
        .describe(`Comma-separated list of fields to include in the response. 
Available fields: 'description', 'stats', 'pricing', 'rating', 'metadata', 'input-schema', 'readme', 'mcp-tools'.
Default: all fields except 'mcp-tools'.`),
});

AI conclusion :) """ Use fields if you want to match the API convention. Use the Object/Boolean flags if you want the best performance and reliability from the LLM."""

[jirispilka]

This description is super long now :(

[jirispilka]

Here I would do the same logic as below, we return input-schema if the input is incorrect. Let us return input-schema if the input is empty.

I would write it something like ... [fetch-actor-details was called and schema retrieved, "input-schema"]. Just to tell LLM how the schema was retried (but that's not that important)