diff options
| author | tanaka takashi <isazaka@gmail.com> | 2026-09-13 14:12:41 +0900 |
|---|---|---|
| committer | tanaka takashi <isazaka@gmail.com> | 2026-09-13 14:13:04 +0900 |
| commit | 97b34627667fd699f4e0e054533eb89a205a2878 (patch) | |
| tree | 1d4549d56b7c53be9ecb583db9bb1a5593e54126 /README.md | |
| parent | 3b5bd2f8fd15bcc13542ff5ffd3c35453af9a9df (diff) | |
feat: return composed WAV as MCP audio content
Replace the server-local wav_path result with a protocol-native multimedia response.
- Split internal composition execution from MCP ToolResult serialization so filesystem paths never enter public payloads.
- Return every successfully composed WAV as AudioContent with the audio/wav MIME type, regardless of file size.
- Keep structured audio metadata, duration, note sequence, and validation details alongside the multimedia content.
- Use CallToolResult.isError as the authoritative MCP execution status while retaining compose success and validate valid as domain fields.
- Treat invalid compose/API requests and runtime failures as tool errors, while invalid MML discovered by validate remains a successful validation operation.
- Sanitize synthesis, file-write, audio-serialization, and unexpected failure responses so internal paths and exception details are not exposed.
- Add protocol-level coverage for base64 round trips, content block types, error semantics, ResourceLink absence, and path non-disclosure.
- Update existing tests for the separated execution layer and path-free result contract.
- Document AudioContent and isError behavior in the README, MCP schema, and design specification.
- Require the tested FastMCP 3.4.4 API line and exclude the incompatible 4.x major version.
Verification: 487 tests passed; ruff check passed; git diff --check passed; uv lock --check passed; and a manual MCP call returned TextContent plus AudioContent with no wav_path.
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 6 |
1 files changed, 4 insertions, 2 deletions
@@ -159,9 +159,11 @@ MCPクライアントでは、たとえば次のように依頼できます。 } ``` -成功時は`success: true`、`wav_path`、`duration_sec`、解析済みの`note_sequence`を返します。指定した出力ディレクトリの下に生成時刻を表す`YYYYMMDD_HHMMSS_mmm`ディレクトリを作り、`output.wav`と、合成に使用したMML原文の`output.mml`を保存します。 +成功時は、MCPレスポンスの`content`に`audio/wav`の`AudioContent`を返します。WAVデータはbase64エンコードされ、ファイルサイズにかかわらず同じ形式で返されます。`structuredContent`には`success: true`、`duration_sec`、音声メタデータ、解析済みの`note_sequence`、検証結果が入ります。 -`wav_path`はMCPサーバが動作しているマシン上のローカルパスです。リモートのHTTPサーバとして運用する場合、このツール自体はWAVのダウンロード配信を行いません。 +指定した出力ディレクトリの下には、従来どおり生成時刻を表す`YYYYMMDD_HHMMSS_mmm`ディレクトリを作り、`output.wav`と合成に使用したMML原文の`output.mml`を保存します。この保存先はサーバ内部の情報であり、MCPレスポンスにはファイルパスを含めません。 + +MCPツールとしての成否は`isError`で判定します。compose、引数、actionなどのエラーは`isError: true`、正常に完了したvalidateは対象MMLが不正でも`isError: false`です。composeの`success`とvalidateの`valid`は、それぞれの処理結果を表す構造化フィールドです。 ## MMLの書き方 |
