Context
Devframe exposes agent actions as MCP tools through ctx.agent.registerTool and agent-enabled RPC functions.
Some development actions can take long enough that a regular silent tools/call is not a good experience. MCP defines two complementary mechanisms for these operations:
- Progress reports updates while the original request remains open.
- The official Tasks extension lets long-running work continue asynchronously through a durable task handle.
Progress fits operations that remain within one request. Tasks fit work that may outlive the request or connection, require polling or cancellation, or pause for additional input.
Where this would help
A build or test tool may take 30–60 seconds. Progress would let the client show stages such as dependency analysis, compilation, and test execution instead of leaving the agent with a silent pending call.
A full workspace build, codebase indexing operation, profiling session, or large test suite may take several minutes. Returning a task would let the agent start the work, continue with something else, reconnect if needed, poll its status, cancel it, and retrieve the final result later.
Tasks would also help workflows that pause for input or approval before continuing.
Question for maintainers
Should Devframe support MCP progress and the Tasks extension for long-running agent tools?
This would extend the agent-native surface in the same spirit as the resource lifecycle work in #292, while following the standard MCP protocols rather than introducing Devframe-specific conventions.
If this direction fits the project, I would be happy to work on the implementation in a follow-up PR.
Context
Devframe exposes agent actions as MCP tools through
ctx.agent.registerTooland agent-enabled RPC functions.Some development actions can take long enough that a regular silent
tools/callis not a good experience. MCP defines two complementary mechanisms for these operations:Progress fits operations that remain within one request. Tasks fit work that may outlive the request or connection, require polling or cancellation, or pause for additional input.
Where this would help
A build or test tool may take 30–60 seconds. Progress would let the client show stages such as dependency analysis, compilation, and test execution instead of leaving the agent with a silent pending call.
A full workspace build, codebase indexing operation, profiling session, or large test suite may take several minutes. Returning a task would let the agent start the work, continue with something else, reconnect if needed, poll its status, cancel it, and retrieve the final result later.
Tasks would also help workflows that pause for input or approval before continuing.
Question for maintainers
Should Devframe support MCP progress and the Tasks extension for long-running agent tools?
This would extend the agent-native surface in the same spirit as the resource lifecycle work in #292, while following the standard MCP protocols rather than introducing Devframe-specific conventions.
If this direction fits the project, I would be happy to work on the implementation in a follow-up PR.