<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MCP</title><link>https://blog.ast.moe/en/tags/mcp/</link><description>Recent posts: Gorimuchu</description><generator>Hugo</generator><item><title>Integrating Jev into Izanagi’s behavioral analysis</title><link>https://blog.ast.moe/en/blog/2026-10-09/</link><pubDate>Fri, 09 Oct 2026 10:03:32 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-10-09/</guid><description>&lt;p&gt;In the previous article (&lt;a href="https://blog.ast.moe/en/blog/2026-10-08-3/"&gt;source&lt;/a&gt;), we introduced Izanagi, which isolates and runs development commands while recording file accesses and network communications. This time, we discuss the addition of behavior analysis using Jev.&lt;/p&gt;
&lt;p&gt;Existing detection rules issue warnings based on a single action—such as an attempt to open a secret file, a connection to an address outside the allowed list, or the execution of an unexpected command. In addition, we have made it possible to link multiple actions together in chronological order.&lt;/p&gt;</description></item><item><title>What can be done with Izanagi</title><link>https://blog.ast.moe/en/blog/2026-10-08-3/</link><pubDate>Thu, 08 Oct 2026 22:24:12 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-10-08-3/</guid><description>&lt;p&gt;When you run &lt;code&gt;npm install&lt;/code&gt;, it not only downloads the package but may also execute scripts that the package provides. If you run that code in your regular development environment, you can access files readable by the executing user and the environment variables passed to the process.&lt;/p&gt;
&lt;p&gt;To isolate such development commands and track what they access, we have built Izanagi in Rust (&lt;a href="https://github.com/ieee0824/izanagi"&gt;source&lt;/a&gt;). It records file accesses, network communications, and child‑process launches so you can examine the behavior of the executed code.&lt;/p&gt;</description></item><item><title>Added evaluation JSONL and production‑ready features to Jev MCP.</title><link>https://blog.ast.moe/en/blog/2026-09-21/</link><pubDate>Mon, 21 Sep 2026 15:55:00 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-21/</guid><description>&lt;p&gt;I updated the
&lt;span&gt;
&lt;a target="_blank" href="https://github.com/ieee0824/jev-mcp"&gt;
jev-mcp
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
.&lt;/p&gt;
&lt;p&gt;In the previous post, I wrote that we had created an MCP server that invokes Jev, TypeSafe AI’s decision model, from Codex. Simply connecting the four decision tools doesn’t tell us whether they can be reliably used in actual coding work.&lt;/p&gt;
&lt;p&gt;This time, we added a small JSONL file for evaluating the decision results, an evaluation CLI, telemetry for monitoring invocation status, and handling for failures. We have also expanded the Codex‑specific Skill with additional decision recipes tailored to different use cases.&lt;/p&gt;</description></item><item><title>I created an MCP server that extracts Codex’s decisions for Jev.</title><link>https://blog.ast.moe/en/blog/2026-09-20-2/</link><pubDate>Sun, 20 Sep 2026 18:29:44 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-20-2/</guid><description>&lt;p&gt;I created an MCP server called
&lt;span&gt;
&lt;a target="_blank" href="https://github.com/ieee0824/jev-mcp"&gt;
jev-mcp
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
.&lt;/p&gt;
&lt;p&gt;It is intended to be invoked during Codex work to call the TypeSafe AI decision model Jev. Implemented in Rust, it communicates with Codex via standard input/output.&lt;/p&gt;
&lt;span&gt;
&lt;a target="_blank" href="https://docs.typesafe.ai/introduction"&gt;
Jev, TypeSafe AI’s decision model
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
&lt;p&gt;Instead of handing the entire coding task over to another agent, I want to extract the small decisions that arise during the investigation.&lt;/p&gt;
&lt;p&gt;For example, questions like “Is this file related to the current bug?” or “Which subsystem should be examined next?” While Codex continues the investigation, editing, and testing, we use Jev for the intermediate classification and evaluation.&lt;/p&gt;</description></item><item><title>Development notes for Cubase MCP. I'm having trouble with the preliminary research before retrieving the track list.</title><link>https://blog.ast.moe/en/blog/2026-09-19-2/</link><pubDate>Sat, 19 Sep 2026 20:28:17 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-09-19-2/</guid><description>&lt;p&gt;Previously, I wrote an article titled “Building a Server to Control Cubase via MCP” (&lt;a href="https://blog.ast.moe/en/blog/2026-08-16/"&gt;source&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;Since then, I’ve continued developing
&lt;span&gt;
&lt;a target="_blank" href="https://github.com/ieee0824/cubase_mcp"&gt;
cubase_mcp
&lt;/a&gt;
&lt;img class="external-link-icon" src="https://blog.ast.moe/images/outer-link.png" width="12" height="12" alt="" aria-hidden="true" loading="lazy"&gt;
&lt;/span&gt;
, but it hasn’t progressed as much as I had hoped.&lt;/p&gt;
&lt;p&gt;I’ve now managed to handle play/stop and retrieve transport status, so the next step is to obtain a list of the project’s tracks.&lt;/p&gt;
&lt;p&gt;If we can retrieve information such as the track name, selection state, mute, and solo status, we could expand what’s possible from MCP. That was the premise, but now I’m still investigating what exactly can be retrieved and how far.&lt;/p&gt;</description></item><item><title>I built a server that controls Cubase via MCP.</title><link>https://blog.ast.moe/en/blog/2026-08-16/</link><pubDate>Sun, 16 Aug 2026 08:05:11 +0900</pubDate><guid>https://blog.ast.moe/en/blog/2026-08-16/</guid><description>&lt;p&gt;I thought it would be interesting to control Cubase via MCP, so I created the &lt;a href="https://github.com/ieee0824/cubase_mcp"&gt;Cubase MCP&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;By sending commands such as “play,” “stop,” or “report the current status” from an MCP client, you can operate Cubase’s transport controls and retrieve its state.&lt;/p&gt;
&lt;p&gt;It’s not yet possible to control every aspect of Cubase. This time, I first built a small implementation that simply connects MCP to Cubase.&lt;/p&gt;
&lt;h2 id="what-was-created"&gt;What was created&lt;/h2&gt;
&lt;p&gt;The implementation is an integration daemon written in Rust.&lt;/p&gt;</description></item></channel></rss>