Skip to content

feat(mcp): placeholder for actor-push-source upload tool (F21 bookmark)#1048

Draft
DaveHanns wants to merge 1 commit into
masterfrom
feat-mcp-push-actor-source-placeholder
Draft

feat(mcp): placeholder for actor-push-source upload tool (F21 bookmark)#1048
DaveHanns wants to merge 1 commit into
masterfrom
feat-mcp-push-actor-source-placeholder

Conversation

@DaveHanns

Copy link
Copy Markdown

Summary

Bookmark PR — no behavior change. Adds a single placeholder file src/tools/actor-push-source.ts documenting the intent, the blocker, and the rough shape of the missing MCP upload tool. Zero exports, zero registrations, zero integrations.

Purpose: reserve mental + repo space for the tool while its blocker gets resolved. Merge if you want the bookmark; close if you'd rather track by issue only.

The gap

MCP-only agentic clients today cannot deploy Actor source. mcp__apify__call-actor runs an Actor, mcp__apify__add-actor finds Actors, but nothing wraps what apify push does — upload an already-built local source tree as a new Actor version. In the agentic-actor-dev-eval eval framework, the mcp-only stack consistently fails T2 (push) for this reason (see finding F21).

Related: F38 was originally proposed as "MCP-side template scaffolding" and hits closed issue #1037. After discussion the reframe was:

  • Scaffolding (create a fresh Actor from a template) — client-side concern, served by apify/actor-templates's public manifest + raw GitHub URLs. Not MCP's job.
  • Uploading an already-built Actor — analogous to apify push. Missing from MCP today. This is what F38 collapses into F21 for.

Why placeholder, not implementation

Blocked on apify/apify-core#29044 — a decision-issue for the REST Actor-version deploy contract. Right now there are two competing paths:

  • PUT /v2/acts/{id}/versions/{ver}/source-files (tarball body) — what the docs describe — currently 4xx's regardless of payload.
  • PUT /v2/acts/{id}/versions/{ver} (JSON sourceFiles body) — what actually works — undocumented; apify push uses this internally.

The platform team needs to pick one. Whichever wins, the MCP tool wraps that. Shipping the tool now would either bake in a broken path OR bake in an undocumented-and-could-change path.

What this PR contains

A single new file: src/tools/actor-push-source.ts — ~70 lines of JSDoc, export {}; at the bottom, no other exports. Not imported anywhere. Not registered.

What lands when #29044 unblocks

Roughly (subject to which contract wins):

  • Populate the file with a Zod input schema (actorName, versionNumber (MAJOR.MINOR-validated), sourceFiles[], overwrite, buildTag) and a call() body that wraps the winning REST path.
  • Add HelperTools.ACTOR_PUSH_SOURCE = 'push-actor-source' to src/const.ts.
  • Register in src/default/tools.ts alongside the other write-scope tools.
  • Add integration tests.

Estimated ~2-3 hours of focused work once the blocker resolves.

Cross-refs

🤖 Placeholder generated with Claude Code

This is a BOOKMARK PR. No behavior change, no exports, no tool registration.
Adds a single placeholder file src/tools/actor-push-source.ts documenting
the intent, the blocker, and the rough shape of the upload tool that MCP
is missing today.

Why:
- MCP-only agentic clients today cannot deploy their own Actor source — no
  tool wraps what `apify push` does. That's the fundamental gap of F21 in
  the `apify/agentic-actor-dev-eval` eval framework. The mcp-only stack in
  that eval consistently fails T2 (push) because of this.
- F38 was originally scoped as "MCP template scaffolding" but reframed
  during discussion: MCP is not a scaffolder (that's a client-side or
  CLI-side concern served by `apify/actor-templates`); MCP is an upload
  surface, mirror of `apify push`. F38 rolls up into F21 as the same story.

Why not implementing yet:
- Blocked on `apify/apify-core#29044` — the REST deploy contract decision.
  There are two competing REST paths (documented tarball-body, working
  JSON sourceFiles) and one endpoint. Shipping the MCP tool wrapping either
  path before the decision would either bake in a broken contract or a
  soon-to-be-changed one.

What lands when the decision unblocks:
- Populate the file with a Zod input schema + `call()` body wrapping
  the correct REST path.
- Add `HelperTools.ACTOR_PUSH_SOURCE = 'push-actor-source'` to
  `src/const.ts` enum.
- Register in `src/default/tools.ts` alongside the other write-scope
  tools (ACTOR_CALL, KEY_VALUE_STORE_RECORD_SET, etc.).
- Add integration tests.

For now this file is a documented parking spot so the work doesn't get
lost. Close this PR if you'd rather track via issue only.

Cross-refs (bare, no auto-close keywords):
- apify/apify-core#29044 — REST deploy contract decision (blocker)
- #1037 — closed; the "MCP-side template scaffolding"
  issue that reframed F38 into F21
- Underlying eval findings: F21 + F38 in
  `apify/agentic-actor-dev-eval` FINDINGS.md

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants