---
title: "Using the server"
description: "Four steps from nothing to the first answered question."
canonical: index.html
navigation-title: "Usage"
---

<a id="using-the-server"></a>

# Using the server

- [\1. Install it](#1-install-it)
- [\2. Finish in the client](#2-finish-in-the-client)
- [\3. Ask it one question](#3-ask-it-one-question)
- [\4. Describe your task](#4-describe-your-task)
- [Afterwards](#afterwards)

Four steps from nothing to the first answered question. Each is short here and
names the page that has the detail.

<a id="1-install-it"></a>

## \1. Install it

One standalone checkout serves every project on the machine. `install` writes
into the directory it runs in. So the last two lines run from the root of the
project the agent works in, never from the checkout:

```bash
git clone https://github.com/TYPO3/dev-companion.git typo3-dev-companion
composer install --working-dir=typo3-dev-companion
cd /path/to/your/project
/absolute/path/to/typo3-dev-companion/bin/typo3-dev-companion install
```

Without `--agent` that writes the entry into `.mcp.json` and the skills into
`.agents/skills`, the two places a client finds without configuration for it.
Name a client that reads elsewhere, `--agent=cursor`, `--agent=copilot`, and
[the client table](installing.md#installing-clients) says which file each one gets. A
project can require the package instead of a pointer at a checkout; that and
every other case is [Installing the server](installing.md).

<a id="2-finish-in-the-client"></a>

## \2. Finish in the client

A file on disk registers nothing. The client has to read it, and most ask you to
approve a project server before they start it. Claude Code reads `.mcp.json`
when a session starts, so restart the session and approve at the prompt. The
install prints what your client needs under the line that reports the entry.
[Finishing in the client](installing.md#installing-finishing-in-the-client) has the same list with each client's
own documentation behind it.

<a id="3-ask-it-one-question"></a>

## \3. Ask it one question

In the client you work in:

> Which icon identifier is the right one for a delete button in the TYPO3
> backend?

Then look at what the agent did: a call to `typo3_icon_lookup` means the
server answers. An answer with no call behind it means the client never started
it, and [Checking that it answers](checking-it-answers.md) is how to find out why.

<a id="4-describe-your-task"></a>

## \4. Describe your task

There is nothing more to drive. Describe the work in whatever language you speak
to your agent in, and the server tells the agent at connect where to start.
[Working with it once it runs](working-with-it.md) is what that changes on your side of the conversation.
[task-skills/](task-skills/index.md) lists the workflows the install
published beside the server, with their complete instructions.

<a id="afterwards"></a>

## Afterwards

- `typo3-dev-companion update` refreshes the skills and the entry after this
  package moved. A server that finds stale copies puts them back on its own, see
  [Keeping it current](installing.md#installing-keeping-it-current).
- Which tools the server offers, and the four environment variables the entry
  may carry: [What the entry may carry](installing.md#installing-what-the-entry-may-carry).
- Taking it out again — [Removing it](installing.md#installing-removing-it).

It is a local subprocess, started by the client over stdio, and it reads. It
writes nothing into the TYPO3 installation it points at. The one exception is
the feedback channel, which writes into this server's own checkout, and only a
standalone checkout offers it.