The xaf-logic-explainer server provides live, queryable access to an XAF application's source code using Roslyn (no compilation required), bridging general XAF knowledge with the application's unique logic. It offers:
xaf_overview: Full application inventory—ORM, modules, entities, controllers, actions, navigation groups.
xaf_search: Keyword search across entities, properties, controllers, actions, rules, messages, seed data.
xaf_entity: Detailed entity info—properties, types, attributes, relationships, validation/appearance rules, calculated expressions.
xaf_controller: Controller details—target views, actions, handler code, helpers.
xaf_rules: Business rules—validation, conditional appearance, calculated properties, optionally by entity.
xaf_model: Model Editor (.xafml) customizations—captions, view settings, columns, filters (XML-only).
xaf_editors: Custom and reconfigured property/list editors, including JS dependencies.
xaf_migrations: Version-gated database migration blocks explaining legacy data.
xaf_refresh: Discard cache and re-read sources (automatic change detection also in place). The server stays up-to-date with live file monitoring, complements DevExpress agent-skills and Docs MCP servers, and supports multi-project configuration via an optional project parameter.
Provides tools for explaining DevExpress XAF applications by extracting entities, controllers, actions, business rules, navigation, and Model Editor customizations from source code to help AI agents understand the application.
Teach your AI coding agent what your XAF application actually does.
Point it at an XAF module. It reads your entities, controllers, actions, business rules, navigation and Model Editor customizations straight from source — and hands the result to whatever agent you code with.
DevExpress has done excellent work making AI agents fluent in XAF. Two pieces already exist, and this is the third:
Teaches the agent… | Tool |
How XAF works in general | |
What the official documentation says | |
What YOUR application does | XAF Logic Explainer ← you are here |
An agent that has read every page of the XAF documentation still does not know that your Invoice
total is calculated from its lines, that ApproveController refuses to run when the period is
closed, or that three columns were hidden in the Model Editor and appear in no C# file at all. It
will confidently invent all three.
That gap is not solvable by better prompting. It is solvable by extraction.
These tools compose. Install the DevExpress skills for framework knowledge, use the Docs MCP for the official reference, and use this for your own codebase. None of them replaces the others.
Related MCP server: mcp-digger
Everything below is read as syntax, using Roslyn. Your project never has to compile, and this tool never links against DevExpress assemblies:
Entities — properties, types, associations, and the XAF attributes that give them meaning
([Association], [Aggregated], [RuleRequiredField], [Appearance], [ModelDefault], …).
XPO and EF Core, auto-detected from your using statements.
Controllers and actions — SimpleAction, PopupWindowShowAction, SingleChoiceAction,
their target criteria, and the handler code that runs when they fire.
Business rules — validation attributes and code rules, with the conditions attached.
Module setup — ModuleUpdater seed data and what gets created on first run.
Navigation — the groups and items your users actually see.
Model Editor (.xafml) — the customizations that exist only in XML and are invisible to
anyone reading your C#. Module and platform files are merged the way XAF merges them.
Custom property and list editors — including the JavaScript they cannot work without, and
built-in editors reconfigured at run time through View.CustomizeViewItemControl<T>(). These
live in the platform project beside the module, so nobody reading the business objects meets
them.
Version-gated migrations — the CurrentDBVersion < new Version(…) blocks in your updater.
Each runs at most once for any database, and is the only explanation for data the current code
cannot account for.
Reports — what each one is over, the filter inside its layout, its calculated fields and bound
expressions, and the parameters dialog it opens with, down to the GetCriteria() that turns the
answers into a filter. Read from designer code, from a .repx, or from the report's own
constructor.
Every screen, and what loads onto it — see below.
These are the reason an agent that has read every business class can still be confidently wrong about the application:
Nothing in an XAF repository answers that, and both halves are missing for different reasons.
The screens themselves are in no file. XAF generates a list, a detail and a lookup view for
every business class, plus a list view for every collection, and the Model Editor stores only the
ones somebody changed. Grepping your source for Patient_Prescriptions_ListView finds nothing —
and that is not evidence it is missing.
Which controllers run there is decided at run time, by four conditions XAF ANDs together: nesting, view type, object type and view id. Each is unrestricted when unset, so a controller that sets none of them loads onto every screen you have.
This reads all four the way ViewController.IsFitToView evaluates them, against a view inventory
built from the framework's own id generators — and records why each one matched, so the answer
can be checked rather than trusted:
Two layers, kept apart. What your team wrote gets the full treatment; what XAF provides is folded away behind one line, because there is a great deal of it and it is not yours to change. With a ground-truth catalog it is named too — scoped to the modules you actually register, so a WinForms controller never appears on a Blazor screen.
What it will not claim: a controller listed here can still switch itself off through
Active["reason"], which depends on the data and the user. This is what XAF loads onto a
screen, not what will necessarily do something — and anything it could not read from the source is
listed apart, with the reason, instead of being quietly treated as "runs everywhere".
Every other section here is a claim that we found something you could not see. This one is the opposite, and it is the more useful half.
Reports V2 lets your users design reports at run time. Those are stored as rows in your database, not as files — so no tool that reads a repository can see them, this one included. An application with forty reports and none in its source is not unusual; it is what a successful reporting setup looks like.
So the answer changes shape depending on what is knowable:
Your application | What you are told |
No | "these are all of them" — nothing can appear at run time |
Module registered, reports in source | "this list is a lower bound" |
Module registered, none in source | "the true number is not zero but unknown" |
That last row is the common case, and it is where a confident tool does real damage. An agent told
"this application has no reports" will design as though none can exist — for an application whose
users built forty. AGENTS.md says it outright:
The number is unknown, not zero — do not tell anyone this application has no reports.
The same rule governs the framework catalog. If the catalog on your machine describes DevExpress 26.1 and your application declares 23.2, every framework answer says so, with both numbers, rather than being presented as certain.
A tool that never says "I cannot see that" is not more capable. It is less checkable.
dotnet tool install -g XafLogicExplainer.Cli
xaflogic agents --project "C:\MySolution\MyApp.Module"That writes AGENTS.md, CLAUDE.md and .github/copilot-instructions.md at your solution root.
No account, no API key, no server. Your agent understands the application on its next question.
AGENTS.md is prepended to every request an agent makes in the repository, so its cost is paid
forever. Dumping 70 KB of entity detail there would crowd out the actual question. So the output is
tiered:
| ~11 KB | Always loaded: ground rules, complete inventories, conventions, recipes |
| ~70 KB | Opened on demand: full properties, handler code, rule messages, |
The most valuable part is the smallest. AGENTS.md opens with ground rules — that this
application uses XPO and never EF Core, that the inventories are complete so anything absent
genuinely does not exist, and that some behavior lives in the Model Editor rather than in C#. Those
few paragraphs stop most of the confident invention agents produce about unfamiliar XAF codebases.
Existing files are never clobbered: generated text lives between markers, anything you wrote by hand is preserved, and regenerating is byte-identical when nothing changed.
Generated files are a snapshot. The MCP server is a live connection — the agent queries your application while you work on it, and cannot go stale.
/plugin marketplace add peopleworks/XAFLogicExplainer
/plugin install xaf-logic-explainer@peopleworks-xafThat installs a skill and an MCP server in one step. For any other MCP client, either run it straight from NuGet with no install:
{
"mcpServers": {
"xaf": { "command": "dnx", "args": ["XafLogicExplainer.Mcp", "--yes"] }
}
}…or point at the CLI if you already have it:
{ "mcpServers": { "xaf": { "command": "xaflogic", "args": ["mcp"] } } }Started from a solution directory it finds the XAF module by itself, so neither form needs a path.
Tool | Answers |
| What this application is, and the complete list of everything in it |
| Where a field, concept or business term is defined |
| Every property, relationship, rule and calculation on one entity |
| What an action does — including the C# that runs when it fires |
| What the application validates, computes, hides and disables |
| Model Editor customizations, which exist in no C# file |
| Custom editors, the JavaScript they need, and built-in editors changed at run time |
| What ran once against a live database, and the comment explaining why |
| What each report is over, the filter inside it, and the dialog it opens with |
| Everything loaded onto one screen — which controllers activate, and why |
| How one process works end to end — what runs, in what order, and what it could not follow |
| Re-read the source (changes are detected automatically) |
Ask for something that isn't there and the answer is the useful one:
There is no entity called 'PurchaseOrder' in this application. This is the complete list of 19 entities, extracted from the whole source tree: … If the user expects 'PurchaseOrder' to exist, it has not been created yet.
Pair it with the official DevExpress skills. /plugin install dx-xaf@DevExpress-agent-skills
teaches how XAF works; this teaches what your application does. An agent with only the first will
write correct XAF against entities you do not have.
An agent reads AGENTS.md or queries the MCP server. Someone who has just inherited a ten-year-old
XAF application needs the same facts arranged very differently:
xaflogic explain --project "C:\MySolution\MyApp.Module" --openOne HTML file. No server, no build step, no request to the network — it opens from an email attachment on a machine with no internet, which is how handovers actually happen.
It draws a map of your domain model from the association attributes scattered across your codebase. Most teams have never seen theirs: it exists in one person's head, which is exactly the knowledge that leaves when they do.
Real output, from the sample application in this repository. Hover an entity and everything it does not touch fades; purple means deleting the parent deletes the child.
Alongside it: every entity and what each property is, every action with the code it runs, validation with the message the user will actually see, and the Model Editor settings that appear in no C# file.
And an index of every criteria expression in the application — a dialect that is neither SQL nor C#, gathered from attributes spread across the source and otherwise collected nowhere:
Try it on the sample without touching your own code:
xaflogic explain --project tests/XafLogicExplainer.Tests/Fixtures/DemoSolution/PharmacyDemo.Module --openYou have delivered XAF applications to clients for ten years. Somewhere in there you already modelled the class you are about to write again, and you cannot remember which project it was in.
xaflogic projects add --name pwLegalOffice --project "C:\Clients\Legal\pwLegalOffice.Module"
xaflogic projects add --name Presupuesto --project "C:\Clients\Budget\PWPresupuesto.Module"
xaflogic wiki --openOne HTML file over all of them, and a section that exists in no single-project tool:
Classes you modelled more than once — with a property-by-property comparison, so you can see
which application models Cliente in the most detail before writing it a fourth time.
The layer you wrote yourself — base classes carried from one application into another. Your own framework, the one that was never written down. A base class is listed only when its own source was read in one of the projects, so nothing is matched against a list of DevExpress type names that would rot at the next release.
The same name, two shapes — where Total is a decimal in one application and a double
in another. Nothing is broken; each one compiles. It is how a total ends up two cents out.
Names you keep — the vocabulary of your applications, which nobody wrote down and everybody who joins has to learn by reading code.
And a map of the whole estate, drawn from the same reading:
Real output, from the three sample client modules in this repository. Each class sits at the average direction of the applications that model it, at a distance set by how much they agree — so a class every application has falls to the centre. The middle is your common ground; the rim is the work that belongs to one client.
Beside it, two more that only a corpus can produce: which two of your projects are most alike, as a grid you can click to hold the page to just those two, and the DevExpress releases your estate is spread across — with the one your framework catalog actually describes marked, so every claim about DevExpress types says whether it was checked against the right release.
Everything in it is computed from what was read. There is no place in the page to put a sentence somebody typed about the corpus, because a hand-written summary of nine applications is wrong the day the tenth is added and nobody notices.
Filter by any project to see only what it has in common with the rest. And the honest part is on the page too: two classes are matched by name, so the wiki tells you they share a name — the comparison is what tells you whether they share an idea.
You arrive at an XAF project you have never seen and, half a day later, hand someone a document
about it. The last step is not this tool's. xaflogic extract writes Markdown, and
mcpOffice — an MCP server built on the DevExpress Office
File API — turns Markdown into .docx and .docx into PDF. With both servers connected, the agent
hands one to the other. There is no Word exporter here and there will not be one
(#28): reading an XAF application
needs no DevExpress, and that stays true.
xaflogic extract --project "C:\MySolution\MyApp.Module"
# writes .xaflogic-output/MyApp_Full.md, and one file per section beside itThen, to the agent:
Turn
.xaflogic-output/MyApp_Entities.mdinto a Word document withword_create_from_markdown, thenword_convertit to PDF.
Hand over a section file rather than _Full.md when the reader is one audience: _Entities.md is
the data dictionary, _BusinessRules.md the rules, _Controllers.md what the buttons do.
word_create_from_markdown takes a templatePath, so headings, tables, header and footer can come
from your own .dotx.
Verified on the sample application in this repository: every heading becomes a Word heading and appears in the document outline, the property tables become real tables, fenced C# becomes shaded monospace, and lists, bold and inline code survive. Nothing in the generated Markdown is HTML, and a test keeps it that way.
mcpOffice needs a DevExpress licence, because it writes Office files with DevExpress's API. If you run an XAF application, you have one. Setup is in its usage guide.
Extraction reads your source without knowing anything about the framework it is written against,
which leaves one question unanswerable: is DeleteObjectsViewController something your team wrote,
or something DevExpress ships? Without an answer, generated documentation presents framework
behavior and your own logic as the same thing.
If you have a DevExpress licence:
xaflogic catalog buildThat reads your own installation and records what XAF itself provides — attributes, controllers, model interfaces and modules, with the official summaries and documentation links DevExpress ships. On DevExpress 26.1 that is around 850 framework types.
If you also installed the DevExpress source code component, it records where each framework
controller activates — the four conditions XAF checks before running it. That cannot be read from
the assemblies: four out of five built-in controllers set their target inside a constructor. Pass
--dx-sources <Components/Sources> if they are not beside your assemblies.
Extraction then picks it up automatically and can say things it otherwise could not:
"ArchiveController extends the built-in DeleteObjectsViewController" — you are changing how
deletion works application-wide, not adding a feature beside it.
"[AuditedByFinance] is not an XAF or .NET attribute" — your team invented it, so its meaning
lives in this codebase and in no documentation anywhere.
"32 framework controllers also load onto this screen" — named, with what each one does, and scoped to the modules your application actually registers, so a WinForms controller never appears on a Blazor screen.
The catalog is written to ~/.xaflogic/catalog/, never into your repository: it is derived from
licensed software. Everything works without it — it only sharpens the output. See
NOTICE.md.
Command | What it does |
| Write |
| Run as an MCP server so agents can query the app live |
| Write a self-contained HTML page explaining the app to a person |
| Read every project together and say what they have in common |
| Build the DevExpress ground-truth catalog ( |
| Read the project, write Markdown + JSON locally |
| Trace one business process — what runs, in what order, and what governs it |
| Compare against the previous extraction and report what changed |
| Show the change-detection hash and whether a re-extract is needed |
| Re-extract on file change, with debounce |
| Extract and publish to a remote target |
| Ask questions about the extracted project |
| Set defaults in |
| Manage several XAF projects; most commands accept |
Documentation is generated in English or Spanish (--lang en|es).
Useful flags: --orm auto\|xpo\|efcore, --lang en\|es, --enrich (AI-generated business-logic
summaries per controller and action), --force, --all.
xaflogic walkthrough --from ApproveOrder # to the screen, or > process.md
xaflogic walkthrough --from ApproveOrder --depth 4 --out docs/approval.mdWhat runs, in what order, which entities it touches and which rules govern them — every step citing
file:line, with a Mermaid diagram emitted from the trace itself, never drawn by a model. Calls
the trace could not follow are listed rather than skipped, so an empty list means the path really is
complete. Add --narrate for prose over the steps; a paragraph that cannot name a real step is
dropped before you see it.
xaflogic walkthrough --from ApproveOrder --since # against the last extraction--since re-walks the same process over a stored snapshot and reports what is different about
this process: a step added, a rule now governing it, a body rewritten, a branch gone, a call the
trace can no longer follow. No conversational agent can answer that, because none of them has a
yesterday.
--enrich and --narrate need a model, and any of these is enough — a key on the command line
wins, then the environment, then a PeopleWorks Copilot account if you happen to have one:
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-...Everything else in this tool runs with no key, no account and no network — the walkthrough included, minus its prose.
Extraction is incremental — a SHA-256 over your .cs and .xafml files means an unchanged
project is a no-op. There is an MSBuild .targets file if you want it to run on build.
v0.17.0. The extraction engine is the mature part: it runs in production against real XAF applications. The agent-facing surface is what is landing now, in the open.
✅ | Roslyn extraction — entities, controllers, rules, updater, navigation, |
✅ | XPO and EF Core, auto-detected |
✅ | Custom property and list editors, their client assets, and built-in editors reconfigured at run time |
✅ | Version-gated data migrations — what happened to databases that were not fresh |
✅ | Incremental change detection, diff reports, multi-project, watch mode |
✅ | Walkthrough — one process traced end to end, with a diagram emitted from the trace, the calls it could not follow, and |
✅ | AI enrichment of controllers and actions ( |
✅ | Blazor in-app help panel |
✅ |
|
✅ |
|
✅ |
|
✅ | Pluggable publishing targets ( |
✅ | MCP server — 12 tools, live against your source |
✅ | Installable Claude Code plugin with skill and MCP server |
✅ | 556 tests over synthetic XPO and EF Core fixtures — no DevExpress needed |
✅ | DevExpress ground-truth catalog, generated locally by licensees |
PeopleWorks Copilot, where this tool grew up, is now one sink among several rather than the destination everything was built around. The outputs that matter most need no server at all.
Why a third of an XAF application's behaviour lives outside its business classes, the four places it hides, and what the extracted output actually looks like:
Your coding agent knows XAF. It has never seen your application.
Tu agente de código sabe XAF. Nunca ha visto tu aplicación. — en español
Each is written in its own language rather than translated from the other. Sources in
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 pluginBuilt on .NET 10.
Only XafLogicExplainer.Blazor references DevExpress packages; it needs the DevExpress NuGet feed
and a license to build. Everything else builds anywhere, which is why CI can verify it for free.
The single most valuable contribution is telling us what the extractor missed. XAF is enormous, every codebase uses a different slice of it, and no single project exercises the whole framework. There is an extraction-gap issue template for exactly this: show the XAF pattern your project uses and what the tool failed to see.
See CONTRIBUTING.md. Bug reports, docs and translations are equally welcome.
MIT. See NOTICE.md for the relationship to DevExpress.
An independent community project — not affiliated with, endorsed by, or supported by Developer Express Inc. It contains no DevExpress source code and needs no DevExpress license to build or run. DevExpress, XAF and eXpressApp Framework are trademarks of Developer Express Inc.
Built by Pedro Hernández (PeopleWorks), Microsoft MVP for .NET — for the DevExpress and XAF community.
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. Dates show when Glama detected each change.
v0.16.0xaf_reportsv0.15.0xaf_walkthroughv0.12.1xaf_viewv1.0.0xaf_controllerxaf_editorsxaf_entityxaf_migrationsxaf_modelxaf_overviewxaf_refreshxaf_rulesxaf_searchEach tool targets a distinct aspect of XAF applications: overview lists everything, entity dives into one entity, view explains screen behavior, controller explains action code, rules cover business logic, etc. The purposes are clearly separated with cross-references, so an agent can confidently select the right tool without confusion.
All tool names follow a uniform `xaf_` prefix followed by a descriptive noun (or verb for refresh), using snake_case throughout. The pattern is predictable and immediately signals the tool's domain, making it easy to guess what each tool does.
With 10 tools, the server covers the full spectrum of XAF application exploration without being bloated. Each tool addresses a specific concern and is essential for the stated purpose of explaining application logic, from high-level overview to low-level controller details.
The toolkit provides comprehensive coverage of an XAF application: entities, views, controllers, rules, editors, model customizations, migrations, and a global overview. The addition of a search tool and cache refresh ensures no dead ends, making it a complete solution for understanding any aspect of the application.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/peopleworks/XAFLogicExplainer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
