Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

WebMCP tool execution progress report

オープン
  • 何か問題がありますか？
#196 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
28/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
javascript
領域
ai, api

調査の方向性

Start with the linked Chromium change, the extension inspector PR, and the current ToolExecuteCallback and document.modelContext definitions. Compare the proposed event-target API with the alternative ExecuteToolOptions.monitor, especially how concurrent executions receive identifiers. Done means selecting and specifying one API shape, including progress-event fields and execution-ID behavior, then updating the WebMCP specification and examples consistently.

索引モデルが issue の本文から書いたものです。

説明

enhancement

Introduction & Objectives

As Language Models and Agentic workflows become deeply integrated into the web platform via WebMCP, some tools registered by web applications may be tasked with long-running operations (e.g., repository indexing, complex multi-file analyses). Currently, the ToolExecuteCallback interface executes asynchronously but behaves as a "black box" until the final promise resolves or rejects. There is no native mechanism for an active tool execution to stream intermediate telemetry, status messages, or sub-task heartbeats back to the calling agent, which leaves both the agent and the user without visibility into the tool's current state.

Better agent to agent integrations

A common agentic pattern is to expose sub-agents to a coordinator as tools. This pattern also enables websites to expose their own agents to browser agents. Similar to other tasks described in this document, invoking a sub-agent can be a long running process. The progress report feature would enable sub-agents to send progress updates: thinking blocks, partial texts, and details on their own tool calls to the browser agent, so it can display their content to the user.

[!NOTE]
While it’s up to the agent to decide how to use the progress reports it receives, the goal is to use the information to show progress of the tool call to the user, and the content of those reports should not be included in the conversation between agents, to avoid context bloat.

Proposed API changes

partial interface ModelContextClient {
    undefined reportProgress(DOMString message);
};

interface ToolProgressEvent : Event {
    constructor(DOMString type, optional ToolProgressEventInit eventInitDict = {});
    readonly attribute DOMString toolName;
    readonly attribute DOMString message;
};

dictionary ToolProgressEventInit : EventInit {
    DOMString toolName = "";
    DOMString message = "";
};

partial interface ModelContext : EventTarget {
    attribute EventHandler ontoolprogress;
};

JavaScript example

// 1. Tool Implementation with Progress Updates
async function* runTasks() {
  yield { type: 'thinking', text: 'Analyzing your workspace...' };
  await new Promise((r) => setTimeout(r, 800));

  yield { type: 'tool_start', name: 'hackathon-analyzer', params: { file: 'reasons.md' } };
  await new Promise((r) => setTimeout(r, 1200));

  yield { type: 'tool_finish', name: 'hackathon-analyzer' };
  await new Promise((r) => setTimeout(r, 500));

  yield { type: 'text', text: 'Analysis complete! Found 3 migration reasons.' };
}

// 2. Registering the Tool with the injected client
document.modelContext.registerTool({
  name: 'workspace-analyzer',
  description: 'Analyzes files in the current workspace directory',
  execute: async (input, client) => {
    for await (const message of runTasks()) {
      // Serialize updates to string data
      client.reportProgress(JSON.stringify(message));
    }
    return { success: true };
  },
});

// 3. Orchestrator observing runtime progress hooks
document.modelContext.ontoolprogress = (event) => {
  const { toolName, message } = event;
  const data = JSON.parse(message);
  
  console.log(`[Progress Update] Tool: ${toolName}`, data);
};

Resources

Open questions

A key challenge remains: determining how an extension can effectively track concurrent tool executions. Tool execution IDs are currently unavailable until executeTool() completes, which complicates parallel monitoring. Shall we introduce a new monitor object in ExecuteToolOptions instead of document.modelContext.ontoolprogress to report progress?

const result = await document.modelContext.executeTool(myTool, {
  monitor(m) {
    m.addEventListener('progress', ({ message }) => {
      // Report progress to the extension sidebar
      chrome.runtime.sendMessage({
        toolExecutionId: m.toolExecutionId,
        toolName: m.toolName,
        message,
      });
    });
  },
});
// Report final result from tool execution.
chrome.runtime.sendMessage({ result });
主要言語
Bikeshed
スター
4.7k
フォーク
328
平均マージ
2日 15時間
マージ済み PR（30日）
16

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

webmachinelearning/webmcp のほかの issue

webmachinelearning/webmcp の issue をすべて見る

似ている issue

AI Infra & Agents の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。