MCP: connect a client agent and ask your own data

Step by step

1. 1. Decide what the connection gives you and what it does not change

   The MCP server exposes the context of your product to a client agent: strategy, goals, hypotheses, assumptions, decisions, artifacts and sizing. The client agent asks a question in plain language and receives an answer assembled from that context, with citations to the source nodes and a mark of how current they are. This is a second surface for the same mechanism that answers questions inside the TaskTreker interface — not a separate product and not a chat that replaces the interface. It also does not move the product boundary. TaskTreker is not becoming a task tracker, a chat or a file manager: your tasks stay in the tracker your team already uses, and product analytics stays in the analytics tool your team already reads. If a promise about what the MCP server does not appear in this guide, treat it as unconfirmed.

2. 2. Prepare the context before you connect the agent

   Answers are assembled from the context store — the structured, versioned memory of your product — and not from the open internet. That means the quality of the answer is decided long before the agent connects: by the confirmed decisions, hypotheses, assumptions and artifacts you have recorded. Two rules follow from this and they are worth checking in advance. First, extracted material is not context: whatever the capture layer pulled out of a meeting or a document arrives with the status “not verified” and does not enter answers until a person confirms it. Second, the model does not decide access and does not fill gaps: when the context holds no answer, the correct result is an explicit “I don’t know” with a suggestion to create a decision record, not a plausible paragraph. If you connect the agent to an empty workspace, the honest answer you will get is that there is nothing to answer from.

3. 3. Connect the server in the client agent and authorize with your own account

   Add the TaskTreker MCP server to the MCP configuration of your client agent — Claude Code or Cursor — and authorize the connection with your own account in the workspace. The account matters: access is granted to a specific person, and the company’s data stays isolated, so an agent connected as a member of one company never sees the context of another. A client agent connected on behalf of the whole company, or shared between colleagues without separate accounts, breaks that isolation and is not a supported setup. Rights and connections are managed in the company settings, where the administrator sees the users, their roles, the connected services and the billing. If the agent answers with data that is not yours, stop there and re-authorize before asking anything else — that symptom is an isolation failure, not a question about your data.

4. 4. Check the access mode and keep it read-only

   The default mode is read-only, and the product treats that default as a rule, not as a recommendation. Reading the context and answering questions about it is allowed. Changing a node of the context is not: when the agent attempts a write, the attempt is rejected and recorded in the audit log. Write access is only possible where it has been explicitly enabled in the settings, and the decision about what to allow belongs to a person with the corresponding rights — the language model never grants it to itself. Keep read-only mode while you are getting to know the setup: most questions are answered from what is already recorded, and a write that you did not intend is easier to prevent than to notice afterwards. When you do enable write for a specific case, remember that the change applies to the connection you configured, and check the audit log afterwards to see exactly what was changed.

5. 5. Ask the first question about your own context

   Ask a question the way you would ask a colleague who was in the meeting: “why did we decide to do it this way”, “which assumption does this hypothesis rest on”, “what did we promise the customer about this”, “what changed in this release”. The question goes through the same mechanism as the search inside the interface, and the answer arrives with citations pointing at the context nodes it used and a mark of their freshness — when the source was created and whether it is overdue. Start with a decision that was actually recorded, because that is the scenario the product is built around: the chain from assumption to hypothesis to decision to consequence, with a link to the source at every step. Keep the first question narrow. A broad question returns a broad answer, and it is harder to tell a weak answer from a thin context than it is to tell which node is missing.

6. 6. Read the answer: citations, freshness, and honest gaps

   Four things are visible in a correct answer, and they are the same whether it came from the interface or from the agent. Every factual statement carries a reference to the context node it came from. Sources show their date, and a source that is out of date is marked as such rather than quietly used. Numbers without a source are labelled as an estimate and are not treated as fact. And when the context holds no answer, you get an explicit “I don’t know” with a suggestion to create a decision record. Two consequences follow for your own practice. An “I don’t know” is information: it points at a gap in the context that is worth closing, not a defect of the agent. And when two versions of the same statement contradict each other, the answer shows both with their dates instead of silently choosing one — the context is yours to settle, and the agent is not allowed to settle it for you.

7. 7. Check the audit log and the run log after the first session

   Every call made through the MCP server lands in two places. The audit log records who called what and when — it is the trail you use if a question of access ever arises. The run log records the input, the output, the status and the cost of the run, the same way runs inside the product are recorded. Read both after the first session: it is the fastest way to understand what the agent really asked for and what it really received. Two habits are worth forming. First, run the audit log whenever you connect a new agent or change who is authorized. Second, treat the run log as the place where you check the freshness of an answer later — an answer produced from a source that was current last month is not the same claim as one produced today, and the log is where that difference is visible.

8. 8. Connect the source systems and keep the way out open

   The MCP server answers from the context; the context is filled from the systems where your work already happens. Twelve integrations are part of the target state of v1: Linear, Jira, GitHub, Notion, Confluence, Slack, Google Docs and Drive, Figma, Amplitude and Mixpanel, HubSpot and amoCRM, email, and the MCP server itself. Each of them is a separate connection with its own rights — what is read, what is not, what leaves for the model. Two properties hold for every connector: it can be switched off without breaking the product, and the data can be exported without loss. The universal path — import and export in Markdown, JSON and CSV — covers the stacks that have no dedicated connector, so a rare tool does not become a reason to wait. After connecting, verify the way out: export the context and check that the result is complete, before you rely on the system with anything you cannot afford to lose.

If it does not work

The agent answers, but the answer is “I don’t know”.

This is the designed behaviour when the context holds nothing confirmed on the topic. The answer is assembled from the context store, and extracted material that nobody confirmed does not enter it. Record the decision, or confirm the extracted node, and ask again. If the question keeps returning the same answer, the missing piece is a gap in your context — and the suggestion to create a decision record is exactly what to act on.

The agent shows data that is not ours.

Treat this as an isolation failure, not as a curiosity. Revoke the connection in the client agent, re-authorize with your own account, and check in the company settings which accounts are currently connected. Access is granted to a specific person and companies stay separated, so an agent that answers with another company’s context is misconfigured or mis-authorized. Nothing else should be asked of the agent until the authorization is confirmed.

The agent tried to change a node or write a task.

Read-only is the default, so a rejected write is the system working as intended: the attempt was declined and written to the audit log. Look at the log to see what the agent was trying to do. If the write was needed, enable it explicitly for that connection in the settings — and remember that a decision about access is made by a person, not by the model. Read the audit log afterwards to confirm that only what you expected was changed.

We disconnected a connector and part of the context became unavailable.

Any integration must be switchable off without breaking the product, and the data must remain exportable without loss — that is a requirement on connectors, not a courtesy. Reconnect the service if you need it live again, or take the exported copy and work with it through the universal path: import and export in Markdown, JSON and CSV. If the disconnection did remove data you had not exported, treat it as a defect and report it, because the export path is the safety net the product promises.

The agent and the interface give different answers to the same question.

This should not happen and is worth reporting: answers in the agent and answers in the interface use one and the same mechanism for citations and for “I don’t know”, and a divergence between them is a defect rather than a feature. Before reporting it, note the two answers, the question, the date and the version of the context each was built on — the run log holds the input, the output and the status, and the audit log holds the call itself. With those, the cause can be established instead of guessed at.