ON HOLD feat: skyfire payments

[MQ37]

related to https://github.com/apify/apify-mcp-server-internal/pull/149

This PR prepares the core MCP repo for custom payment agentic key provider.

Backstory

Till now we just received Apify token through Auth header Bearer token or ?token query param. This now changes as we want to implement the Skyfire for agentic payments. So we will be supporting both Apify tokens and also Skyfire payment tokens (PAY) as input.

Main idea

The main ideas is the Apify token logic remains as it is and we will also accept the PAY token through the skyfire-pay-id header or the Auth Bearer auth header (we can recognize Apify token (starts either with apify_api or integration_api for OAuth). We will then pass that to the MCP tools as we did with the Apify token and then forward it to the Apify API server.

Technical details

For this I introduced the AuthToken type so we can clearly mark from which provider (currently only Apify or Skyfire) the token is since we may support multiple providers in future and they may not be easily recognizable by their string value but for example only via the header they come from - this needs to be somehow passed from the HTTP server in this wrapper.

Additional changes

• Removed two unused legacy functions getRealActorID() and getActorDefinition().
• Also added integation tests for the MCP progress notificaiton for the Actor tool calls so we can easily verify they actually work in production.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/apify/apify-mcp-server/@apify/actors-mcp-server@253

commit: eb07cd7

[MichalKalita]

👍

[jirispilka]

Well, the generated summary is nice but IMO completely use-less, srry :).
I would appreciate your thoughts more than AI ones.

What about this approach?

I'm not really a fan of passing around AuthToken everywhere, when, most of the time, we just need actual token string. It's a bit clunky

Instead of the AuthToken object, we'll just use plain strings. The ApifyClient will handle figuring out if it's an Apify token or Skyfire token internally, so tools don't need to worry.

We can expose this function for classification, to be reusable (or we can duplicate it).

Why this is better:
• cleaner API - tools just pass the token string
• classification logic lives where it's actually used
• simpler code

We can also live with the authToken but it seems to be a bit overkill.

Yes, I'm being pedantic because you said it was vibe-coded 😜

[MQ37]

Well, the generated summary is nice but IMO completely use-less, srry :). I would appreciate your thoughts more than AI ones.

What about this approach?

I'm not really a fan of passing around AuthToken everywhere, when, most of the time, we just need actual token string. It's a bit clunky

Instead of the AuthToken object, we'll just use plain strings. The ApifyClient will handle figuring out if it's an Apify token or Skyfire token internally, so tools don't need to worry.

We can expose this function for classification, to be reusable (or we can duplicate it).

Why this is better: • cleaner API - tools just pass the token string • classification logic lives where it's actually used • simpler code

We can also live with the authToken but it seems to be a bit overkill.

Yes, I'm being pedantic because you said it was vibe-coded 😜

Thank you for your hawk-eye review 😄

Makes sense, the generated summary is a bit verbose and sometimes not to the point. Will introduce my own 👍

Regarding the passing token around I understand that it would be simpler but we need to somehow "mark" the token provider on the HTTP server level before it gets to the tools since in future we might not be able to recognize the key just by the string value but for example only from header it comes from (skyfire-pay-id, other-provider-header, ...) and for this use case we need something like the AuthToken with the provider clearly marked. This introduces some burder, but make the logic future proof and as it is already written, so I would keep it as it is 😅 We can do a compromise and make the functions accept both string | AuthToken and if only string is provided it would be considered an Apify token.

[jirispilka]

Well I find this logic a bit flawed .... first, we have this as POC, but at the same time you're making it more complicated to be future-proof.

ok, fair enough, let's go out with that. But then please do not name it authToken since it is an object not authToken.
What about authConfig or authInfo or any better name

[MQ37]

closing in favor of v2 PRs