あなたのAIコーディングエージェントに、あなたの XAFアプリケーションが実際に何をするかを教えてください。
XAFモジュールを指定します。エンティティ、コントローラー、アクション、ビジネスルール、ナビゲーション、Model Editorのカスタマイズをソースから直接読み取り、その結果をあなたがコードを書く任意のエージェントに渡します。
DevExpressは、AIエージェントがXAFに精通するようにする優れた作業を行ってきました。すでに2つのツールが存在し、これが3つ目です。
エージェントに教えること… | ツール |
XAFがどのように機能するか全般 | |
公式ドキュメントの内容 | |
あなたのアプリケーションの動作 | XAF Logic Explainer ← ここにいます |
XAFドキュメントのすべてのページを読んだエージェントでも、あなたのInvoiceの合計が明細行から計算されること、ApproveControllerが期間が閉じているときに実行を拒否すること、またはModel Editorで3つの列が非表示にされていてどのC#ファイルにも現れないことを知りません。エージェントはこれら3つすべてを自信を持って捏造します。
そのギャップは、より良いプロンプトでは解決できません。抽出によって解決可能です。
これらのツールは組み合わせて使用します。 フレームワークの知識にはDevExpressのスキルをインストールし、公式リファレンスにはDocs MCPを使用し、独自のコードベースにはこれを使用します。どれも他のものを置き換えるものではありません。
Related MCP server: mcp-digger
以下はすべて、Roslynを使用して構文として読み取られます。プロジェクトをコンパイルする必要はなく、このツールはDevExpressアセンブリにリンクすることはありません。
エンティティ — プロパティ、型、関連付け、およびそれらに意味を与えるXAF属性（[Association]、[Aggregated]、[RuleRequiredField]、[Appearance]、[ModelDefault]、…）。XPOおよびEF Core、usingステートメントから自動検出されます。
コントローラーとアクション — SimpleAction、PopupWindowShowAction、SingleChoiceAction、それらのターゲット条件、および実行時に起動するハンドラコード。
ビジネスルール — 検証属性とコードルール、およびそれらに付随する条件。
モジュールセットアップ — ModuleUpdaterのシードデータと初回実行時に作成されるもの。
ナビゲーション — ユーザーが実際に表示するグループとアイテム。
Model Editor（.xafml） — XMLのみに存在し、C#を読む人には見えないカスタマイズ。モジュールファイルとプラットフォームファイルは、XAFがマージする方法でマージされます。
カスタムプロパティエディターとリストエディター — 動作に不可欠なJavaScript、および実行時にView.CustomizeViewItemControl<T>()を通じて再設定されるビルトインエディターを含みます。これらはモジュールの横にあるプラットフォームプロジェクトに存在するため、ビジネスオブジェクトを読む人は誰もそれらに遭遇しません。
バージョンゲート付きマイグレーション — アップデータ内のCurrentDBVersion < new Version(…)ブロック。各ブロックはデータベースごとに最大1回実行され、現在のコードでは説明できないデータの唯一の説明です。
すべての画面と、それに読み込まれるもの — 以下を参照。
これらが、すべてのビジネスクラスを読んだエージェントがそれでもアプリケーションについて自信を持って間違う理由です。
XAFリポジトリ内の何もそれに答えません。そして、両方の半分が異なる理由で欠落しています。
画面自体はどのファイルにもありません。 XAFはすべてのビジネスクラスに対してリストビュー、詳細ビュー、ルックアップビューを生成し、さらにすべてのコレクションに対してリストビューを生成します。Model Editorは誰かが変更したものだけを保存します。ソース内でPatient_Prescriptions_ListViewをgrepしても何も見つかりません。それは欠落している証拠ではありません。
どのコントローラーがそこで実行されるかは実行時に決定されます。XAFがAND条件で結合する4つの条件（ネスト、ビュータイプ、オブジェクトタイプ、ビューID）によって決まります。各条件は設定されていない場合は無制限であるため、どれも設定しないコントローラーは、あなたの持つすべての画面に読み込まれます。
これは、ViewController.IsFitToViewがそれらを評価する方法で4つすべてを読み取り、フレームワーク自身のIDジェネレーターから構築されたビューインベントリと照合し、各一致の理由を記録するため、答えを信頼するのではなく確認できます。
2つの層は分離されています。チームが書いたものは完全な処理を受けます。XAFが提供するものは1行の背後に折りたたまれています。なぜなら、それは大量にあり、変更するものではないからです。グラウンドトゥルースカタログを使用すると、名前も付けられます — 実際に登録するモジュールにスコープが限定されるため、WinFormsコントローラーがBlazor画面に表示されることはありません。
主張しないこと：ここにリストされているコントローラーは、データとユーザーに依存するActive["reason"]を通じて自身をオフにすることができます。これはXAFが画面に読み込むものであり、必ず何かをするものではありません。ソースから読み取れなかったものは、理由とともに別途リストされ、静かに「どこでも実行される」として扱われることはありません。
dotnet tool install -g XafLogicExplainer.Cli
xaflogic agents --project "C:\MySolution\MyApp.Module"これにより、ソリューションルートにAGENTS.md、CLAUDE.md、.github/copilot-instructions.mdが書き込まれます。アカウントもAPIキーもサーバーも不要です。エージェントは次の質問でアプリケーションを理解します。
AGENTS.mdは、エージェントがリポジトリで行うすべてのリクエストの前に追加されるため、そのコストは永久に支払われます。そこに70KBのエンティティ詳細をダンプすると、実際の質問が押しのけられます。そのため、出力は階層化されています。
| ~11 KB | 常に読み込まれる：基本ルール、完全なインベントリ、規約、レシピ |
| ~70 KB | オンデマンドで開かれる：完全なプロパティ、ハンドラコード、ルールメッセージ、 |
最も価値のある部分は最小です。AGENTS.mdは基本ルールで始まります — このアプリケーションはXPOを使用し、EF Coreは使用しないこと、インベントリは完全であるため、存在しないものは本当に存在しないこと、一部の動作はC#ではなくModel Editorに存在すること。これらの数段落で、エージェントが不慣れなXAFコードベースについて生成する自信に満ちた捏造のほとんどを防ぎます。
既存のファイルは決して上書きされません。生成されたテキストはマーカーの間に存在し、手書きで書いたものは保持され、再生成は何も変更されていない場合にバイト単位で同一です。
生成されたファイルはスナップショットです。MCPサーバーはライブ接続であり、エージェントは作業中にアプリケーションにクエリを実行し、古くなることはありません。
/plugin marketplace add peopleworks/XAFLogicExplainer
/plugin install xaf-logic-explainer@peopleworks-xafこれにより、スキルとMCPサーバーが1ステップでインストールされます。他のMCPクライアントの場合は、インストールなしでNuGetから直接実行するか、
{
"mcpServers": {
"xaf": { "command": "dnx", "args": ["XafLogicExplainer.Mcp", "--yes"] }
}
}…またはすでに持っているCLIを指定します：
{ "mcpServers": { "xaf": { "command": "xaflogic", "args": ["mcp"] } } }ソリューションディレクトリから起動すると、XAFモジュールを自動的に見つけるため、どちらの形式でもパスは必要ありません。
ツール | 回答内容 |
| このアプリケーションの概要と、その中にあるすべての完全なリスト |
| フィールド、概念、ビジネス用語が定義されている場所 |
| 1つのエンティティに関するすべてのプロパティ、リレーションシップ、ルール、計算 |
| アクションが何を行うか — 発火時に実行されるC#コードを含む |
| アプリケーションが検証、計算、非表示、無効化するもの |
| モデルエディタのカスタマイズ（C#ファイルには存在しないもの） |
| カスタムエディタ、それらが必要とするJavaScript、および実行時に変更される組み込みエディタ |
| 実稼働データベースに対して一度だけ実行されたものと、その理由を説明するコメント |
| 1つの画面にロードされるすべて — どのコントローラーがアクティブになるか、その理由 |
| ソースを再読み込み（変更は自動検出されます） |
存在しないものを尋ねると、その回答が役立ちます：
このアプリケーションには「PurchaseOrder」というエンティティは存在しません。 以下は、ソースツリー全体から抽出された19個のエンティティの完全なリストです：… ユーザーが「PurchaseOrder」の存在を期待している場合、それはまだ作成されていません。
公式のDevExpressスキルと組み合わせて使用します。 /plugin install dx-xaf@DevExpress-agent-skills
はXAFの仕組みを教えます。こちらはアプリケーションが何を行うかを教えます。最初のスキルだけを持つエージェントは、存在しないエンティティに対して正しいXAFコードを書いてしまいます。
エージェントはAGENTS.mdを読むか、MCPサーバーにクエリを送信します。10年前のXAFアプリケーションを引き継いだばかりの人は、まったく異なる形で整理された同じ事実を必要とします：
xaflogic explain --project "C:\MySolution\MyApp.Module" --open1つのHTMLファイル。サーバー不要、ビルド不要、ネットワークリクエスト不要 — インターネットのないマシン上のメール添付ファイルから開きます。これが実際の引き継ぎの方法です。
これは、コードベース全体に散らばったアソシエーション属性からドメインモデルのマップを描画します。ほとんどのチームは自分のドメインモデルを見たことがありません。それは一人の頭の中に存在し、その人が去るときに失われる知識そのものです。
実際の出力。このリポジトリのサンプルアプリケーションから。エンティティにホバーすると、それに触れていないすべてがフェードアウト。紫色は親を削除すると子も削除されることを意味します。
それに加えて：すべてのエンティティと各プロパティの内容、実行されるコードを含むすべてのアクション、ユーザーが実際に目にするメッセージを含む検証、およびC#ファイルには現れないモデルエディタの設定。
そしてアプリケーション内のすべての条件式のインデックス — SQLでもC#でもない方言で、ソース全体に散らばった属性から収集され、他ではどこにも集められていません：
自分のコードに触れずにサンプルで試す：
xaflogic explain --project tests/XafLogicExplainer.Tests/Fixtures/DemoSolution/PharmacyDemo.Module --open抽出は、対象のフレームワークについて何も知らずにソースを読み取ります。そのため、1つの疑問が未解決のまま残ります：DeleteObjectsViewControllerはチームが書いたものか、それともDevExpressが出荷しているものか？答えがなければ、生成されたドキュメントはフレームワークの動作と独自のロジックを同じものとして提示します。
DevExpressライセンスをお持ちの場合：
xaflogic catalog buildこれにより、自身のインストールを読み取り、XAF自体が提供するもの（属性、コントローラー、モデルインターフェース、モジュール）を、DevExpressが出荷する公式の概要とドキュメントリンクとともに記録します。DevExpress 26.1では、約850のフレームワークタイプがあります。
さらにDevExpressのソースコードコンポーネントもインストールしている場合、各フレームワークコントローラーがどこでアクティブになるか — XAFが実行前にチェックする4つの条件 — を記録します。これはアセンブリからは読み取れません。組み込みコントローラーの5分の4は、コンストラクター内でターゲットを設定します。ソースがアセンブリの隣にない場合は、--dx-sources <Components/Sources>を渡してください。
その後、抽出は自動的にそれを取得し、そうでなければ言えないことを言えるようになります：
「ArchiveControllerは組み込みのDeleteObjectsViewControllerを拡張しています」 — これは、アプリケーション全体で削除の動作を変更しているのであって、その横に機能を追加しているわけではありません。
「[AuditedByFinance]はXAFや.NETの属性ではありません」 — チームが発明したものであり、その意味はこのコードベースにのみ存在し、どのドキュメントにもありません。
「この画面にはさらに32のフレームワークコントローラーがロードされます」 — 名前付きで、それぞれの機能と、アプリケーションが実際に登録するモジュールにスコープされているため、WinFormsコントローラーがBlazor画面に表示されることはありません。
カタログは~/.xaflogic/catalog/に書き込まれ、決してリポジトリには書き込まれません。これはライセンスソフトウェアから派生したものです。カタログがなくてもすべて動作します — 出力をより鮮明にするだけです。NOTICE.mdを参照してください。
コマンド | 機能 |
| エージェント用の |
| MCPサーバーとして実行し、エージェントがアプリケーションをライブでクエリできるようにします |
| アプリケーションを人間に説明する自己完結型HTMLページを書き込みます |
| DevExpressのグラウンドトゥルースカタログを構築します（ |
| プロジェクトを読み取り、Markdown + JSONをローカルに書き込みます |
| 前回の抽出と比較し、変更点を報告します |
| 変更検出ハッシュを表示し、再抽出が必要かどうかを示します |
| ファイル変更時に再抽出（デバウンス付き） |
| 抽出してリモートターゲットに公開します |
| 抽出されたプロジェクトについて質問します |
|
|
| 複数のXAFプロジェクトを管理します。ほとんどのコマンドは |
ドキュメントは英語またはスペイン語で生成されます（--lang en|es）。
便利なフラグ：--orm auto|xpo|efcore、--lang en|es、--enrich（コントローラーとアクションごとにAI生成のビジネスロジックサマリー）、--force、--all。
--enrichにはモデルが必要で、以下のいずれかで十分です — コマンドラインのキーが優先され、次に環境変数、最後にPeopleWorks Copilotアカウント（お持ちの場合）：
xaflogic extract --enrich --api-key sk-... # or any OpenAI-compatible endpoint:
xaflogic extract --enrich --api-key ... --ai-base-url http://localhost:11434/v1 --ai-model qwen2.5-coder
export OPENAI_API_KEY=sk-... # picked up with no configuration at all
export ANTHROPIC_API_KEY=sk-ant-...このツールの他のすべては、キー、アカウント、ネットワークなしで動作します。
抽出はインクリメンタルです — .csおよび.xafmlファイルに対するSHA-256により、変更のないプロジェクトは何も行いません。ビルド時に実行したい場合のMSBuild .targetsファイルもあります。
v0.14.0。 抽出エンジンは成熟した部分です。実際のXAFアプリケーションに対して本番環境で動作しています。エージェント向けのインターフェースは現在、公開で導入されている部分です。
✅ | Roslyn抽出 — エンティティ、コントローラー、ルール、アップデータ、ナビゲーション、 |
✅ | XPOおよびEF Core、自動検出 |
✅ | カスタムプロパティエディタとリストエディタ、そのクライアントアセット、および実行時に再構成された組み込みエディタ |
✅ | バージョンゲートされたデータマイグレーション — 新しいデータベースでなかったものに何が起こったか |
✅ | インクリメンタル変更検出、差分レポート、マルチプロジェクト、ウォッチモード |
✅ | コントローラーとアクションのAIエンリッチメント（ |
✅ | Blazorアプリ内ヘルプパネル |
✅ |
|
✅ |
|
✅ | プラグイン可能な公開ターゲット（ |
✅ | MCPサーバー — 10のツール、ソースに対してライブで動作 |
✅ | インストール可能なClaude Codeプラグイン（スキルとMCPサーバー付き） |
✅ | 345のテスト（合成XPOおよびEF Coreフィクスチャ上） — DevExpress不要 |
✅ | DevExpressグラウンドトゥルースカタログ、ライセンシーがローカルで生成可能 |
PeopleWorks Copilot（このツールが育った場所）は、今ではすべてが中心に構築されていた宛先ではなく、複数のシンクの1つです。最も重要な出力にはサーバーがまったく必要ありません。
XAFアプリケーションの動作の3分の1がビジネスクラスの外に存在する理由、それが隠れる4つの場所、そして抽出された出力が実際にどのように見えるか：
それぞれが他から翻訳されるのではなく、それぞれの言語で書かれています。ソースはdocs/Blog/にあります。
src/
XafLogicExplainer.Core Roslyn extraction engine — no DevExpress reference
XafLogicExplainer.Mcp MCP server (ModelContextProtocol 2.1)
XafLogicExplainer.Cli the `xaflogic` command
XafLogicExplainer.CopilotSync PeopleWorks Copilot target + AI enrichment
XafLogicExplainer.DescriptionAnnotator generates missing [Description] attributes
XafLogicExplainer.Blazor in-app help panel for XAF Blazor apps
plugins/
xaf-logic-explainer the installable Claude Code plugin.NET 10上に構築されています。
XafLogicExplainer.BlazorのみがDevExpressパッケージを参照します。ビルドにはDevExpress NuGetフィードとライセンスが必要です。他のすべてはどこでもビルドできるため、CIは無料で検証できます。
最も価値のあるコントリビューションは、抽出ツールが見逃したものを教えていただくことです。XAFは非常に大きく、コードベースごとに異なる部分を使用しており、単一のプロジェクトでフレームワーク全体を網羅することはできません。このための抽出ギャップ issue テンプレートがあります：プロジェクトで使用しているXAFパターンと、ツールが認識できなかったものを示してください。
CONTRIBUTING.mdを参照してください。バグ報告、ドキュメント、翻訳はすべて歓迎します。
MIT。DevExpressとの関係についてはNOTICE.mdを参照してください。
独立したコミュニティプロジェクトです — Developer Express Inc.とは提携、承認、サポート関係にありません。DevExpressのソースコードは含まれておらず、ビルドや実行にDevExpressライセンスは必要ありません。DevExpress、XAF、eXpressApp FrameworkはDeveloper Express Inc.の商標です。
Pedro Hernández（PeopleWorks）、[Microsoft MVP for .NET](https://mvp.microsoft.com/en-US/mvp/profile/24060a02-dbc6-44ec-bca5-c213ff9835c5）によって構築されました — DevExpressおよびXAFコミュニティのために。
Full detail of one controller: which views it applies to, every action it defines with the actual C# that runs when the action fires, and its helper methods. Use when asked what a button or command actually does.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Controller class name, e.g. 'ApproveInvoiceController'. Case-insensitive. | |
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It describes the output contents (views, actions, C# code, helper methods) but does not explicitly state that it is read-only or non-destructive, nor does it mention any side effects or limitations. It is informative but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the core purpose, and every sentence adds value. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description carries the load of explaining what is returned. It does so by listing the key content areas (views, actions with C# code, helper methods). It could be slightly more detailed about response format, but it is adequate for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (name and project) with 100% coverage. The tool description adds little beyond implying that 'name' identifies the controller. Baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (one controller) and exactly what it returns: views, actions with actual C# code, and helper methods. It distinguishes itself from siblings like xaf_search and xaf_overview by focusing on deep controller internals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use when asked what a button or command actually does.' This gives clear context for when to use the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Custom property and list editors this application defines, and built-in editors its controllers reconfigure at run time. IMPORTANT — a property rendered by one of these does NOT show the control its type implies, and the business class says nothing about it. Check this before describing or changing how anything appears on screen.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It prominently discloses a non-obvious behavioral trait: properties rendered by these editors do not show the control their type implies, and the business class gives no indication. This adds valuable context beyond a simple resource listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the scope of editors, and the second delivers an important caveat in caps. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple optional parameter and the absence of an output schema and annotations, the description covers the key behavioral trap and defines what types of editors are included. It could explicitly state what the tool returns (e.g., a list of editor names or settings), but the critical warning makes it sufficiently complete for likely use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the sole optional 'project' parameter with a clear description, so the baseline is 3. The tool description adds no additional context about how this parameter affects results, but it does not need to because the schema already covers it completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's focus on custom property/list editors and reconfigured built-in editors, which distinguishes it from siblings like xaf_controller and xaf_model. However, it lacks an explicit action verb such as 'list' or 'get', relying on the resource name to imply the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to consult this tool before describing or changing UI appearance, and highlights a critical caveat about misleading assumptions. It does not mention alternative tools or when not to use it, so it stops short of offering full decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail of one business entity: every property with its type and attributes, relationships to other entities, validation rules, appearance rules, and calculated property expressions. Use before writing or changing any code that touches an entity.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Entity class name, e.g. 'Invoice'. Case-insensitive. | |
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of indicating the tool's behavior. It discloses the full detail returned and implicitly signals a read-only operation via 'Use before writing or changing'. However, it does not explicitly state side effects or permissions, though likely unnecessary for this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with a clear definition of what the tool does, followed by a concise usage directive. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description thoroughly enumerates the return content and provides a clear usage context. It is sufficient for an agent to know when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage, including type and description for each parameter. The description adds no additional parameter-level guidance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full detail of a single business entity, enumerating the categories of information included. This is specific and distinguishes it from sibling tools like xaf_search or xaf_overview, which likely provide broader or partial views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to use this tool before writing or changing code that touches an entity, which establishes a clear 'when to use' context. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full differentiation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updater blocks that ran once when an existing database was upgraded past a version, and never again. Use when asked why a column contains what it contains, where legacy data came from, or what changed between releases — the code running today cannot explain any of that, and reasoning from it produces a plausible wrong answer.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It clearly states these blocks ran once and never again, establishing a read-only historical nature, and the caution about current code adds interpretive context. It does not mention output format, but that is less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first defines the resource, the second provides usage guidance. The wording is slightly dense but efficient, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately covers purpose, usage, and behavioral context. It does not describe return values, but the use cases make clear the tool returns historical migration information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'project' is already fully described in the schema (100% coverage), and the description adds no additional parameter-level details. This matches the baseline of 3 when the schema handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as updater blocks that ran once during database upgrades, which clearly distinguishes it from sibling tools about current code. It lacks an explicit verb like 'list' or 'show', but the noun phrase and usage guidance communicate its role as a historical reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when asked about column origins, legacy data provenance, or changes between releases. It also warns against reasoning from current code because it produces plausible wrong answers, effectively guiding the agent away from inappropriate alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Model Editor (.xafml) customizations: captions, list and detail view settings, columns, filters and application options. IMPORTANT — this behavior exists only in XML and cannot be inferred from the C# at all, so check it before concluding how a screen behaves.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that behavior is XML-defined and cannot be inferred from C#—a valuable insight. However, it doesn't state whether the tool reads or writes, what side effects occur, or what output to expect. This ambiguity is significant for a tool with 'customizations' in its scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first lists the tool's scope compactly, the second provides a crucial caveat. It is front-loaded with the domain and keeps the warning high-priority. No wasted words or redundant structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool operates in a complex domain (XAF model customization) with no output schema and no annotations. The description tells you what the tool covers but not what it returns, whether it mutates state, or how it relates to the many sibling tools. The XML caveat is helpful but insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'project' is already fully described in the schema ('Project name, when several are configured.'). Since schema coverage is 100%, the description adds no new semantic value, and the baseline of 3 applies. No extra usage details are given for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Model Editor .xafml customizations) and enumerates specific content areas (captions, list/detail views, columns, filters, app options). However, the verb is implicit ('customizations' rather than 'get' or 'edit'), so it doesn't crisply state the action. It does distinguish itself from sibling tools by focusing on .xafml model behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'IMPORTANT' statement gives a clear directive: check this tool before concluding how a screen behaves because behavior exists in XML, not C#. This implies when to use it, but it doesn't explicitly name alternatives or exclusions. Still, the usage context is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this XAF application is and everything it contains: ORM, module setup, and the COMPLETE list of entities, controllers, actions and navigation groups. Call this first when asked anything about the application as a whole. The lists are exhaustive: if something is not in them, it does not exist in this application.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name, when several are configured. Omit for the default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It does disclose a key behavioral trait—that the lists are exhaustive and authoritative—which is valuable. However, it does not mention other behavioral aspects such as performance implications, response format, or whether it reads from a cache or scans files, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence encapsulates the tool's content, and the second provides usage and behavioral guidance. There is no redundant or filler text, making it well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an overview tool with no output schema, the description provides a solid sense of what the response will contain (complete lists of key components). It stops short of detailing the exact result format or organization, but the content scope is clear enough for the agent to infer what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'project' parameter with a clear description, so schema coverage is 100%. The tool description adds no additional parameter semantics, so it does not go beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as an overview of the entire XAF application, listing ORM, module setup, and exhaustive enumerations of entities, controllers, actions, and navigation groups. It distinguishes itself from sibling tools by emphasizing it is the complete index and should be called first for whole-app questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this first when asked anything about the application as a whole', giving a direct usage trigger. It also implies the tool serves as a definitive existence check ('if something is not in them, it does not exist'), which guides when to rely on its results versus diving into specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discard cached analysis and re-read the source on the next query. The server already detects file changes automatically, so this is only needed if you believe the cached view is wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name, or omit to refresh all configured projects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the cache-discarding behavior, the deferred effect ('on the next query'), and the caveat about automatic file change detection. It omits details about side effects or permissions, but for a cache refresh tool, the description is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: first states the action, second gives the usage condition. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Low complexity (one optional param, no output schema). The description tells what happens, when to use it, and why it exists. Fully adequate for an AI agent to decide and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 100% of the single parameter, giving the project name and its optionality. The tool description does not add parameter-specific meaning, but the baseline of 3 applies since schema already documents the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action ('Discard cached analysis and re-read the source') on a specific resource (the analysis cache). This clearly distinguishes it from sibling xaf_* tools, which focus on searching, overviews, entities, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'only needed if you believe the cached view is wrong,' and provides context that the server auto-detects changes, implying regular use is unnecessary. This is direct when-to-use guidance with an implicit alternative (do nothing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports the application registers in source: what each is over, the filter and expressions in its layout, and the parameters dialog it opens with. Use when asked what a report shows, why its numbers differ from a screen's, or before writing a new one. Says explicitly when the list is a lower bound because users can also design reports at run time.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It adds a key limitation: 'Says explicitly when the list is a lower bound because users can also design reports at run time.' This is extra behavioral context beyond the raw purpose. It does not mention side effects or auth, but the tool is clearly read-only in nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Purpose is front-loaded, usage is provided, and the limitation is appended concisely. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers what the tool returns, when to use it, and a caveat about completeness. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so the schema already documents the 'project' parameter. The description adds no additional parameter-specific guidance, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Reports the application registers in source' and details what it covers (what each report is over, filter/expressions, parameters dialog). This clearly distinguishes it from sibling tools like xaf_search or xaf_entity, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when asked what a report shows, why its numbers differ from a screen's, or before writing a new one.' However, it does not mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The business rules the application enforces: validation rules with their messages and conditions, conditional appearance rules, and calculated properties. Use when asked what the system requires, forbids, or computes. Optionally narrowed to one entity.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | No | Restrict to one entity. Omit for every rule in the application. | |
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It details what the tool returns (validation rules with messages, conditions, appearance rules, calculated properties) and implies a read-only query. It does not explicitly state side effects or return format, but the level of detail is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences and every sentence serves a distinct purpose: defining the resource, specifying when to use it, and explaining parameter narrowing. It is front-loaded with the most important information and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description adequately captures content, usage, and parameter filtering. It does not mention empty responses or error handling, but that is not critical for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters fully described in the input schema. The description adds a small reiteration for 'entity' ('narrowed to one entity') but does not need to compensate for any schema gaps, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it returns the business rules the application enforces, specifically enumerating validation rules with messages and conditions, conditional appearance rules, and calculated properties. This goes beyond a generic resource name and effectively distinguishes the tool from sibling tools like xaf_model or xaf_entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when asked what the system requires, forbids, or computes,' providing a clear when-to-use directive. It also notes optional narrowing by entity, which adds practical usage guidance beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the whole application for a term: entity and property names, controllers, actions, validation messages, criteria expressions and seed data. Use when you know roughly what you are looking for but not where it lives — for example a field name mentioned by the user, or a business concept like 'discount'. Returns what matched and where.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Optional filter: entity, property, controller, action, rule, or seed. | |
| query | Yes | Text to look for. Case-insensitive, matches substrings. | |
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what is searched (entity names, validation messages, etc.), that it is case-insensitive, and that it returns what matched and where. It does not state side effects or permissions, but as a search tool, the read-only nature is implied and adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. Front-loaded with the verb 'Search', followed by scope and usage context, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple search tool. It covers purpose, usage, and return behavior, and no output schema means it needn't explain return structure beyond what is stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The tool description reinforces the 'kind' parameter by listing examples (entity, property, controller, etc.) and gives a concrete query example, but it adds minimal new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search the whole application for a term' which clearly states the verb and scope. It enumerates specific resource types (entity, property, controllers, actions, etc.), distinguishing it from sibling tools like xaf_entity or xaf_controller.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use when you know roughly what you are looking for but not where it lives' and provides an example. It gives clear context but does not mention exclusions or alternative tools, falling short of a fully explicit when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is loaded when a screen opens: every controller XAF activates on that view, why each one matches, and which of their actions appear. Call with no view to list the application's screens. IMPORTANT — most views exist in no file at all; XAF generates them from the business classes, so neither the C# nor the .xafml can be read to find them. Use before changing a controller, adding an action, or answering what a screen does.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | View id, e.g. 'Order_ListView'. Omit to list every view. Case-insensitive. | |
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the critical fact that most views are generated from business classes and not present in C# or .xafml files, preventing the agent from mistakenly reading files. It also reveals that omitting the view returns a screen list, a behavioral trait not visible from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences that front-load the core definition, then add an important caveat, then provide usage context. Every sentence contributes new information with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description gives a complete picture: what data the tool returns (controllers, actions, match reasons), how to invoke it (with or without a view), a critical gotcha about generated views, and concrete use cases. This is sufficient for an agent to correctly select and call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents both parameters (view, project) with 100% coverage, including default null and case-insensitivity. The description reinforces the view parameter's behavior by explaining the effect of omitting it (list all screens) but adds no new meaning for the project parameter. This meets the baseline for high schema coverage without major additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as showing what controllers and actions are loaded for a screen, with a specific resource (view) and detailed output (why each matches, which actions appear). It also explains the no-view invocation to list all application screens, distinguishing it from sibling tools like xaf_controller or xaf_model. This goes beyond a vague verb to explain the exact output scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use cases: 'Use before changing a controller, adding an action, or answering what a screen does.' It also explains the no-view pattern to list screens. However, it does not name alternative tools or specify when not to use it, so it's strong but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace one business process end to end: what runs, in what order, which entities it touches and which rules govern them, every step citing file and line. Start from an action, a controller method, a controller or an entity. Use this when asked HOW something works — 'how does approval work', 'what happens when I press this' — rather than what exists. Calls the trace could not follow are reported explicitly, so an empty list of them means the path really is complete.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Where to start: an action, a controller method, a controller or an entity. | |
| depth | No | How many hops to follow. Three covers an ordinary XAF process. | |
| project | No | Project name, when several are configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes the full burden of behavioral disclosure. It successfully discloses a important limitation: calls the trace cannot follow are reported explicitly, and an empty list has a meaningful interpretation. It does not explicitly state whether the tool is side-effect free, but the read-only affordance of a trace is strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no filler. It opens with a concise definition of the tool, then quickly gives usage criteria, and ends with an important nuance about the completeness of the path.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex exploration/walkthrough tool with no output schema and no annotations, the description covers the needed invocation context: starting points, scope, traversal boundaries, citation by file and line, and interpretation of missing-boundary results. It gives enough structure for an agent to know both when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, so schema coverage is 100%; the baseline is 3. The description only reinforces the required 'from' parameter's valid starting points without adding behavior or details about 'depth' or 'project' beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—'Trace e one business process end to end'—and specifies what the trace covers: what runs, execution order, touched entities, and governing rules. The phrase 'rather than what exists' distills the tool from sibling existence/search tools, so selected against and invocation are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this path 'when asked HOW something works' and gives concrete examples like 'how does approval work' and 'what happens when I press this'. It also contrasts it with what-exists questions, giving an explicit when-to-use and when-not-to-use distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.16.0xaf_reportsv0.15.0xaf_walkthroughv0.12.1xaf_viewv1.0.0xaf_controllerxaf_editorsxaf_entityxaf_migrationsxaf_modelxaf_overviewxaf_refreshxaf_rulesxaf_searchScored across 12 tools
Each tool targets a distinct source of truth (overview, entity, view, controller, model, editors, rules, reports, migrations, search, trace). A couple of adjacent tools (xaf_entity vs xaf_rules, xaf_view vs xaf_model) cover overlapping facts, but the use-case guidance clearly separates them.
All tools share a uniform `xaf_` prefix followed by a short, descriptive noun/verb, so the family is instantly recognizable. `xaf_refresh` is the only imperatively named tool, but this is a deliberate and predictable exception for a cache-control function.
Twelve tools is within the ideal range and each tool addresses a distinct aspect of explaining an XAF application. The count feels intentional rather than padded; there is no obvious redundancy or token-for-count inflation.
The surface covers static structure (overview, entities, views, model, editors), dynamic behavior (controllers, walkthrough, rules), historical data (migrations), and search/reporting (search, reports), plus a cache refresh for correctness. No essential operation for the stated explainer purpose is missing.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
AI Agent with Architectural Memory. Impact analysis (free), tests and code from the graph (pro).
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Shared memory for coding agents. Stop re-explaining your codebase every session.
