<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Werkzeuge on Defender TD5</title><link>https://td5.390er.de/kategorien/werkzeuge/</link><description>Recent content in Werkzeuge on Defender TD5</description><generator>Hugo</generator><language>de</language><lastBuildDate>Sat, 01 Aug 2026 09:53:22 +0200</lastBuildDate><atom:link href="https://td5.390er.de/kategorien/werkzeuge/index.xml" rel="self" type="application/rss+xml"/><item><title>Alternative AI Interfaces for AppleBridge: What Else Can Drive the Bridge, and What Changes When It Does</title><link>https://td5.390er.de/applebridge/alternative-ai-interfaces-for-applebridge/</link><pubDate>Sat, 01 Aug 2026 09:51:25 +0200</pubDate><guid>https://td5.390er.de/applebridge/alternative-ai-interfaces-for-applebridge/</guid><description>&lt;p&gt;Every note in this section so far has assumed the same operator: Claude Code, on the host, holding one end of the bridge. That assumption is worth examining, because it is not actually load-bearing. AppleBridge&amp;rsquo;s own README names Claude Code in its first line, and &lt;code&gt;.mcp.json&lt;/code&gt; configures exactly one client — but nothing in &lt;code&gt;mcp/server.py&lt;/code&gt;, &lt;code&gt;host_server.py&lt;/code&gt;, or the 68K daemon knows or cares which client is on the other side of the pipe. The coupling is a convention, not a dependency.&lt;/p&gt;</description></item></channel></rss>