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

Declarative tool-manifest for JS-callable tools: shape proposal, with production reference

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

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

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

評価

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

調査の方向性

Start with the repo’s Alternatives Considered #2 and the input-schema-synthesis work in #210, then compare the proposed JSON block with the production reference’s current ai-actions and input_schema spellings. The issue asks whether and where to explore a shared declarative shape; done would mean an agreed direction on venue and conventions, which requires discussion and design rather than a bounded code change.

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

説明

Context

The repo's Alternatives Considered #2 (Static Declarative Manifests) defers static declarations as "layered on in the future," on the correct observation that a manifest cannot contain executable code and so cannot replace imperative registration. The declarative API for <form> elements (see the input-schema-synthesis work in #210) addresses one subset of what a declarative counterpart could cover.

This issue proposes a declarative shape for the JS-callable subset — tools whose execution is a JavaScript function rather than a form submission — that would complement the imperative registerTool surface and the form-based declarative API already in flight. It is not a replacement for either.

Proposed shape

A <script type="application/json"> block in the page containing an array of MCP Tool objects, where each entry carries name, description, and inputSchema reused verbatim from MCP's wire type. A reader-side convention binds the tool name to the executing JavaScript function. One example in the shape under discussion:

<script type="application/json" id="ai-tools">
[
  { "name": "add_dictionaries",
    "description": "Add the named dictionaries to the current selection.",
    "inputSchema": {
      "type": "object",
      "properties": { "names": { "type": "array", "items": { "type": "string" } } },
      "required": ["names"]
    } }
]
</script>

Deliberately conservative:

  • MCP's Tool type reused verbatim. The same shape every MCP consumer already recognises, including WebMCP's own registerTool arguments — no new type to design, nothing to adopt beyond what the ecosystem already has.
  • Shape only. Dispatch binding (how a reader finds the JavaScript function to invoke) is left to each reader — WebMCP agents could call registerTool with the parsed entry; a widget could call its own dispatch table. This mirrors how the forms-based declarative API leaves execute behaviour to the user agent after schema synthesis.
  • No new lifecycle, state-conveyance, or permissions model. Only the schema part that registerTool already takes.

The reference implementation (see 'Reference implementation' below) currently uses the DOM id ai-actions and the snake_case field name input_schema as legacy spellings; the proposal above uses ai-tools and inputSchema to align with MCP's Tool type and WebMCP's registerTool surface, and the widget would migrate to the aligned spellings on standardisation.

Reference implementation

llm_meta_widget (npm @aibranch/llm-meta-widget, also a Ruby gem on RubyGems) reads this shape in production and dispatches declared tool-calls to a page-provided JavaScript function. Running live at https://pubdictionaries.org/text_annotation — view the page source to see the current shape in use, or interact with the chat widget directly. A related MCP Specification Enhancement Proposal, static-primitives, covers the backend-side analogue (pre-connection advertisement of a server's primitives via a Server Card extension).

Compatibility across the WebMCP adoption window

The pre-WebMCP window — Origin-Trial support in Chromium today, broader cross-browser adoption longer — is a period where host sites that want in-page LLM tool integration need a shape that works in every current browser. A declarative JSON-block manifest serves that need now: the widget reads it in any browser with ES-module support, without a WebMCP implementation present. If WebMCP later specifies a reader for the same block, the page's declaration continues working for both widget-style assistants and WebMCP-capable browser agents from a single source, without re-authoring.

The widget-style reader is the shipping path during the pre-WebMCP window; a shared shape avoids the authoring churn when WebMCP ships broadly.

Discussion

Would there be interest in exploring a shared declarative shape for JS-callable tools, as a complement to the forms-based declarative API in #210? Open on venue: this repo as the natural home, the Web Machine Learning CG, the Model Context Protocol SEP track, or combined. Happy to iterate on the shape, the DOM-placement convention, or any aspect of the proposal.

主要言語
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

Backend & API Design の issue をもっと見る

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

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