# Scope Boundaries — what Cortex/MCP does NOT do

> Not every request is a task. Some ask for things the MCP **cannot** do (credential/tooling limits) or **should not** do
> (someone else owns the work). Recognizing these early saves a triage cycle: they are not bugs, not feature requests,
> and not `report_feedback` material — they get named plainly and closed. This doc is the canonical list, each boundary
> tied to the ticket that established it, so the same "out of scope" answer is consistent across operators.

The self-sufficiency doctrine (`self-sufficiency.md`) says never bounce back a task you *could* drive. This doc is its
complement: the small set of requests you correctly **don't** drive — and how to redirect instead of deflecting.

---

## The boundaries

| Request | Verdict | Why | Ref |
|---------|---------|-----|-----|
| Build a **Meta Ads audience** / segment / lookalike | ❌ Not our job | The MCP exposes metrics + contact data (`get_conversations`, `search_contacts`, custom properties). Building and pushing audiences into Meta Ads happens on the **client's** ad side — we surface the data, they build the audience. | NINJO-2038 |
| **Host or update a client's website** from the MCP | ❌ Not possible | Updating a hosted site would need the client's web-host credentials **in the model context** (credential leakage), and we don't own the deploy pipeline. We provide the metrics/content; the client builds and hosts their own site — even one Ninjo scaffolded for them is theirs to redeploy. | NINJO-2064 |
| Operate on **off-platform accounts** (e.g. "ninjolabs") | ❌ Out of scope | Every tool assumes a Ninjo-platform `influencer_id`. Accounts that don't live on the Ninjo platform aren't reachable and aren't ours to touch. | NINJO-1986, NINJO-1987 |
| A capability that **already exists** dressed as a feature request | ⊘ Already supported | Check the tool list first. "Delete two old agents" is `delete_agent`, not a new build. | NINJO-1987 |

---

## How to handle an out-of-scope request

1. **Name the boundary plainly.** "Updating a hosted website from here isn't possible — it would put your host credentials in the model context." Not a vague "no".
2. **Redirect to what we *do* provide.** Out of scope ≠ dead end: point at the adjacent thing we can do (export the metrics, give the contact list, hand over the data the client needs to build the audience/site themselves).
3. **Don't `report_feedback` it.** These aren't dev gaps — filing them just floods the queue with tickets that get canceled. Close/decline in place.
4. **If it's "already supported", just do it** (or show the tool). Don't escalate an existing capability as missing.

**Boundary vs. self-sufficiency — don't confuse them.** A tool that *errored* is a self-sufficiency problem (retry, diagnose, drive it — `self-sufficiency.md`). A request that's *out of scope* is this doc (name it, redirect, close). The tell: could a correctly-working tool + more effort complete it? If yes → self-sufficiency, keep going. If no capability exists at all, or someone else owns it → scope boundary, redirect.

---

## Cross-references

- **`knowledge/self-sufficiency.md`** — the complement: tasks you *must* drive rather than deflect.
- **`knowledge/feedback-reporting.md`** — when a request *is* a real dev gap worth `report_feedback` (vs. an out-of-scope ask, which is not).
- **`knowledge/keyword-playbook.md`** §5 — a delivery-layer example of the same idea: a platform lever that doesn't exist (splitting a keyword resource across messages) is not an actionable bug.
- **`knowledge/mcp-tool-reference.md`** — check here before declaring something impossible; the capability may already exist.