-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: MCP server implementation #1
Conversation
- add ability to load actors in standby mode
* Update docs and update apify-client-js with fixes for Actor definition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! Very cool usage of a Standby Actor. I had a few comments, if you want, we can discuss the Standby architecture tomorrow in the office 🙂
|
||
The Actor runs in [**Standby mode**](https://docs.apify.com/platform/actors/running/standby) with an HTTP web server that receives and processes requests. | ||
|
||
Start server with default Actors. To use the Apify MCP Server with set of default Actors, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit problematic, Actor Standby doesn't have a concept of "starting a server". It just starts an Actor run when it receives the first requests to its Standby URL, the run will run until the idle timeout, and then it's shut down. So with this scenario this could happen:
- user "starts" the Actor with specified Actors through the
?actors=...
parameter - user uses the MCP server on the
/sse
path, everything works - user waits a bit, Actor run started in 1 gets shut down
- user tries to use the MCP server again, but now it's not "started", and the specific Actors are not loaded
Or, if the user uses the MCP server a lot, an additional run is started to handle the requests, and that is not prepared with the specific Actors.
It also doesn't give the user an option how to load different Actors after the run is started.
What would work is one of these two options:
- specify Actors in every request to the
/sse
endpoint - specify Actors in the Standby Actor input, and when users would want to use different Actors in the MCP server, they'd create an Actor task which would override the Actor input, and use the task's standby URL instead of the Actor standby URL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh 💡, this didn't occur to me. Thanks Franto!
specify Actors in every request to the /sse endpoint
This is a bit problematic as it depends on the MCP client (e.g., Claude Desktop, LibreChat). These clients do not pass parameters to the SSE endpoint
specify Actors in the Standby Actor input, and when users would want to use different Actors in the MCP server, they'd create an Actor task which would override the Actor input, and use the task's standby URL instead of the Actor standby URL
This seems to be the easiest and quickest solution.
There is one more option.
- The MCP server can dynamically load Actors. Basically, based on the use case, the MCP will include a tool to search for Actors and "load" them (i.e., add them as a tool). I've already experimented with this in the [feat/internal-tools]() branch. It "works", but I encountered some issues and haven’t had much time to fix them yet.
src/actorDefinition.ts
Outdated
// Extract default build label | ||
const tag = actor.defaultRunOptions?.build || ''; | ||
const buildId = actor.taggedBuilds?.[tag]?.buildId || ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default build is not necessarily tagged, you can specify any build number as default build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, let's discuss this tomorrow
src/examples/clientStdio.ts
Outdated
dotenv.config({ path: '../../.env' }); | ||
|
||
const SERVER_PATH = '../../dist/index.js'; | ||
const NODE_PATH = execSync('which node').toString().trim(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this work on Windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, I was too lazy. I'll fix it
Co-authored-by: František Nesveda <[email protected]>
Co-authored-by: František Nesveda <[email protected]>
Co-authored-by: František Nesveda <[email protected]>
Co-authored-by: František Nesveda <[email protected]>
Co-authored-by: František Nesveda <[email protected]>
Also limit number of Actors used to avoid rate limiting.
Major changes since the last review:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! Two small suggestions, but nothing major.
Co-authored-by: František Nesveda <[email protected]>
Future work
FYI: @vystrcild @MQ37