reference
The eight tools
What each one answers from, which releases it holds for, and how it last answered.
Open the tool reference
Feature
Every answer says where it came from
A tool declares the sources it may answer from. The answer carries the one that answered, the releases it holds for, and what it leaves out — and a result that cannot name its source is not returned at all.
5
sources
Bundled knowledge, this checkout, installed packages, the booted installation, and the network.
4
preconditions
From nothing running to outbound reach. Each source declares which one it needs.
0
writes
Every source is read. Nothing is written back, and nothing is executed to answer.
240 ms
typical answer
From bundled knowledge, with no installation booted and no request leaving the machine.
Every source has a precondition
The five differ in how much of the machine has to be running before they can answer. Bundled knowledge and the server’s own checkout answer with nothing running; installed packages need files on disk; the installation source needs a booted installation; network sources need outbound reach.
A declaration is resolved, not documented
The server checks a tool’s declared sources against the machine it
was started on. One it cannot reach is not offered, so a question is
never answered by a source that was unavailable when it was asked.
The five sources
Named as the result names them. What a tool returns in answeredBy is one of these five strings and never a sentence about one.
| Source | What it reads | Required machine state | Versions |
|---|---|---|---|
| knowledge | Curated rules and hints, shipped with the server | nothing running | 12.4 · 13.4 · 14.3 · main |
| checkout | This server’s own repository | nothing running | follows the checkout |
| packages | Files on disk, read and never executed | files on disk | follows the installation |
| installation | Assembled runtime state | a booted installation | follows the installation |
| network | Official documentation and core services | outbound reach | requested release |
What a result carries
Four fields beside the answer, and each of them is there to make a claim checkable: which source answered, which were declared, which releases it holds for, and what the answer does not cover.
The installation could not be booted — packages were read instead
So this result omits anything a running extension would register at
runtime. ddev start would close the gap.
A degraded result
json
{
"answeredBy": "packages",
"declared": ["installation", "packages"],
"versions": ["13.4", "main"],
"omitted": "dynamically registered entries, never read"
}declared is what the tool was allowed to read; answeredBy is what it reached. The two differing is the whole of what “degraded” means here.
Three consequences
The declaration is one line in a tool. What it buys is spread across every answer that tool ever gives.
in every result
The source is named, not implied
A tool declares what it may read and returns which of them answered. Two answers that disagree can be told apart by where they came from rather than by which was asked for last.
when it degrades
A shortfall travels with the result
Where a source is out of reach the next one answers, and the result says what the substitution left out. A partial registry never looks complete.
across releases
A binding, or none at all
Every answer holds for named releases. Where a claim cannot be bound to one, it is not returned — an unbounded rule is a rule that is wrong somewhere.
What it does not do
A source is a statement about where an answer came from. It is not a statement about whether the answer is right, and the two are worth keeping apart.
It does not rank the sources against each other
Where two could answer, the tool’s own order decides — not a score.
A result names the one that answered so the caller can disagree with
that order, which is a decision the caller is better placed to make.
It cannot vouch for an extension that overrides core behaviour
The installation source reads assembled runtime state, so what an
extension changed is in the answer without being attributed to it.
Where that matters, the tool says which releases it checked and stops.
Read on
documentation
Sources and preconditions
The five sources in full, and what the server does when one of them cannot be reached.
Read the documentation
guide
Writing a task skill
How a skill declares the sources it needs, so it fails at registration rather than mid-answer.
Read the guide
Install it
One command, and the client finds the server. PHP 8.2+, and a TYPO3 project it can read — nothing has to be running for the first answer to arrive.
Install
bash
# one command, and the client finds it $ composer require typo3/support-app ✓ registered 8 tools in .mcp.json
The tools register themselves with their declared sources. One that cannot reach any of them says so at registration rather than in the middle of an answer.