fix: export internals for apify-mcp-server

[MQ37]

Export internals used in apify-mcp-server repo to prevent importing from dist/.

related to #102

[jirispilka]

I still think it would be better to expose only the ActorsMcpServer class.
Otherwise, it becomes too easy to break something.

Do we really need to export all these functions?
Could we include them as part of the ActorsMcpServer class instead?

[MQ37]

I still think it would be better to expose only the ActorsMcpServer class. Otherwise, it becomes too easy to break something.

Do we really need to export all these functions? Could we include them as part of the ActorsMcpServer class instead?

We can include the actorNameToToolName and parseInputParamsFromUrl functions in the ActorsMcpServer class, however I don't think it makes sense to include tool related "config", like categories, in this class. But I think in a long run we should get rid of this class to make the architecture more scalable and less isolated in the class.

@MichalKalita what do you think?

[MichalKalita]

@MQ37 @jirispilka
The library should export all classes, functions, and constants required to work with this library. (It's not happening now)
On the other hand, lib should respect semver, but it's hard in this case.

Exporting non-stable parts in /internals is a good compromise for me.

I don't know if some other NPM package uses this library as a dependency. https://www.npmjs.com/package/@apify/actors-mcp-server?activeTab=dependents
Almost all users use it to start a local MCP server, not as a dependency in other NPM modules.

TLDR: I'm approving this PR

[MichalKalita]

Fun fact, react uses more dangerous names. https://github.com/facebook/react/blob/edac0dded99d56e7d66a88da83e874761e3e937a/fixtures/fiber-debugger/src/App.js#L10

[jirispilka]

For the record, exporting more tools will just make things harder for us.
Once something is exposed, we shouldn’t change it, or it might break in apify-mcp.

Let's approve it and we will see.

[MQ37]

For the record, exporting more tools will just make things harder for us. Once something is exposed, we shouldn’t change it, or it might break in apify-mcp.

Let's approve it and we will see.

To some degree I agree but since its marked as internal and we are building that for us only and not for the public (I mean the /internals export path) it should be fine to do breaking changes since it is only used in single repo.

Merging 👍