One read of Claude Documentationclaude-docs-20260814T092040Z

claude-tag/users/proactivity First recorded · 115 lines, first recorded

# Set up routines ## Set up standing work ### Scheduled jobs ### Watch channels ### Follow a pull request ## Routine recipes ### Daily standup summary ### Weekly channel digest ### Watch a pull request until it merges ### Alert investigation when a monitor fires ### Automatic triage for new requests ## Manage standing work ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Set up routines

> Claude Tag runs routines you set up from the channel. See scheduled jobs, channel watching, pull request subscriptions, paste-ready routine recipes, and how to list or pause standing work.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

You can give Claude standing work from any channel it's in. This standing work is called a routine: a job that runs on a schedule, such as watching a channel, following a pull request, or posting status updates. You set a routine up in the channel where it should run, and it uses that channel's connections with the same permissions as a typed request.

## Set up standing work

### Scheduled jobs

Describe the schedule you want and the work Claude should do in one message:

```text wrap theme={null}
@Claude every weekday at 9am, read the open threads in this channel, check the tickets and pull requests linked in them, and post a one-line status per item. Skip anything with a ✅ reaction.
```

Name the output format in the job so recurring posts stay scannable.

### Watch channels

Ask Claude to watch named channels and post here when something matches a topic:

```text wrap theme={null}
@Claude watch #product-announce, #eng-announce, and #design-announce. Once a day, post here if anything is relevant to user education. Skip days with nothing.
```

Naming both the channels and the topic is what keeps a watch useful. The watch can cover this channel too ("keep an eye on this channel and post a morning summary").

### Follow a pull request

Claude can subscribe to a single pull request and react when it updates.

```text wrap theme={null}
@Claude subscribe to PR #482 in acme/data-pipeline. When CI finishes or a review lands, post here, and tag me if anything failed.
```

## Routine recipes

Each recipe below sets up a complete routine with one message. Adapt the channel names, repositories, and times to your own, and name the timezone so the schedule fires when you expect.

### Daily standup summary

Claude posts a morning rollup of open threads and anything waiting on someone, before the team starts the day.

```text wrap theme={null}
@Claude every weekday at 9am Pacific, post a summary of open threads in this channel and anything that looks like it's waiting on someone.
```

"Waiting on someone" makes the rollup surface actions, not just a recap; [Catch up](/docs/claude-tag/users/use-cases/catch-up) has the one-off version.

### Weekly channel digest

Claude posts one recap at the end of each week, so the channel has a single place to see what happened.

```text wrap theme={null}
@Claude every Friday at 3pm Eastern, post a digest of this week in this channel: what got decided, what's still open, and anything waiting on someone.
```

For an intake channel, the [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) version of this rollup also sweeps posts that never tagged Claude.

### Watch a pull request until it merges

Claude subscribes to a single pull request and posts as it moves through CI, review, and merge.

```text wrap theme={null}
@Claude subscribe to PR #482 in acme/data-pipeline. Post here when CI finishes, a review lands, or it merges, and tag me if anything failed.
```

[Follow a pull request](#follow-a-pull-request) explains what the subscription reacts to.

### Alert investigation when a monitor fires

Claude checks the alerting dashboard on a schedule and posts a first pass at diagnosis for anything new, so the investigation is underway before anyone asks. This recipe needs a monitoring connection such as Datadog or PagerDuty; [Watch monitors and alerts](/docs/claude-tag/users/use-cases/watch-monitors) has the full setup.

```text wrap theme={null}
@Claude every two hours, check the alerting dashboard against its last state. For anything new, post when it started, what changed around then, and what to look at first.
```

The routine posts only when something changed, not on every check.

### Automatic triage for new requests

Claude answers, deduplicates, and routes requests as they arrive. This recipe is a standing role rather than a schedule; "remember for this channel" saves it to [channel memory](/docs/claude-tag/users/memory), so it applies to everyone's threads.

```text wrap theme={null}
@Claude remember for this channel: when someone tags you on a request, check whether it duplicates something already reported, answer it directly if the answer exists, and otherwise route it to the right owner with a one-line summary.
```

Pair it with a weekly rollup so untagged posts are still swept; [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) has both messages.

## Manage standing work

Anyone in the channel can list, edit, or disable its standing work:

* **List.** Ask "what routines do you have set up in this channel?", or send [`@Claude !routines`](/docs/claude-tag/users/commands#list-the-routines-in-a-channel). Add a channel mention or its ID, as in `@Claude !routines #other-channel`, to list another channel's routines; pick the channel from Slack's autocomplete so it lands as a real mention, since a typed name on its own isn't accepted.
* **Edit.** Describe the change and it updates the job
* **Disable.** Name the job to stop, as in "disable the Friday rollup"

Standing work is visible to the channel: jobs post into the channel they belong to. Routines keep running if their creator leaves the organization, but stop firing if the creator is removed from the channel.

A few boundaries apply:

* A job runs with the channel's connections, the same as an interactive request.
* Schedules default to UTC. When you say "every weekday at 9am," include the timezone (for example "9am Pacific") so Claude converts correctly; without one it may guess. Ask "what triggers do you have set up?" to confirm the time it actually scheduled.
* A scheduled job that touches a github.com repository uses the same GitHub connection your admin set up for interactive work. See [Configure GitHub access](/docs/claude-tag/admins/configure-github#scheduled-work-uses-the-same-connection).

## Related resources

* [Use case library](/docs/claude-tag/users/use-cases): every entry has a proactive form to copy
* [Prompt library](/docs/claude-tag/users/prompt-library#manage-routines): prompts to create, audit, and stop routines
* [Good habits](/docs/claude-tag/users/good-habits): write schedules that keep working

claude-tag/users/prompt-library First recorded · 161 lines, first recorded

# Prompt library ## First messages in a new channel ## Forward a message as a task ## Shape how the channel works ## Check and correct memory ## Manage routines ## Steer work mid-thread ## Task starters, by shape ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Prompt library

> Copy-paste prompts for Claude Tag in Slack, each with why it works. See first messages, forwarded-message handoffs, channel rules, memory checks, routines, and mid-thread steering.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

These prompts are ready to copy, paste, and adapt: swap in your own channel names, services, and repositories. Each comes with the reason it works, so you can keep the mechanism when you change the words.

## First messages in a new channel

Ask what Claude can access from this channel:

```text wrap theme={null}
@Claude what can you access from this channel?
```

**Why it works**: what Claude can do differs per channel, and without this grounding Claude may suggest tasks it can't do here.

Get a personalized starting point:

```text wrap theme={null}
@Claude learn what you can about my role from this workspace, then tell me three tasks you could take off my plate this week.
```

**Why it works**: it's a discovery task with a bounded output. By asking for three tasks, you get a list you can judge in ten seconds and reuse as a menu of next tasks.

Start with a low-stakes task:

```text wrap theme={null}
@Claude catch me up on this channel since Monday.
```

**Why it works**: you bound the task with "since Monday", and you can grade the result yourself because you were there.

## Forward a message as a task

To turn an existing Slack message into a task, for example a bug report or a request someone posted, forward it to a channel Claude is in. In the message you attach when forwarding, name the deliverable and say what Claude should do if it isn't possible. Claude reads the forwarded message, so you don't need to retype its contents.

```text wrap theme={null}
@Claude investigate this. If it's something we can fix, open a draft PR; if not, post who owns it and why it's theirs.
```

**Why it works**: by giving Claude both branches, you get a useful result whether or not a fix is possible.

To hand over a discussion too long to forward, paste the thread's link instead:

```text wrap theme={null}
@Claude read the thread linked below and take over the fix it describes. Post your plan here before changing anything.
```

**Why it works**: Claude works in the thread where you pasted the link, not in the thread you linked, so it uses this channel's connections and this channel can see the result. By asking Claude to post its plan first, you can redirect it before it starts. To read a linked thread in a public channel, Claude must be a member of that channel, and it can read a private channel's threads [only from inside that channel](/docs/claude-tag/users/good-habits#pick-the-right-surface). If Claude says it can't read the link, `/invite @Claude` in the linked public channel, or forward the messages instead.

## Shape how the channel works

Use the prompts below to set channel-wide behavior that applies to every thread, not just yours.

```text wrap theme={null}
@Claude remember for this channel: keep replies short, and always include a link to the source.
```

**Why it works**: you're explicitly telling Claude to save the rule. Claude usually doesn't keep preferences you mention in passing.

```text wrap theme={null}
@Claude stay quiet in this channel unless tagged.
```

**Why it works**: you're stating standing channel behavior, so Claude applies it beyond the current conversation.

```text wrap theme={null}
@Claude remember for this channel: treat every top-level post as a task and pick it up without waiting for a mention.
```

**Why it works**: Claude already [picks up untagged posts when it judges a reply is warranted](/docs/claude-tag/users/when-claude-responds), and it weighs this channel-memory rule in that judgment, so teammates don't have to remember to tag Claude on posts with a concrete ask. If you don't specify a need, or if a teammate has already claimed the task, Claude may not respond to the message. In [a channel where Claude has quieted itself](/docs/claude-tag/users/when-claude-responds#when-claude-quiets-itself), mention `@Claude` to turn unprompted pickup back on.

## Check and correct memory

```text wrap theme={null}
@Claude what do you remember about this channel?
```

**Why it works**: memory is a curated note and Claude decides what's worth keeping, so you have to ask to know what stuck.

```text wrap theme={null}
@Claude that's outdated — forget the entry about the old project name.
```

**Why it works**: you name the specific entry, so Claude doesn't have to guess what's stale the way it does with "clean up your memory".

```text wrap theme={null}
@Claude update your memory for this channel so this doesn't happen again.
```

**Why it works**: when you correct Claude in a thread, you fix that thread only. With this message, Claude saves the correction and applies it in everyone's future threads.

## Manage routines

Create, audit, and stop the scheduled jobs Claude runs in this channel. For paste-ready schedules by scenario, like a daily standup summary or a weekly digest, see [Routine recipes](/docs/claude-tag/users/proactivity#routine-recipes).

```text wrap theme={null}
@Claude every Friday at 3pm, post a summary of this week's requests: how many, top themes, and anything still unrouted.
```

**Why it works**: you name the schedule and the post's contents, so every week Claude posts the same shape and you can compare to last week. By asking for anything still unrouted, you get a sweep for dropped requests, not just a recap.

```text wrap theme={null}
@Claude what routines do you have set up in this channel?
```

**Why it works**: schedules are channel state, and someone else may have set them up. Check what exists before you create a duplicate digest.

```text wrap theme={null}
@Claude disable the daily digest job.
```

**Why it works**: you name which job. Any channel member can disable a scheduled job; you don't need to find an admin to stop a noisy routine.

## Steer work mid-thread

Reply in the same thread; once Claude is working there, you don't need to @-mention it again.

```text wrap theme={null}
Status check — what's done and what's left?
```

**Why it works**: you're replying into the session that's running the task, with full context. If you ask in a new thread instead, Claude starts a second session that knows nothing about the first.

```text wrap theme={null}
Change of plan: target the staging config instead, and post the diff here before applying anything.
```

**Why it works**: when you redirect in the thread, Claude keeps everything the session has already learned. By asking for the diff first, you and the channel can review the change before Claude applies it.

```text wrap theme={null}
Post the draft to the thread, or commit and push what you have, then keep going.
```

**Why it works**: the thread is durable but [the isolated workspace behind it isn't](/docs/claude-tag/concepts/how-it-works#what-survives-between-replies). Anything Claude posts to the thread or pushes to a branch survives idle recycling; files that exist only in that workspace don't.

## Task starters, by shape

Each entry in the use case library gets one starter here; the linked page has the full setup and the reasoning behind its prompts.

| To do this                                                                  | Paste this                                                                                                                                                                                                                                                   |
| :-------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Triage requests](/docs/claude-tag/users/use-cases/triage-requests)              | "remember for this channel: when someone tags you on a request, check whether it duplicates something already reported, answer it directly if the answer exists, and otherwise route it to the right owner with a one-line summary. Track recurring themes." |
| [Catch up](/docs/claude-tag/users/use-cases/catch-up)                            | "what got decided in this thread, and what's still open?"                                                                                                                                                                                                    |
| [Create an artifact](/docs/claude-tag/users/use-cases/create-artifacts)          | "turn this thread into a one-page decision doc"                                                                                                                                                                                                              |
| [Track a project](/docs/claude-tag/users/use-cases/track-projects)               | "where are we on the migration? What's blocked and on whom?"                                                                                                                                                                                                 |
| [Answer a data question](/docs/claude-tag/users/use-cases/answer-data-questions) | "show signup growth by week, and explain the dips discussed above"                                                                                                                                                                                           |
| [Find an answer in the docs](/docs/claude-tag/users/use-cases/find-answers)      | "what's our policy on data retention, and which doc says so?"                                                                                                                                                                                                |
| [Pull deal state](/docs/claude-tag/users/use-cases/pull-deal-state)              | "what's the state of the Acme renewal?"                                                                                                                                                                                                                      |
| [Watch monitors](/docs/claude-tag/users/use-cases/watch-monitors)                | "every morning at 7, check the dashboards and post one line per service"                                                                                                                                                                                     |
| [Fix a bug](/docs/claude-tag/users/use-cases/fix-bugs)                           | "in acme/data-pipeline, reproduce the bug in this thread, fix it, and open a draft PR"                                                                                                                                                                       |

## Related resources

* [Use case library](/docs/claude-tag/users/use-cases): the full setup behind each starter
* [Good habits](/docs/claude-tag/users/good-habits): the habits these prompts are built from
* [Getting started](/docs/claude-tag/users/getting-started): the basics, if you haven't sent a first message yet

claude-tag/users/troubleshooting First recorded · 595 lines, first recorded

# Troubleshoot Claude Tag in channels and DMs ## No response or silence ### Mentioning @Claude does nothing at all ### Claude replies to me but not to a teammate ### Claude reacted or started thinking, then never replied ### Claude says my session is queued or failed to start ### Claude didn't react to a message I edited ### Claude never responds in a channel shared with another company ### Couldn't check this channel just now ### Claude doesn't respond in channels that include guests ## Too many or wrong responses ### Claude gave me a confident but wrong answer ### Claude replies to every message in a thread ### I want to take back something I sent ### This conversation is too long for me to process ## Claude stopped mid-task ### I hit repeated API server errors and stopped after retrying ### I hit API rate limits and stopped after retrying ### This request needs usage credits that aren't available ### Claude couldn't clone a repository for this session ### I lost the connection to this session's container mid-turn ### Something went wrong and I couldn't finish this turn ## Lost or stale work ### Claude lost work it created earlier ### My old thread stopped working, but new threads are fine ### Claude picked the wrong repository ### Claude forgot instructions I gave it before ## Access and connections ### A connection my admin added isn't showing up ### Claude says it can't access a channel it read before ### Claude says it can't reach a tool or service ### A connector works on claude.ai but not in Slack ### Claude says it has no internet access or can't open a link ### Claude can't connect over SSH ### You've reached a Claude Tag spend limit ## DMs aren't working ### I get an environment error in a DM ### Your Claude account is connected, but it doesn't have access in this organization ### Your Claude admin has disabled sending direct messages to Claude ### Group DMs aren't supported ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Troubleshoot Claude Tag in channels and DMs

> Fixes for common Claude Tag problems in Slack. See no reply after a reaction, queued or failed sessions, lost work, missing connections, blocked links and websites, and DM or account errors.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

When something goes wrong mid-conversation, the cause is usually one of a small set. Each entry below has the same three parts: what you see, what it means, and how to resolve it. For setup and credential errors, see the [admin troubleshooting page](/docs/claude-tag/admins/troubleshooting).

Many fixes end with something to send your admin. On this page that means whoever manages your organization's Claude account at claude.ai, and it's often not the same person as your Slack administrator. If you don't know who that is, ask whoever set Claude up in your workspace.

## No response or silence

### Mentioning @Claude does nothing at all

**What you see**

`@Claude` gets no reaction and no reply.

**What it means**

Total silence has several possible causes, from the app not being installed to the channel being turned off, and the checks below separate them.

**How to resolve**

Work through these in order. Each step says what success looks like and where to go if it fails.

1. **Is the Claude app installed in this workspace?** Start typing `@Claude` in any channel. **Works**: Slack autocompletes to a Claude app with an app badge; if more than one Claude app appears, check with your admin which one to use. **Fails**: nothing autocompletes, or only a person named Claude appears. The app isn't installed; this needs your admin (send them the [setup overview](/docs/claude-tag/admins/setup-overview)).
2. **Is Claude in this channel?** Type `/invite @Claude` in the channel's message box, not in a thread reply. Slack rejects `/invite` inside threads ("/invite is not supported in threads. Sorry!"). **Works**: Slack posts "Claude was added to #channel" (or "is already in this channel"). Mention it again. **Fails**: Slack says you can't add apps to this channel (a Slack Connect or guest-restricted channel); try an internal channel instead.
3. **Is Claude Tag turned on for this channel?** Mention it again now that it's invited. **Works**: it reacts and replies. **Fails**: it replies "Claude is disabled in this channel" (the channel is set to **Off**), or it replies but behaves like the earlier Claude in Slack, with no channel memory and pull requests opening under your name rather than Claude's (the channel is set to **Legacy**). Either way this needs your admin (send them [Migrate from the earlier Claude in Slack](/docs/claude-tag/admins/restrict-access#migrate-from-the-earlier-claude-in-slack)).

If `@Claude` still gets no reaction and no reply after all three, send your admin [the admin entries for a silent workspace](/docs/claude-tag/admins/troubleshooting#nothing-responds). If the silence covers every channel across an Enterprise Grid, the fix needs a Slack organization admin rather than your Claude admin, so send the link to them.

### Claude replies to me but not to a teammate

**What you see**

Claude answers your mentions in a channel, and a teammate's mentions in the same channel get silence or a refusal.

**What it means**

Mentioning Claude in a channel doesn't require the sender to have a Claude account or seat, so by default anyone in the workspace can use it. Your organization can restrict that with the [member access setting](/docs/claude-tag/admins/restrict-access#members), in which case members outside the restriction are declined.

**How to resolve**

Have the teammate mention `@Claude` themselves and report the exact text of any reply; the reply is the diagnosis.

* No reaction and no reply at all: unusual when it works for you in the same channel; send your admin the exact channel and person.
* A message about guests: see [the guest entry below](#claude-doesn%E2%80%99t-respond-in-channels-that-include-guests).
* A message about permissions or access: your organization restricts who can use Claude; send your admin [the member access setting](/docs/claude-tag/admins/restrict-access#members).

### Claude reacted or started thinking, then never replied

**What you see**

Claude added a reaction to your message, or an "is thinking…" line appeared under it, but no reply arrived.

**What it means**

A reaction or an "is thinking…" line without a reply usually means Claude is still working, not that your message was dropped.

**How to resolve**

1. @-mention Claude in the same thread to ask for a status check.
2. If it has replied before in the thread, open the session from the link in its last message to watch live progress. Long tasks often show steady movement there while the Slack thread looks idle.
3. If the silence has stretched well past what the task should need, send [`@Claude !restart`](/docs/claude-tag/users/commands#restart-a-stuck-or-wrong-context-session) in the thread; it archives the session and starts a fresh one that still reads the thread. Starting a new thread and restating the request also works.

<Warning>Restarting abandons whatever the session was midway through, and there's no way to resume it. A silent session may still be working through a long task, so treat `!restart` as a last resort.</Warning>

### Claude says my session is queued or failed to start

**What you see**

Claude posts in the thread:

> Still waiting for available capacity — your request is queued and will start automatically. Replies in this thread are picked up automatically.

Or, if the session never started:

> Session failed to start: the session container never connected — please try again

**What it means**

The first message means compute capacity is temporarily busy; the session starts on its own once capacity frees up. The second means the session didn't start at all, which is transient.

**How to resolve**

* For the capacity message, wait a few minutes; no action is needed. To add context while waiting, @-mention Claude in the same thread rather than starting a new one. A new thread only queues a second session behind the first.
* For the failed-start message, mention Claude in the same thread to retry. If the retry worked, the session starts and Claude begins the task.

### Claude didn't react to a message I edited

**What you see**

You edited a sent message to add `@Claude`, and nothing happened.

**What it means**

Editing a sent message to add a mention doesn't trigger a response; Claude only picks up mentions from new messages.

**How to resolve**

Send a new message with the mention included.

### Claude never responds in a channel shared with another company

**What you see**

Mentions in a channel shared with another company get no reaction and no reply, ever.

**What it means**

Claude doesn't operate in Slack Connect channels, the ones shared with another company. This holds regardless of admin settings; mentions there are dropped without a reply. See [externally shared channels](/docs/claude-tag/admins/restrict-access#externally-shared-channels).

A channel shared across workspaces inside your Enterprise Grid isn't silent; what happens there depends on how those workspaces connect to Claude. When every workspace in the channel belongs to your one Claude organization, Claude answers, but with only your organization's default access and settings, so a repository or an instruction set up for that channel doesn't apply. A notice in the thread points this out from time to time. When the workspaces are connected to different Claude organizations, you see "This channel is shared among several Claude workspaces, so Claude cannot respond here" instead of an answer.

Where guest access is restricted, you may first see "This channel is shared across multiple workspaces, and Claude can't verify whether it includes guests, so Claude can't respond here." If you ask Claude from another conversation to act in one of these channels, such as posting a message there, you see a reply that ends "Claude isn't available in channels shared across your Enterprise Grid".

Each of these messages means the channel spans more than one workspace. The [admin entries on these messages](/docs/claude-tag/admins/troubleshooting#this-channel-is-shared-across-multiple-workspaces) explain what causes each one and what an admin can change.

**How to resolve**

Move the conversation to an internal channel that belongs to a single workspace, or to a DM, and mention Claude there.

### Couldn't check this channel just now

**What you see**

Claude replies in the channel:

> Couldn't check this channel just now. Please try again in a moment.

**What it means**

When your organization restricts Claude in channels that include guests (the default), Claude checks each channel for guests before replying. That check briefly failed, so Claude declined this reply rather than guess.

**How to resolve**

Mention Claude again; the check usually passes on retry. If the same channel hits this repeatedly, send your admin [the admin entry on this message](/docs/claude-tag/admins/troubleshooting#couldn%E2%80%99t-check-this-channel-just-now).

### Claude doesn't respond in channels that include guests

**What you see**

Claude replies in the channel:

> Claude doesn't respond in channels that include guests. You can remove the guests from this channel (Channel details -> Members -> filter by "guests"), or a claude.ai organization owner can allow it here.

**What it means**

The channel includes at least one Slack guest account, and your organization restricts Claude in channels that include guests (the default).

**How to resolve**

Any of these fixes works:

* Remove the guests from the channel. In Slack, open **Channel details** → **Members** and filter by "guests"; guests show a **guest** badge on their Slack profile.
* Move the conversation to a channel with no guests.
* Ask a claude.ai organization owner to allow Claude to respond in channels that include guests, and send them [the guest access setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels). If you don't know who your organization's owners are, ask whoever set Claude up in your workspace.

The guest access setting restores replies, not workspace search. Claude can't search the workspace from a channel that includes guests, even when it's allowed to respond there. Removing the guests or moving the conversation to a channel with no guests restores search as well.

If the fix worked, a mention in the channel gets a reply.

## Too many or wrong responses

### Claude gave me a confident but wrong answer

**What you see**

Claude answered with certainty, and the answer is wrong or incomplete.

**What it means**

Claude can be wrong, including when it sounds certain. The most common wrong answer in Slack is an incomplete one, where Claude queried one source or one date range and reported the result as if it were the whole picture.

**How to resolve**

Before you share or act on a result, check the source links it posted, and ask it to show its work ("which channels did you search?" or "show me the query you ran"). If the answer is wrong, say so in the same thread with the correct answer; correcting it there is also how you steer the next attempt.

For numbers and facts that matter, the [definition-of-done habit](/docs/claude-tag/users/good-habits#give-every-task-a-definition-of-done) helps. Make "include the source for every figure" or "show me the query" part of the ask.

### Claude replies to every message in a thread

**What you see**

Claude answers messages in the thread that weren't addressed to it.

**What it means**

Once Claude is mentioned in a thread, it follows the whole conversation there and may reply to messages that weren't addressed to it.

**How to resolve**

Reply in the thread with an instruction such as "only respond when I @-mention you"; Claude follows that instruction for the rest of the thread.

### I want to take back something I sent

**What you see**

You edited or deleted a message, and Claude still acts on the original.

**What it means**

Claude has already read the original. An edit reaches it as a new update in the thread, so it may or may not act on the change, and it never undoes work already in progress. A deleted reply doesn't reach Claude at all.

**How to resolve**

Say so in a new reply ("ignore that, do X instead"), or start a fresh thread for a clean session.

### This conversation is too long for me to process

**What you see**

Claude posts in the thread:

> This conversation is too long for me to process and I couldn't finish this turn — please start a new thread to continue.

In a DM it ends with "Click *New Chat* in the top right to start a fresh session" instead.

**What it means**

The thread has grown past what one session can hold, and it stays too long forever; retrying there can't work.

**How to resolve**

Start a new thread. You can paste a summary of where the previous one left off.

## Claude stopped mid-task

The messages in this section mean a session started and then stopped partway through. In most cases the work isn't lost, and the same thread picks up where it stopped. Each entry says whether anything needs redoing.

### I hit repeated API server errors and stopped after retrying

**What you see**

Claude posts in the thread:

> I hit repeated API server errors and stopped after retrying. Mention me to continue.

The related messages "I hit repeated 529 Overloaded errors (the API is at capacity) and stopped after retrying. Mention me to continue." and "The API request timed out and I stopped after retrying. Mention me to continue." behave the same way.

**What it means**

The API serving the session returned repeated errors, so Claude stopped rather than keep retrying. The work isn't lost.

**How to resolve**

Mention Claude in the same thread; it picks up where it stopped.

### I hit API rate limits and stopped after retrying

**What you see**

Claude posts in the thread:

> I hit API rate limits and stopped after retrying. Wait a moment, then mention me to continue.

**What it means**

The Claude API rate-limited your organization's traffic partway through the turn. The work isn't lost. Rate limits are about momentary request rate, not accumulated usage: a single task makes many API requests in short bursts, so this can appear on an organization's very first request. It isn't the channel spend limit, and it doesn't mean anything is misconfigured.

**How to resolve**

Wait a moment, then mention Claude in the same thread; it picks up where it stopped. If it recurs constantly across channels, the organization's sustained traffic is above its rate limits; an admin can stagger heavy use or contact their account team about limits.

If your message mentions a spend limit instead, that's a different problem; see [You've reached a Claude Tag spend limit](#you%E2%80%99ve-reached-a-claude-tag-spend-limit).

### This request needs usage credits that aren't available

**What you see**

Claude posts in the thread:

> This request needs usage credits that aren't available and I couldn't finish this turn. Enable or purchase usage credits in claude.ai, then mention me to retry.

**What it means**

Your organization's usage credit balance can't cover the request, so the turn stopped. The session is still there.

**How to resolve**

An admin enables or purchases usage credits in claude.ai for your organization. Once that's done, mention Claude in the same thread to retry (adding credits doesn't restart the work on its own). The retry continues with the thread's conversation and context. [What survives between replies](/docs/claude-tag/concepts/how-it-works#what-survives-between-replies) covers what else carries over.

### Claude couldn't clone a repository for this session

**What you see**

Claude posts in the thread:

> Claude couldn't clone a repository for this session. Mention Claude in this thread to retry.

**What it means**

The clone failed when the session started. A one-off failure is transient; the same repository failing every time usually means it isn't granted for this channel.

**How to resolve**

Mention Claude in the same thread to retry. If the same repository fails every time, send your admin [the GitHub access entry](/docs/claude-tag/admins/troubleshooting#github-doesn%E2%80%99t-work-in-this-channel).

Cut at 300 lines. The page has the rest.

claude-tag/users/use-cases First recorded · 50 lines, first recorded

# Use case library ## All use cases ## Use cases by connection ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Use case library

> Shapes of work teams hand Claude Tag in Slack, each with prompts to paste. See triage, catch-up, docs and tickets, project tracking, data, deals, monitoring, and bug fixes.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

Each use case below links to a page with prompts to paste, what it needs connected, and how to set it up to [run on a schedule or watch the channel](/docs/claude-tag/users/proactivity) instead of asking each time.

<Note>If `@Claude` doesn't autocomplete in your workspace, your admin hasn't enabled Claude Tag. Send them the [setup guide](/docs/claude-tag/admins/setup-overview).</Note>

## All use cases

| Use case                                                                             | Who it's for                                       | What Claude does                                                                                                        | Connections needed                                                                                                  |
| :----------------------------------------------------------------------------------- | :------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------ |
| [Catch up](/docs/claude-tag/users/use-cases/catch-up)                                     | Anyone                                             | Summarizes a thread, a channel, or what's waiting on you                                                                | Nothing                                                                                                             |
| [Work from your own channel](/docs/claude-tag/users/use-cases/your-own-channel)           | Anyone                                             | Answers scratch questions, digests channels you don't follow, and chases what you said you'd do                         | Nothing (issue tracker or GitHub optional)                                                                          |
| [Triage requests](/docs/claude-tag/users/use-cases/triage-requests)                       | Support, ops, IT, any intake channel               | Answers what it can, flags duplicates, routes the rest, rolls up themes                                                 | Nothing (issue tracker optional for filing)                                                                         |
| [Turn threads into docs and tickets](/docs/claude-tag/users/use-cases/create-artifacts)   | Anyone                                             | Produces a decision doc, status memo, ticket, send-ready reply, or hosted web page from a discussion                    | Nothing (Drive or issue tracker optional)                                                                           |
| [Track projects and chase approvals](/docs/claude-tag/users/use-cases/track-projects)     | PMs, leads, anyone running a project channel       | Posts standing status digests; follows up on stalled sign-offs                                                          | Nothing (issue tracker optional)                                                                                    |
| [Find answers in your docs](/docs/claude-tag/users/use-cases/find-answers)                | Anyone                                             | Looks up policies, runbooks, prior decisions; replies with the source                                                   | Google Drive, Notion, or Confluence                                                                                 |
| [Review documents against a checklist](/docs/claude-tag/users/use-cases/review-documents) | Ops, compliance, anyone reviewing against criteria | Checks documents in a connected tool against a checklist or policy; posts findings per item                             | Google Drive, Notion, or Confluence                                                                                 |
| [Answer data questions](/docs/claude-tag/users/use-cases/answer-data-questions)           | Analysts, data-adjacent teams                      | Runs warehouse queries, returns charts; or charts from Slack history alone                                              | BigQuery, Snowflake, or Redshift (charts from Slack need none)                                                      |
| [Fix bugs](/docs/claude-tag/users/use-cases/fix-bugs)                                     | Engineering                                        | Reproduces the bug, opens a draft PR, follows CI to green                                                               | GitHub (Datadog, Sentry optional)                                                                                   |
| [Work with GitHub](/docs/claude-tag/users/use-cases/work-with-github)                     | Engineering, anyone with repository questions      | Answers repository questions in-thread, watches pull requests for you, turns postponed chores into draft PRs            | GitHub                                                                                                              |
| [Watch monitors and alerts](/docs/claude-tag/users/use-cases/watch-monitors)              | On-call, SRE                                       | Checks dashboards on a schedule; investigates alerts before anyone asks                                                 | Datadog, Sentry, or PagerDuty                                                                                       |
| [Pull deal and account state](/docs/claude-tag/users/use-cases/pull-deal-state)           | Sales, customer success                            | Answers account questions in-thread; pre-call briefs; weekly pipeline digest                                            | Salesforce, HubSpot, or Gong                                                                                        |
| [Claude Tag for marketing teams](/docs/claude-tag/users/use-cases/marketing-team)         | Marketing                                          | Answers policy questions from team docs, drafts from campaign threads, checks lead state, posts a weekly metrics digest | HubSpot or Salesforce, plus Google Drive or Notion; BigQuery or Snowflake for the metrics digest (varies by recipe) |

## Use cases by connection

A connection is a tool an admin linked for the channel. Each one adds a category of work; ask `@Claude what can you access from this channel?` to see which your channel has.

| Connection         | Examples                         | What it adds                                                                                                                            |
| :----------------- | :------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------- |
| Knowledge and docs | Google Drive, Notion, Confluence | [Find answers in your docs](/docs/claude-tag/users/use-cases/find-answers)                                                                   |
| Issue tracking     | Linear, Jira, Asana              | [Turn threads into tickets](/docs/claude-tag/users/use-cases/create-artifacts), [track projects](/docs/claude-tag/users/use-cases/track-projects) |
| Data warehouse     | BigQuery, Snowflake              | [Answer data questions](/docs/claude-tag/users/use-cases/answer-data-questions) with charts                                                  |
| Go-to-market       | Salesforce, HubSpot, Gong        | [Pull deal and account state](/docs/claude-tag/users/use-cases/pull-deal-state)                                                              |
| Monitoring         | Datadog, Sentry, PagerDuty       | [Watch monitors and alerts](/docs/claude-tag/users/use-cases/watch-monitors)                                                                 |
| Code               | GitHub                           | [Fix bugs](/docs/claude-tag/users/use-cases/fix-bugs), open pull requests, follow CI                                                         |

If a connection your work needs is missing, an admin can [add it](/docs/claude-tag/admins/add-connections).

## Related resources

* [Prompt library](/docs/claude-tag/users/prompt-library): the prompts from every entry, plus the operational ones, on one page
* [Good habits](/docs/claude-tag/users/good-habits): make any of these reliable
* [Set up routines](/docs/claude-tag/users/proactivity): turn any entry into a scheduled job

claude-tag/users/use-cases/answer-data-questions First recorded · 63 lines, first recorded

# Answer data questions ## How data-question prompts work ## Check the channel's connections ## Prompts to paste ### Chart a metric on demand ### Schedule a recurring metrics report ### Chart from Slack alone ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Answer data questions

> Claude Tag answers data questions in the Slack thread. See warehouse queries with charts, scheduled metric reports, and charts built from channel history alone.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How data-question prompts work

This page is for teams who answer questions from a data warehouse (the database where your analytics tables live, like BigQuery or Snowflake). These prompts turn a question asked in Slack into a query and a chart.

Each prompt below is a Slack message. You paste it in the channel where the metrics get discussed, Claude queries the warehouse or reads the channel history and posts progress in that thread, and the result lands there too. The result is a chart with a short answer, returned once or on a schedule depending on the prompt.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection     | Examples            | Why it matters here                          |
| :------------- | :------------------ | :------------------------------------------- |
| Data warehouse | BigQuery, Snowflake | Required. Runs the queries behind each chart |

## Prompts to paste

### Chart a metric on demand

The thread is debating something a number would settle. Ask in the channel where the metrics get discussed.

```text wrap theme={null}
@Claude show signup growth by week for the last quarter, and explain the two dips people were debating above.
```

### Schedule a recurring metrics report

When the team checks the same numbers every morning, schedule the post. One message sets up the recurring report.

```text wrap theme={null}
@Claude every morning at 8, post yesterday's key metrics as a chart with a two-line summary of anything unusual.
```

Naming the format, here a chart plus two lines, keeps a recurring post scannable instead of letting it grow each day. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

### Chart from Slack alone

Charts don't require a connection, because channel history is data. It can chart request volume in a triage channel, or how long requests waited for a first reply.

```text wrap theme={null}
@Claude chart the volume of requests in this channel by week, and how long each waited for a first reply.
```

Anyone in the thread can ask for a different cut of the same data.

## Related resources

<CardGroup cols={2}>
  <Card title="Watch monitors and alerts" href="/docs/claude-tag/users/use-cases/watch-monitors" horizontal arrow>
    When the question is about systems, not metrics
  </Card>

  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    Recurring reports
  </Card>
</CardGroup>

claude-tag/users/use-cases/catch-up First recorded · 57 lines, first recorded

# Catch up ## How catch-up prompts work ## Check the channel's connections ## Prompts to paste ### Get a one-off recap ### Schedule a daily recap ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Catch up

> Claude Tag summarizes Slack threads and channels on demand. See one-off recaps, a scheduled morning rollup of open threads, and what's waiting on you.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How catch-up prompts work

Each prompt below is a Slack message. You paste it in any channel Claude is in, Claude reads the channel or thread history and posts progress in that thread, and the recap lands there too. The result is always a summary of what was said, returned once or every morning depending on the prompt.

## Check the channel's connections

This use case needs no connections; it works on Slack history alone. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

## Prompts to paste

### Get a one-off recap

A thread ran to forty replies overnight, or you skipped a channel for a week. Ask for the catch-up you need.

```text wrap theme={null}
@Claude catch me up on this channel since Monday.
```

```text wrap theme={null}
@Claude what got decided in this thread, and what's still open?
```

```text wrap theme={null}
@Claude summarize what I missed last week, grouped by topic.
```

Each of these bounds the work with a time window, one thread, or a grouping, so the summary comes back in a shape you can check.

### Schedule a daily recap

If the first stretch of every morning goes to re-reading channels, schedule the recap instead. One message sets up a rollup that posts before you start the day.

```text wrap theme={null}
@Claude every weekday at 9am, post a summary of open threads in this channel and anything that looks like it's waiting on someone.
```

"Waiting on someone" makes the rollup surface actions, not just a recap of yesterday. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

## Related resources

<CardGroup cols={2}>
  <Card title="Turn threads into docs and tickets" href="/docs/claude-tag/users/use-cases/create-artifacts" horizontal arrow>
    When the catch-up should become an artifact
  </Card>

  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    Scheduling and triggers
  </Card>
</CardGroup>

claude-tag/users/use-cases/create-artifacts First recorded · 72 lines, first recorded

# Turn threads into docs and tickets ## How artifact prompts work ## Check the channel's connections ## Prompts to paste ### Draft from one thread ### Ask for a hosted page ### Keep a capture channel ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Turn threads into docs and tickets

> Claude Tag turns a Slack discussion into the artifact you name. See replies you can send, decision docs, status memos, filed tickets, hosted web pages, and a capture-channel pattern.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How artifact prompts work

An artifact here is a generated document, page, chart, or file Claude posts or links in the thread for the team to use, as opposed to a chat reply.

Each prompt below is a Slack message. You paste it in the thread or channel you want turned into something, Claude reads the discussion and posts progress in that thread, and the draft lands there too. What the draft is depends on the prompt, and each one below names the artifact it returns, like a decision doc, a customer reply, a filed ticket, a planning outline, or a hosted web page.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection     | Examples            | Why it matters here                    |
| :------------- | :------------------ | :------------------------------------- |
| None           | —                   | Works on Slack content alone           |
| Issue tracking | Linear, Jira, Asana | Optional. Files tickets from the draft |

## Prompts to paste

### Draft from one thread

The thread settled the question, and what's missing is the doc, the customer reply, or the ticket. Name the artifact in the thread where the discussion happened.

```text wrap theme={null}
@Claude turn this thread into a one-page decision doc: what we decided, the options we rejected, and why.
```

```text wrap theme={null}
@Claude draft a reply I can send to the customer based on this discussion. Keep it under 150 words.
```

```text wrap theme={null}
@Claude file this thread as a ticket, assign it to the owner we discussed above, and post the link here.
```

Name the format and the length; "a doc" gets you a guess, "a one-pager with a decision section" gets you the artifact.

### Ask for a hosted page

When the deliverable is a page people open, like a dashboard or a status page, ask for one. Claude publishes it as a web page hosted on claude.ai, posts the link in the thread, and updates it when you ask in the same thread.

```text wrap theme={null}
@Claude build a status page from the open items in this channel and post the link here.
```

Anyone with access to this channel can open the page; [artifact visibility](/docs/claude-tag/concepts/security-and-data#artifact-visibility) covers the access model.

### Keep a capture channel

Planning inputs arrive over a month, not in one sitting. Forward messages and ideas to one channel as you find them, then ask for a synthesis when you need the artifact.

```text wrap theme={null}
@Claude go through everything posted in this channel this month and synthesize it into an outline for the planning doc.
```

## Related resources

<CardGroup cols={2}>
  <Card title="Catch up" href="/docs/claude-tag/users/use-cases/catch-up" horizontal arrow>
    When you need the summary, not the artifact
  </Card>

  <Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
    How to specify outputs that come back right
  </Card>
</CardGroup>

claude-tag/users/use-cases/find-answers First recorded · 71 lines, first recorded

# Find answers in your docs ## How answer-finding prompts work ## Check the channel's connections ## Prompts to paste ### Look up a policy ### Check a named document ### Find the latest version ### Answer from the channel alone ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Find answers in your docs

> Claude Tag finds answers in connected docs and replies in the thread. See policy lookups, runbook checks, prior decisions, and answers from the Slack channel alone.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How answer-finding prompts work

Each prompt below is a Slack message. You paste it in the channel where the question came up, Claude searches the connected docs or the channel history and posts progress in that thread, and the answer lands there too. The result is always an answer with the source it came from, so you can open what it read.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection         | Examples                         | Why it matters here                                                                                             |
| :----------------- | :------------------------------- | :-------------------------------------------------------------------------------------------------------------- |
| Knowledge and docs | Google Drive, Notion, Confluence | Required to search those sources; channel-history-only answers need none. Searches the docs the answers live in |

## Prompts to paste

### Look up a policy

A customer asks about data retention and you need the policy, not a recollection. Ask where the question comes up.

```text wrap theme={null}
@Claude what's our policy on data retention, and which doc says so?
```

Asking for the doc keeps the answer checkable, since you can open what it read.

### Check a named document

Launch is close and you need to know whether the plan covers the EU rollout, without re-reading it. Point it at the document and the question.

```text wrap theme={null}
@Claude does the launch plan cover the EU rollout? Quote the relevant section if it's there.
```

"Quote the relevant section" turns a yes/no into evidence.

### Find the latest version

The pricing deck gets recreated every quarter, and the link you saved is two versions old. Ask for the current one.

```text wrap theme={null}
@Claude find the latest pricing deck and post where it lives.
```

### Answer from the channel alone

Without any connection, Claude can still answer from the channel's own history.

```text wrap theme={null}
@Claude what did this channel decide about the retention policy, and when?
```

Answers come from this channel's history and [memory](/docs/claude-tag/users/memory).

## Related resources

<CardGroup cols={2}>
  <Card title="Catch up" href="/docs/claude-tag/users/use-cases/catch-up" horizontal arrow>
    The same mechanism pointed at "what did I miss"
  </Card>

  <Card title="What Claude Tag remembers" href="/docs/claude-tag/users/memory" horizontal arrow>
    How channel knowledge accumulates
  </Card>
</CardGroup>

claude-tag/users/use-cases/fix-bugs First recorded · 79 lines, first recorded

# Fix bugs ## How bug-fix prompts work ## Check the channel's connections ## Prompts to paste ### Fix a reported bug ### Watch a bug channel ### Diagnose a failure without a fix ### See a pull request through CI ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Fix bugs

> Claude Tag takes a bug report from Slack to a draft pull request. See reproducing the issue, watching a bug channel, root-cause digs, and following CI to green.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How bug-fix prompts work

This page is for engineering teams. A pull request is a proposed code change opened for review; Claude opens them under its own GitHub identity, so they appear in your review queue like any other pull request.

Each prompt below is a Slack message. You paste it in the channel or thread where the bug lives, Claude works on it in an isolated workspace Anthropic hosts and posts progress in that thread, and the result lands there too. What the result is depends on the prompt, and each one below says what it returns, like a draft pull request, a root-cause writeup, or a standing watch that triages new reports as they arrive. Anything it opens on GitHub is authored by the Claude GitHub App.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection | Examples | Why it matters here                                    |
| :--------- | :------- | :----------------------------------------------------- |
| Code       | GitHub   | Required. Reads the repo and opens draft pull requests |

## Prompts to paste

### Fix a reported bug

A bug report arrives with reproduction steps and nobody free to take it. This gets you a draft pull request with the fix, linked back to the thread. Name the repository in the prompt so it's cloned before work starts.

```text wrap theme={null}
@Claude in acme/data-pipeline, reproduce the bug in this thread, fix it, and open a draft PR. Done means CI is green and the PR links back here.
```

The done definition, CI green and the PR linking back, gives the session a finish line it can check itself against.

The pull request appears under the Claude GitHub App and links back to the Slack thread it came from. See [how agent identity works](/docs/claude-tag/concepts/agent-identity#agent-access).

### Watch a bug channel

Reports arrive faster than the team triages them. The standing form watches the channel and opens drafts for anything reproducible.

```text wrap theme={null}
@Claude when a bug report lands in this channel, try to reproduce it. If you can, open a draft PR and tag the area owner; if you can't, reply with what you tried.
```

With the if/can't branch, every report gets a reply, either a draft or a list of what was tried. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

### Diagnose a failure without a fix

Not every failure needs a pull request. Ask for the diagnosis alone, and the decision about what to do with it stays with the team.

```text wrap theme={null}
@Claude why is this failing? Trace it to a cause and post what you find — diagnosis only, no fix.
```

Naming the deliverable, a cause rather than a patch, keeps the session from jumping ahead to code changes nobody asked for.

### See a pull request through CI

Once a pull request exists, one Claude opened or one a person did, Claude can watch it instead of you refreshing the page. It subscribes to that pull request and posts when CI status changes.

```text wrap theme={null}
@Claude watch PR #482 in acme/data-pipeline. When CI finishes, post the result here, and tag me if anything failed.
```

"Tag me if anything failed" is the filter. Green runs land quietly in the thread, and only a failure interrupts you.

For repository conventions that should hold across every session that touches the code, like where files go or what a pull request must include, see [Make repo conventions stick](/docs/claude-tag/users/good-habits#teach-claude-something-that-sticks).

## Related resources

<CardGroup cols={2}>
  <Card title="Watch monitors and alerts" href="/docs/claude-tag/users/use-cases/watch-monitors" horizontal arrow>
    Catching the problem before the bug report
  </Card>

  <Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
    Definitions of done for code tasks
  </Card>
</CardGroup>

claude-tag/users/use-cases/marketing-team First recorded · 116 lines, first recorded

# Claude Tag for marketing teams ## How marketing prompts work ## Check the channel's connections ## Prompts to paste ### Answer policy questions in an intake channel ### Recap a campaign channel and draft from it ### Check lead and campaign state in the CRM ### Schedule a weekly campaign metrics digest ### Save brand voice rules to channel memory ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Claude Tag for marketing teams

> Claude Tag recipes for marketing teams in Slack. See policy answers in an intake channel, campaign channel recaps and send-ready drafts, lead and campaign state from the CRM, a weekly metrics digest, and brand voice rules saved to channel memory.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How marketing prompts work

This page is for marketing teams. The recipes below run in the channels where marketing work already happens, like an intake channel where other teams post requests, a campaign channel during a launch, and the channel where lead numbers get discussed.

Each prompt below is a Slack message. You paste it in the channel where that work lives, Claude posts progress in that thread, and the result lands there too. What you get depends on the prompt, and each recipe names it, like an answer with the doc it came from, a channel recap, a send-ready draft, a list of CRM records, or a scheduled digest.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing. Each recipe below names the connection it uses.

| Connection         | Examples                         | Why it matters here                                                      |
| :----------------- | :------------------------------- | :----------------------------------------------------------------------- |
| None               | —                                | Recaps, drafts, and brand voice rules work on Slack content alone        |
| Knowledge and docs | Google Drive, Notion, Confluence | Answers policy and process questions from the docs where they're written |
| Go-to-market       | HubSpot, Salesforce              | Reads CRM records, like contacts, leads, and deals                       |
| Data warehouse     | BigQuery, Snowflake              | Runs the queries behind the metrics digest                               |

## Prompts to paste

### Answer policy questions in an intake channel

Other teams bring marketing their process questions, like whether the company can sponsor an event, who approves a use of the logo, and who owns customer stories. When the answers are written in the team's connected docs, Claude can answer each request in the thread where it was asked.

```text wrap theme={null}
@Claude a vendor asked us to sponsor their conference. What's our sponsorship policy, and which doc says so?
```

Asking for the doc keeps the answer checkable, since you can open what it read.

To answer requests as they arrive instead of prompting each time, give the channel a standing role:

```text wrap theme={null}
@Claude remember for this channel: when someone tags you on a request, answer it from the brand guidelines and the marketing process docs, name the doc you used, and route anything the docs don't cover to the right owner with a one-line summary.
```

"Remember for this channel" saves the role to [channel memory](/docs/claude-tag/users/memory), so it applies to everyone's threads, not just yours. [Triage requests](/docs/claude-tag/users/use-cases/triage-requests) adds a weekly rollup that also sweeps posts that never tagged Claude.

Some questions have no doc to cite, and a person on the team answers in the thread. When that answer will come up again, tell Claude to save it:

```text wrap theme={null}
@Claude remember for this channel: conference sponsorships are capped at $5,000, and the events lead approves each one.
```

The next person who asks gets the answer from channel memory instead of waiting for the team. When the policy changes, ask `@Claude what do you remember about this channel?` and tell it to update the entry.

### Recap a campaign channel and draft from it

During a launch, a campaign channel fills with decisions, status updates, and copy changes faster than anyone can read them all. Ask for a recap bounded by a time window, and when a thread settles what an announcement should say, ask for the draft in that thread.

```text wrap theme={null}
@Claude catch me up on this channel since Monday: what got decided, what's still open, and anything waiting on marketing.
```

The time window bounds the recap, so it comes back in a shape you can check.

```text wrap theme={null}
@Claude turn this thread into an announcement draft I can send to the customer list. Keep it under 200 words and match the messaging doc linked above.
```

Name the format, the length, and the source the draft should match. The same prompt shape produces a decision doc or a status memo; [Turn threads into docs and tickets](/docs/claude-tag/users/use-cases/create-artifacts) lists the variants.

### Check lead and campaign state in the CRM

A lead is a prospect record in a CRM like HubSpot or Salesforce, created when someone responds to a campaign. When the channel is debating whether a campaign's leads are moving, ask the question against those records.

```text wrap theme={null}
@Claude which leads from last month's webinar campaign still have no owner, and how long has each been waiting?
```

Asking how long each has waited tells you which lead to chase first.

```text wrap theme={null}
@Claude compare the leads the June campaign created against the ones that reached a queue, and post which ones stalled and at what stage.
```

The reply lists the stalled records and the stage where each stopped. The [HubSpot connection](/docs/claude-tag/admins/connections/hubspot) is created with read scopes, so prompts in this channel pull records and don't change them. For account questions, pre-call briefs, and a pipeline digest, see [Pull deal and account state](/docs/claude-tag/users/use-cases/pull-deal-state).

### Schedule a weekly campaign metrics digest

When the team checks the same campaign numbers at the start of every week, schedule the post instead of asking each time. One message sets up the recurring report, and it needs a data warehouse connection to run the queries.

```text wrap theme={null}
@Claude every Monday at 9am Eastern, post last week's campaign metrics as a chart: signups by campaign, week-over-week change, and a two-line note on anything unusual.
```

Naming the timezone matters, since schedules default to UTC. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

### Save brand voice rules to channel memory

Claude follows the tone and terminology rules saved to a channel's memory, so a rule saved once applies to every later draft in that channel.

```text wrap theme={null}
@Claude remember for this channel: headlines use sentence case, "sign up" is the verb and "signup" is the noun, and the product is never called a platform.
```

Keep saved entries short, since long entries crowd out everything else. For a full style guide, link the document in the channel or store it in a connected tool Claude can read, instead of re-describing its contents in memory. [What Claude Tag remembers](/docs/claude-tag/users/memory) covers how to check and correct what's saved.

## Related resources

<CardGroup cols={2}>
  <Card title="Pull deal and account state" href="/docs/claude-tag/users/use-cases/pull-deal-state" horizontal arrow>
    The full set of go-to-market prompts
  </Card>

  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    How the scheduled digest runs, and more recipes
  </Card>
</CardGroup>

claude-tag/users/use-cases/pull-deal-state First recorded · 71 lines, first recorded

# Pull deal and account state ## How deal-state prompts work ## Check the channel's connections ## Prompts to paste ### Check one account's state ### Find stalled deals ### Get a pre-call brief ### Schedule a weekly digest ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Pull deal and account state

> Claude Tag pulls account and deal state into the Slack channel. See in-thread account answers, pre-call briefs, and a scheduled weekly pipeline digest.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How deal-state prompts work

This page is for sales and customer-success teams. A deal (also called an opportunity) is a sales prospect tracked in a CRM like Salesforce or HubSpot; an account is a customer record. These prompts pull that state into the Slack channel where the team discusses it.

Each prompt below is a Slack message. You paste it in the account or deal channel, Claude pulls from the connected CRM and the channel discussion and posts progress in that thread, and the result is posted in that thread. What you get depends on the prompt, and each one below names it, like one account's state, a pre-call brief, or a scheduled pipeline digest.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection   | Examples                  | Why it matters here                      |
| :----------- | :------------------------ | :--------------------------------------- |
| Go-to-market | Salesforce, HubSpot, Gong | Required. Pulls account and deal records |

## Prompts to paste

### Check one account's state

The reply lists last activity, open items, and who owns the next step for the named account.

```text wrap theme={null}
@Claude what's the state of the Acme renewal? Last activity, open items, and who owns the next step.
```

### Find stalled deals

The reply lists deals stuck at the named stage and how long each has been there.

```text wrap theme={null}
@Claude which deals are stuck in stage 3, and how long has each been there?
```

"How long has each been there" is the actionable half. Aging tells you which deal to work first.

### Get a pre-call brief

The brief pairs what's in the system with what was discussed in the channel.

```text wrap theme={null}
@Claude brief me on Initech before my 2pm: account history, recent activity, and anything discussed in this channel lately.
```

### Schedule a weekly digest

One message sets up a standing digest posted to the team channel every Monday.

```text wrap theme={null}
@Claude every Monday at 9am, post a pipeline digest: deals that moved stage last week, deals stalled more than two weeks, and renewals due in the next 30 days.
```

The three lines cover what moved, what's stuck, and what's coming due, so the digest reads the same way every Monday. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

## Related resources

<CardGroup cols={2}>
  <Card title="Answer data questions" href="/docs/claude-tag/users/use-cases/answer-data-questions" horizontal arrow>
    When the question is metrics, not accounts
  </Card>

  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    Scheduled digests
  </Card>
</CardGroup>

claude-tag/users/use-cases/review-documents First recorded · 89 lines, first recorded

# Review documents against a checklist ## How document-review prompts work ## Check the channel's connections ## Prompts to paste ### Review one document against a checklist ### Review a batch against a policy ### Work through a filing list ### Compare with the last review ### Schedule a recurring review ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Review documents against a checklist

> Claude Tag reviews documents in a connected tool against a checklist or policy and posts findings in the thread. See single-document checks, batch reviews, filing lists, comparisons with past reviews, and a scheduled weekly sweep.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How document-review prompts work

Each prompt below is a Slack message. You paste it in the channel where the review belongs, Claude reads the documents and the criteria from the connected tool and posts progress in that thread, and the findings land there too. The criteria can be whatever your team already uses, like a checklist, a policy document, or a filing list.

Read the findings before you act on them, in proportion to what's at stake. If a finding needs checking, ask Claude to show its work in the same thread.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection         | Examples                         | Why it matters here                                                                                                      |
| :----------------- | :------------------------------- | :----------------------------------------------------------------------------------------------------------------------- |
| Knowledge and docs | Google Drive, Notion, Confluence | Required. Claude reads the documents under review, and the checklist or policy they're checked against, from these tools |

Claude can reach only what the connected account can see in that tool. If a document is missing from a review, ask an admin to [share it with the connected account](/docs/claude-tag/admins/add-connections#limit-access-to-specific-resources).

## Prompts to paste

### Review one document against a checklist

A draft is ready to go out, and it has to pass the team's checklist first. Name the document and the checklist in the channel where the review is happening.

```text wrap theme={null}
@Claude review the launch announcement doc against the review checklist, and post one finding per item: met, not met, or unclear, plus the section you based each call on.
```

Asking for the section keeps each finding checkable, since you can open what it read.

### Review a batch against a policy

A quarter's worth of vendor documents landed in one folder, and each needs the same check. Name the folder and the policy.

```text wrap theme={null}
@Claude go through each document in the vendor-docs folder and check it against the data-handling policy. Post a table with one row per document: what it covers, what's missing, and anything unclear.
```

One row per document bounds the work, so the review comes back in a shape you can check.

### Work through a filing list

Your team keeps a list of filings to check, and each item needs a verdict by the end of the week. Point Claude at the list and where the filings live.

```text wrap theme={null}
@Claude work through this week's filing list in the shared folder. For each item, find the matching filing, check it against the list's criteria, and post its status and what's missing.
```

Naming both the list and the folder scopes the search to the documents that matter.

### Compare with the last review

A revised draft is in, and you need to know whether it fixes what the last review flagged.

```text wrap theme={null}
@Claude review the updated vendor agreement against the checklist, then compare with what the review in this channel found last month and post what changed.
```

Naming the timeframe matters, since Claude looks back by listing this channel's earlier sessions and reading them.

### Schedule a recurring review

New documents arrive every week, and the same check applies to each. Schedule the review instead of asking each time.

```text wrap theme={null}
@Claude every Monday at 9am Pacific, check the shared folder for documents added in the past week, review each against the review checklist, and post the findings here.
```

Including the timezone matters, since schedules default to UTC. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

Keep the checklist as a document Claude can read, in the connected tool or linked in the channel, rather than re-describing its contents in [channel memory](/docs/claude-tag/users/memory).

## Related resources

<CardGroup cols={2}>
  <Card title="Find answers in your docs" href="/docs/claude-tag/users/use-cases/find-answers" horizontal arrow>
    The same connections pointed at a single question
  </Card>

  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    How the recurring review runs on a schedule
  </Card>
</CardGroup>

claude-tag/users/use-cases/track-projects First recorded · 68 lines, first recorded

# Track projects and chase approvals ## How project-tracking prompts work ## Check the channel's connections ## Prompts to paste ### Get a one-time status update ### Schedule a daily project digest ### Chase an approval ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Track projects and chase approvals

> Claude Tag posts project digests no one has to compile. See standing status updates and follow-ups on contracts, design reviews, and pull requests until they close.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How project-tracking prompts work

This page is for anyone running a project from a Slack channel: pulling status, chasing approvals, and posting digests so the team doesn't have to ask.

Each prompt below is a Slack message. You paste it in the project channel, Claude reads channel history and any connected trackers and posts progress and the result in that thread. What you get depends on the prompt, and each one below names it, like a one-time status digest, a scheduled daily digest, or a follow-up that runs until an approval lands.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection     | Examples            | Why it matters here                                                                         |
| :------------- | :------------------ | :------------------------------------------------------------------------------------------ |
| Issue tracking | Linear, Jira, Asana | Optional. Adds tracker state to digests; without it, digests draw from channel history only |
| Code           | GitHub              | Optional. Checks PR and review state                                                        |

## Prompts to paste

### Get a one-time status update

The reply pulls status spread across days of channel scroll into one digest. Ask in the project channel.

```text wrap theme={null}
@Claude where are we on the migration? What's blocked and on whom?
```

The digest comes back in the thread with what moved, what's blocked, and on whom, built from channel history plus any connected trackers.

### Schedule a daily project digest

One message sets up a digest that posts every weekday.

```text wrap theme={null}
@Claude every weekday at 5pm, post a project digest: what moved today, what's blocked, and what hasn't been touched in three days.
```

Name the format in the prompt, like the three sections here, so every digest comes back in the same readable shape. "Hasn't been touched in three days" is a number, so stalled work surfaces itself instead of depending on someone's sense of what counts as stale. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

### Chase an approval

A contract sits with legal, a design review has no comments, a pull request waits on a reviewer. Claude can follow any of them until they close. It nudges when the review stalls and posts when the state changes.

```text wrap theme={null}
@Claude every weekday, check the design review discussed in this thread. If it's gone two weekdays with no reviewer reply, nudge them here; when an approval lands, post that it's done. Done means approved, not just commented on.
```

Define what "done" includes; see [the babysit caution](/docs/claude-tag/users/good-habits#give-every-task-a-definition-of-done).

Code approvals need the code connection. Scheduled follow-ups on repositories use that same GitHub connection, with nothing extra to set up.

## Related resources

<CardGroup cols={2}>
  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    Schedules and event triggers
  </Card>

  <Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
    Definitions of done that close threads
  </Card>
</CardGroup>

claude-tag/users/use-cases/triage-requests First recorded · 58 lines, first recorded

# Triage requests ## How triage prompts work ## Check the channel's connections ## Prompts to paste ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Triage requests

> Claude Tag triages a Slack request channel with two setup messages. See in-thread answers, duplicate flags, owner routing, weekly theme rollups, and optional ticket filing.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How triage prompts work

This page is for any team with an intake channel, like #ask-it, #design-requests, or #legal-help, where people post questions and someone has to route or answer each one.

The two prompts below are Slack messages you paste in the request channel, in order. Together they set up a standing role: when someone tags `@Claude` on their request, it replies in-thread, answering what it can, flagging duplicates, and routing the rest. The weekly rollup lands as a top-level post in the same channel and sweeps anything that wasn't tagged.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection     | Examples     | Why it matters here                     |
| :------------- | :----------- | :-------------------------------------- |
| None           | —            | Works on Slack content alone            |
| Issue tracking | Linear, Jira | Optional. Files routed items as tickets |

## Prompts to paste

Add Claude to the channel with `/invite @Claude` if it isn't there, then two messages set it up.

<Steps>
  <Step title="Give the channel a standing role">
    ```text wrap theme={null}
    @Claude remember for this channel: when someone tags you on a request, check whether it duplicates something already reported, answer it directly if the answer exists, and otherwise route it to the right owner with a one-line summary. Track recurring themes.
    ```

    "Remember for this channel" saves the role to [channel memory](/docs/claude-tag/users/memory), so it applies to everyone's threads, not just yours. Tell requesters to include `@Claude` when they post; pin the convention or add it to the channel topic.
  </Step>

  <Step title="Add a weekly rollup so nothing is missed">
    ```text wrap theme={null}
    @Claude every Friday at 3pm, post a summary of this week's requests: how many, top themes, and anything still unrouted, including posts that didn't tag you.
    ```

    "Including posts that didn't tag you" turns the recap into a sweep, so requests that arrived without a mention are still caught. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).
  </Step>
</Steps>

Answers draw on what the channel has already settled, meaning its [memory](/docs/claude-tag/users/memory) and its own past threads, and routing gets more accurate as corrections land in channel memory.

## Related resources

<CardGroup cols={2}>
  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    How the weekly rollup runs on a schedule
  </Card>

  <Card title="What Claude Tag remembers" href="/docs/claude-tag/users/memory" horizontal arrow>
    How the standing role persists and improves
  </Card>
</CardGroup>

claude-tag/users/use-cases/watch-monitors First recorded · 63 lines, first recorded

# Watch monitors and alerts ## How monitor-watch prompts work ## Check the channel's connections ## Prompts to paste ### Schedule a recurring dashboard check ### Investigate a single alert ### Start the diagnosis before anyone asks ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Watch monitors and alerts

> Claude Tag watches dashboards and alert channels so you see one line per issue. See scheduled checks, alert investigation before anyone asks, and the prompts to set both up.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How monitor-watch prompts work

This page is for operations and on-call teams. A monitor is an automated check in a tool like Datadog or PagerDuty that fires an alert when a metric crosses a threshold. These prompts have Claude check those dashboards or investigate alerts as they arrive.

Each prompt below is a Slack message. You paste it in the channel that receives the alerts, Claude checks the connected dashboards or investigates the alert and posts progress in that thread, and the findings land there too. What comes back depends on the prompt, and each one below names it, like a scheduled one-line-per-service check, a single alert's diagnosis, or a standing watch that posts only changes.

## Check the channel's connections

Check that the channel has the connections below. Ask `@Claude what can you access from this channel?` to check; an admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection | Examples                   | Why it matters here                        |
| :--------- | :------------------------- | :----------------------------------------- |
| Monitoring | Datadog, Sentry, PagerDuty | Required. Reads dashboards and alert state |

## Prompts to paste

### Schedule a recurring dashboard check

One message sets up a standing check that posts every morning, one line per service.

```text wrap theme={null}
@Claude every morning at 7, check the service dashboards and post one line per service: green, or what's off and since when.
```

Name the output format in the schedule, like "one line per service" above, so every post reads the same way. To list or cancel scheduled work later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

### Investigate a single alert

Reply in the thread the alert landed in for a first pass at diagnosis. The prompt names what diagnosis means here and where to put the result.

```text wrap theme={null}
@Claude investigate this alert: when it started, what changed around then, and what you'd look at first. Post findings here.
```

"When it started, what changed around then" points the work at diagnosis, and "post findings here" keeps the trail in the thread for whoever picks it up.

### Start the diagnosis before anyone asks

Set this up as a routine to get both: a scheduled check against the last known state, and an investigation kicked off for any change. The routine posts only when something changed, not on every check.

```text wrap theme={null}
@Claude every two hours, check the alerting dashboard against its last state. For anything new, post when it started, what changed around then, and what to look at first.
```

## Related resources

<CardGroup cols={2}>
  <Card title="Fix bugs" href="/docs/claude-tag/users/use-cases/fix-bugs" horizontal arrow>
    When the investigation should end in a pull request
  </Card>

  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    Schedules and event triggers
  </Card>
</CardGroup>

claude-tag/users/use-cases/work-with-github First recorded · 121 lines, first recorded

# Work with your GitHub repositories ## How GitHub prompts work ## Check the channel's connections ## Prompts to paste ### Answer a repository question without interrupting the author ### Stop refreshing a pull request ### Hand off the change you keep postponing ### Triage a suspected bug where the report arrives ### Hand off a change and follow its pull request in one message ### Act on review comments and CI failures ## Repository instructions in CLAUDE.md ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Work with your GitHub repositories

> Claude Tag works with your GitHub repositories from Slack: answer questions in-thread, subscribe to pull requests, and hand back chores as draft pull requests.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

## How GitHub prompts work

This page is for engineers and anyone else with questions a repository can answer. Claude works with the GitHub repositories an admin granted for the channel. It reads the code to answer questions, watches pull requests you name, and hands back changes as draft pull requests.

Each prompt below is a Slack message. Paste it in the channel or thread where the question lives. Claude clones the repository into an isolated workspace Anthropic hosts, posts progress in that thread, and delivers the result there too.

Name the repository in the first message. A session starts with no repositories checked out and clones one when the request names it. Anything Claude opens on GitHub is authored by the Claude GitHub App, so it appears in your review queue like any other pull request.

<Note>An admin [grants a repository to the channels that need it](/docs/claude-tag/admins/attach-to-scope), and questions about the code work only in those channels. By default anyone in those channels can ask, and an admin can [restrict who can use Claude](/docs/claude-tag/admins/restrict-access#control-who-can-invoke-claude-tag).</Note>

## Check the channel's connections

Check that the channel has the connection below. Ask `@Claude what can you access from this channel?` and the reply also lists which repositories the channel can reach. An admin can [add a connection](/docs/claude-tag/admins/add-connections) the channel is missing.

| Connection | Examples | Why it matters here                                                |
| :--------- | :------- | :----------------------------------------------------------------- |
| Code       | GitHub   | Required. Reads granted repositories and opens draft pull requests |

The same workflows apply to other source control systems. For GitLab, an admin [connects it with an access token](/docs/claude-tag/admins/connections/gitlab) instead of the GitHub App, and Claude clones its repositories the same way.

If Claude replies that a repository isn't configured, the repository wasn't granted for this channel. An admin can [verify GitHub access](/docs/claude-tag/admins/configure-github#verify-github-access). After the grant changes, start a fresh thread and name the repository in the first message.

## Prompts to paste

### Answer a repository question without interrupting the author

A question about how the code behaves arrives in the channel, and the person who wrote it is away. Claude clones the repository, reads the code, and posts the answer in the thread.

```text wrap theme={null}
@Claude in acme/data-pipeline, how does the export retry logic decide when to give up? Name the files involved.
```

Asking for the files involved attaches proof to the answer, so anyone in the thread can open them and check.

Investigation questions work the same way: when a behavior last changed, in which commit, and who to ask about it.

```text wrap theme={null}
@Claude in acme/data-pipeline, did the export retry behavior change recently? Find the commit that changed it, when it landed, and who wrote it.
```

The clone carries the repository's full commit history, so history questions get answered from the same checkout as code questions. If the repository keeps a `CODEOWNERS` file, questions about who owns a path read from it too.

### Stop refreshing a pull request

Your work is blocked on a pull request a teammate opened, and the only way to know it moved is to keep checking the page. Claude subscribes to the pull request and posts in the thread when it updates, whether Claude opened it or a person did.

```text wrap theme={null}
@Claude subscribe to PR #519 in acme/data-pipeline, the schema migration. When CI finishes or a review arrives, post here, and tag me if anything failed.
```

Claude reads the pull request's workflow runs and logs, so the post says whether checks passed or failed. To list or cancel a subscription later, see [Manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work). Because the prompt asks for a tag only on failure, passing runs post to the thread without notifying you.

### Hand off the change you keep postponing

Small, well-understood changes sit on the list for weeks because they never become urgent. Docs drift from the code, a config key keeps its old name, a dependency stays a version behind. Describe one in a message, and it comes back as a draft pull request linked to the thread.

```text wrap theme={null}
@Claude in acme/data-pipeline, the CSV export docs still describe the old date format. Update them to match the code and open a draft PR. Done means CI is green and the PR links back here.
```

Writing a [definition of done](/docs/claude-tag/users/good-habits#give-every-task-a-definition-of-done) into the task lets the session check its own work. The change comes back as a draft pull request in your review queue, opened under Claude's own GitHub identity.

### Triage a suspected bug where the report arrives

A report arrives in the feedback channel, and nobody knows yet whether it's a bug. Claude investigates the repository and either explains the behavior or opens a draft fix.

```text wrap theme={null}
@Claude a user reports that exports drop rows with empty dates. In acme/data-pipeline, is that a bug or intended behavior? If it's a bug, open a draft PR with a fix; if it's intended, explain here what the code does.
```

For the full arc from a bug report to green CI, including a standing watch that triages a bug channel, see [Fix bugs](/docs/claude-tag/users/use-cases/fix-bugs). Because the prompt asks for either a fix or an explanation, the thread gets an answer even when the behavior turns out to be intended.

### Hand off a change and follow its pull request in one message

You can combine the earlier recipes in a single message. The prompt below hands off a change, sets the definition of done, and asks Claude to subscribe to the pull request it opens.

```text wrap theme={null}
@Claude in acme/data-pipeline, the deprecation warnings in the export module still reference the removed legacy-dates option. Remove the stale warnings and open a draft PR. Done means CI is green and the PR links back here. Then subscribe to your own PR, and when CI finishes or a review arrives, post here and tag me if anything failed.
```

Claude opens the draft and then follows it the way it follows any pull request, because subscriptions work the same whether Claude opened the pull request or a person did. CI results and review activity arrive as posts in the thread, so you open GitHub only to review the finished change.

### Act on review comments and CI failures

Claude can watch a pull request and address CI failures, review comments, and change requests as they come in, until the pull request is ready to merge. You approve and merge.

```text wrap theme={null}
@Claude watch your PR #562 in acme/data-pipeline. When CI fails, fix it and push. When a review comment arrives, address it and push. Post here after each push saying what changed and why. Done means CI is green and every comment is addressed. I do the approving and merging.
```

<Warning>If you don't want Claude to approve or merge pull requests, turn on branch protection rules that restrict who can merge. These rules apply to Claude too. Also write "I do the approving and merging" into the task, as the example does. The task wording states your intent, but it's an instruction Claude can lose track of, not a control. The branch protection rule is what enforces it.</Warning>

Ask for a post after each push so you can follow the pull request from the thread instead of opening GitHub.

## Repository instructions in CLAUDE.md

If your repository has conventions Claude should follow, such as file layout, pull request labels, or dependencies to install, add them to a `CLAUDE.md` file at the repository root. When Claude clones the repository into a session, its `CLAUDE.md`, `.claude/CLAUDE.md`, and `.claude/rules/*.md` files load on the next turn, so the guidance arrives without further prompting. Skills in the repository's `.claude/skills/` folder also load, so Claude can use them in sessions that have the repository. Anyone with repository write access can edit these files, and they reach every session that works in that repository, from any channel.

Each session runs in an isolated sandbox with a standard set of preinstalled tools. Two threads are two sessions with two separate sandboxes. If the repository needs a tool that the standard set doesn't include, such as a language runtime or a database client, add the install commands to `CLAUDE.md`, and Claude [runs them when its work needs them](/docs/claude-tag/admins/configure-github#install-project-dependencies).

<Note>A `CLAUDE.md` is guidance rather than a gate. If a pull request must carry a label or pass a check, make that a repository rule. For where `CLAUDE.md` sits among channel memory, channel instructions, and skills, see [Teach Claude something that sticks](/docs/claude-tag/users/good-habits#teach-claude-something-that-sticks).</Note>

## Related resources

<CardGroup cols={2}>
  <Card title="Fix bugs" href="/docs/claude-tag/users/use-cases/fix-bugs" horizontal arrow>
    The full arc from a bug report to a draft pull request and green CI
  </Card>

  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    Pull request subscriptions and other standing work
  </Card>
</CardGroup>

claude-tag/users/use-cases/your-own-channel First recorded · 111 lines, first recorded

# Work from your own channel ## Your own channel versus a DM ## Set up the channel ## Prompts to paste ### Ask scratch questions ### Get a digest of channels you don't follow ### Track your week ### Hand a thread to a teammate ### Chase your open follow-ups ## Cover your time away ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Work from your own channel

> Create a Slack channel for you and Claude Tag alone and run your work from it. See scratch questions, digests of channels you don't follow, a weekly status digest, follow-ups chased until they close, and a handoff that covers your time away.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

A channel with just you and Claude in it works the same way any other channel does. This page is for anyone who wants a place for work that doesn't belong in any specific team's channel, like half-formed questions, personal digests, and the things you said you'd do.

## Your own channel versus a DM

A DM is the other place to work alone with Claude, and the two surfaces run on different accounts. A DM session runs with your own claude.ai connectors, the work is attributed to you (pull requests excepted; the Claude GitHub App authors those), and usage bills to your seat. What Claude does there sits outside channel and workspace memory.

Your own channel runs with the connections an admin set for it, usage bills to the organization, and what Claude learns there accumulates as [channel memory](/docs/claude-tag/users/memory) that later threads build on. [Routines](/docs/claude-tag/users/proactivity) can post there on a schedule. When scratch work turns into a team task, the thread is ready to [hand to a teammate](#hand-a-thread-to-a-teammate).

Pick a DM for personal tasks on your own connections, or for data that shouldn't run through a shared channel connection. Pick your own channel for standing work, and for anything you might later hand off or show someone. [Pick the right surface](/docs/claude-tag/users/good-habits#pick-the-right-surface) compares both against a team channel.

## Set up the channel

1. Create a Slack channel and add Claude with `/invite @Claude`. Make the channel public unless the work needs to be private, since [memory](/docs/claude-tag/users/memory) from a public channel is shared across the workspace and teammates can find and join the work. A private channel works too, and keeps its memory in its own store.
2. Ask `@Claude what can you access from this channel?`. None of the prompts below require a connection, and an admin can [add a connection](/docs/claude-tag/admins/add-connections) your work needs, like the issue tracker or GitHub.
3. Tell Claude how the channel should behave and ask it to remember, as in `@Claude remember for this channel: keep replies short, and format digests as tables`. Later sessions in the channel start from what you saved.

## Prompts to paste

Each prompt below is a Slack message. You paste it in your channel, Claude works with the channel's history and connections, and the result lands in that thread.

### Ask scratch questions

A question is half-formed, or the answer only matters to you. Ask it here instead of in a team channel.

```text wrap theme={null}
@Claude summarize the last week of #product-feedback and pull out anything about the export flow.
```

Naming a public channel works from here, since Claude's Slack search covers public channels in this workspace. For a channel's full history rather than what search finds, Claude needs to be a member of that channel too. The answers stay in your channel, where later sessions read them.

### Get a digest of channels you don't follow

Some channels matter to your work a few times a month, not daily. Have Claude watch them and post here when something is relevant.

```text wrap theme={null}
@Claude watch #product-announce, #eng-announce, and #design-announce. Once a day, post here anything relevant to the billing migration. Skip days with nothing.
```

Naming both the channels and the topic keeps the watch useful, and skipping empty days keeps this channel readable. Instead of skimming three announcement channels yourself, you read at most one post a day here.

### Track your week

Open threads pile up here the way they do in any project channel. A scheduled digest posts a weekly summary of where they all stand.

```text wrap theme={null}
@Claude every Friday at 3pm Pacific, post a digest of this channel: what closed this week, what's still open, and what hasn't moved in five days. Skip anything with a ✅ reaction.
```

Give the digest a concrete threshold, like five days without movement, and stalled work shows up without you asking for it. React ✅ to anything you consider done, and the digest drops it. Include the timezone, since schedules default to UTC. To list, edit, or cancel scheduled work later, see [manage standing work](/docs/claude-tag/users/proactivity#manage-standing-work).

### Hand a thread to a teammate

Scratch work sometimes turns into a team task. Suppose a thread in this channel started as a half-formed question about the export flow, grew into a reproducible bug, and the fix now belongs to your teammate Marta. That thread is ready to share as it stands, because anyone in the channel can steer a session by replying in it. Invite Marta to the channel (for a public channel, sharing the thread link works too) and ask for a handoff summary in the thread.

```text wrap theme={null}
@Claude summarize this thread for Marta: what's been tried, what's decided, and what's still open.
```

The summary gives Marta the state of the work in one message, with the full history above it. From there the thread is hers to continue, without re-mentioning @Claude or starting over.

### Chase your open follow-ups

Claude can track the work you've committed to but might have forgotten about. When you agree to do something in another channel, forward that message to this channel, or post a short note here describing the commitment. When the work is somewhere Claude can check through this channel's connections, like a pull request review you owe, include the link.

Then schedule a weekly sweep.

```text wrap theme={null}
@Claude every Monday at 9am Pacific, read this channel and post one line per thing I said I'd do that isn't done yet, with how long it's been open. Check anything linked before calling it done. Keep listing each item until I mark it with a ✅.
```

Monday's post lists each commitment in this channel that isn't done yet. React ✅ when you finish one and it drops off the list, and everything else comes back the next Monday.

## Cover your time away

Your channel can cover for you while you're out. Before you leave, post one handoff message here and pin it. Say who's covering, where each piece of work stands, what to point people at, and what holds until you're back. Then tell Claude to answer from it and to pause the channel's standing work.

```text wrap theme={null}
@Claude I'm out next week and Marta is covering. Where things stand: the billing migration is waiting on legal, the dashboard rebuild is paused until the design review closes, and the onboarding runbook is pinned in this channel. Leave the pricing config alone until I'm back. While I'm out, when anyone asks here, answer from this message and the channel's history. Pause this channel's scheduled posts until I say I'm back.
```

While you're out, a teammate who needs to know where a piece of work stands, or who owns it, tags `@Claude` in your channel and gets the answer from the pinned handoff message, the channel's history, and [channel memory](/docs/claude-tag/users/memory). If you set a Slack status or an out-of-office reply, point people to this channel in it.

The pause covers this channel's own routines, like the Friday digest and the Monday sweep this page sets up, so scheduled posts stop piling up unread. Anyone in the channel can [list, edit, or disable its standing work](/docs/claude-tag/users/proactivity#manage-standing-work), so a teammate can turn a routine back on early if the coverage needs it.

On your first morning back, ask Claude to catch you up.

```text wrap theme={null}
@Claude I'm back. Turn this channel's scheduled posts back on, and post one list of what needs me first, in priority order, built from what happened here while I was away.
```

The reply is one list of everything that happened here while you were away, ordered by what needs your attention first.

## Related resources

<CardGroup cols={2}>
  <Card title="Set up routines" href="/docs/claude-tag/users/proactivity" horizontal arrow>
    List, edit, or disable the standing work this page sets up
  </Card>

  <Card title="Good habits" href="/docs/claude-tag/users/good-habits" horizontal arrow>
    Pick the right surface and write tasks that close
  </Card>
</CardGroup>

claude-tag/users/when-claude-responds First recorded · 104 lines, first recorded

# Control when Claude Tag responds ## What triggers a response ## Turn automatic replies on or off ## The name on a reply ## Make a channel quieter ### Quiet one conversation ### Quiet the whole channel ### Remove Claude Tag from the channel ## When Claude quiets itself ## Messages that never get a reply ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Control when Claude Tag responds

> Claude Tag replies to DMs, threads it's already in, and channel messages it judges warrant a reply, all without an @-mention. See what triggers a response, how to tell an unprompted reply from a task reply, how to turn automatic replies on or off with the Respond automatically setting, how to quiet a thread or channel, when Claude quiets itself, how to remove Claude from a channel, and which messages never get a reply.

export const BetaNote = () => <Info>Claude Tag is in public beta. Features and behavior described here may change before general availability.</Info>;

<BetaNote />

Claude replies without an @-mention in DMs, in any thread it's already part of, and to channel messages it judges warrant a reply. It's an ambient presence in the channel, and the @-mention is how you guarantee a response, not a requirement for one. Claude also [turns unprompted replies off on its own](#when-claude-quiets-itself) in a channel whose messages stop giving it anything to respond to. Any channel member can quiet Claude further, give it [standing work that posts on a schedule](/docs/claude-tag/users/proactivity), or remove it from the channel.

## What triggers a response

Where you send the message decides whether you need the mention.

| Where you write               | Replies without an @-mention?                                                                                                                                  |
| :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A DM with Claude              | Always. Every message is addressed to Claude already                                                                                                           |
| A thread Claude is already in | Yes, unless you've [quieted the thread](#quiet-one-conversation). Once Claude has joined, every reply there reaches it without another mention                 |
| A channel, top-level          | Sometimes, when it can answer a question or pick up a task. Include `@Claude` to guarantee a reply, or [turn unprompted replies off](#quiet-the-whole-channel) |

All of this is adjustable. You can [quiet a single thread](#quiet-one-conversation), [turn automatic replies off across a channel](#turn-automatic-replies-on-or-off), or tell Claude which kinds of messages to respond to.

For work that should happen without anyone typing a message, use a [routine](/docs/claude-tag/users/proactivity): scheduled posts, channel watches, and pull-request subscriptions run on their own trigger and post into the channel.

## Turn automatic replies on or off

The **Respond automatically** setting controls whether Claude replies to a channel's messages without an @-mention. Each channel has its own. When it's on, Claude may reply to a message it judges warrants one, as [What triggers a response](#what-triggers-a-response) describes. When it's off, Claude replies in that channel only when someone @-mentions it.

All three places below change the same setting, so a change you make in one appears in the others.

| Where                                   | How                                                                                                                                                                                                                                      |
| :-------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| In Slack                                | Ask Claude in the channel, for example "@Claude only respond in this channel when someone @-mentions you" or "@Claude respond to messages here even when nobody mentions you." Claude confirms the change.                               |
| The channel's Configure page            | Open the **Configure** link in the footer of any Claude reply and switch the **Respond automatically** toggle. See [Configure Claude for a channel](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel).                       |
| The Claude Tag admin page (admins only) | At [`claude.ai/admin-settings/claude-tag`](https://claude.ai/admin-settings/claude-tag), on the **Slack** tab under **Claude Tag's access**, open the channel's scope and switch **Respond automatically** in its **Advanced** settings. |

The setting covers the channel's messages, not DMs. To quiet a single thread instead of the whole channel, [ask Claude in that thread](#quiet-one-conversation). Work that runs on a schedule or an event rather than in response to a message is a [routine](/docs/claude-tag/users/proactivity), which has its own controls.

## The name on a reply

Claude doesn't post every reply under the same display name. The name shows which kind of work produced the reply, in two forms:

* **Claude**, the name alone: the reply comes from Claude's ambient presence in the channel, including unprompted replies
* **Claude** followed by a short description of the task in square brackets: the reply comes from a [working session](/docs/claude-tag/concepts/how-it-works) handling that task in its thread. The description changes with every task, so a channel might show something like `Claude [reviewing the launch checklist]`, `Claude [debugging a failing deploy]`, or `Claude [summarizing customer feedback]`.

## Make a channel quieter

If Claude is replying to messages that weren't meant for it, turn that down from inside the channel.

### Quiet one conversation

Tell Claude in the thread to respond only when mentioned.

```text wrap theme={null}
@Claude only respond when I @-mention you
```

Claude stops following that thread, and the rest of the channel is unaffected. This is the fix when one busy thread is the noise. The [`!mute` command](/docs/claude-tag/users/commands#mute-or-unmute-a-thread) goes further and silences the thread entirely; any direct `@Claude` mention turns it back on.

### Quiet the whole channel

Turn the channel's [**Respond automatically**](#turn-automatic-replies-on-or-off) setting off, so Claude replies there only when @-mentioned. From Slack, ask Claude directly.

```text wrap theme={null}
@Claude only respond in this channel when someone @-mentions you directly.
```

Claude confirms the change, which is channel-wide, not just for you. You can make the same change with the toggle on the channel's Configure page, and an admin can make it from the Claude Tag admin page.

Threads Claude already joined keep forwarding replies, so quiet those individually with the in-thread line above. The [`!mute` command](/docs/claude-tag/users/commands#mute-or-unmute-a-thread) quiets one thread at a time and does nothing at a channel's top level.

### Remove Claude Tag from the channel

When quieting isn't enough, end Claude's presence in the channel.

```text wrap theme={null}
/remove @Claude
```

Claude can no longer read or post in that channel. Any member can run this unless your Slack admin restricts the command. Admins have further options, through full removal from the workspace, on [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access).

## When Claude quiets itself

When a channel's messages stop giving Claude anything to respond to, with no questions it can answer and no tasks it can pick up, Claude turns unprompted replies off there on its own. Mentioning `@Claude` turns unprompted replies back on.

A channel whose [**Respond automatically**](#turn-automatic-replies-on-or-off) setting is off stays that way until someone changes the setting.

## Messages that never get a reply

A few cases produce silence even when the message includes a mention:

* **Editing a message to add the mention.** An edit doesn't trigger a response. Delete the message and send a new one with `@Claude` included.
* **Channels with guest accounts.** By default, Claude is off in channels that include guests; your admin can turn it on per scope. Ask whoever runs your Claude plan, or send them [the guest access setting](/docs/claude-tag/admins/restrict-access#restrict-guest-channels).
* **Channels shared across workspaces connected to different Claude organizations.** Every workspace where Claude runs is connected to a Claude organization, the account a company sets up for Claude. When a channel is shared across workspaces connected to different Claude organizations, Claude won't reply there and posts a refusal message instead. You can't tell from Slack how a workspace is connected; the refusal message itself is the signal. Use a channel that belongs to one workspace, or send Claude a DM.
* **Slack Connect channels.** Channels shared with another company are always off.

When the workspaces sharing a channel all belong to one Claude organization, Claude replies there, but with only your organization's default access and settings. The repositories, instructions, and memory set up for that channel or its workspaces don't apply, and Claude posts a notice in the thread explaining this from time to time. The guest check above still applies first where guest access is restricted.

To confirm a channel's setting, check the **Respond automatically** toggle on its [Configure page](/docs/claude-tag/users/good-habits#configure-claude-for-a-channel). To confirm an instruction Claude saved, ask `@Claude what do you remember about responding in this channel?`, and see [What Claude Tag remembers](/docs/claude-tag/users/memory) for where instructions are stored and how to change them.

## Related resources

* [Customize Claude Tag](/docs/claude-tag/admins/customize): the settings only an admin can change, if channel memory isn't enough
* [Restrict where Claude Tag operates](/docs/claude-tag/admins/restrict-access): the admin-side controls, from guest channels to full removal

connectors/building/after-publishing First recorded · 29 lines, first recorded

# Manage your listing after publishing ## Update your MCP server ## Update your plugin ## Update your listing ## Slugs are permanent ## Delist your connector

The first capture of this source. The page was already there, and this is what it said.

# Manage your listing after publishing

> Update your MCP server, plugin, and directory listing after publication

## Update your MCP server

An MCP server is a live API. To add, change, or remove tools, deploy the change to your server—no resubmission to Anthropic is required, and there is no scheduled re-review. Claude picks up the new tool surface on the next connection.

## Update your plugin

Plugin updates are pushed via your GitHub repo. CI mirrors changes to the public marketplace and runs automated screening on each update.

## Update your listing

Edit your description, categories, icon, and other listing metadata from the submissions dashboard at [Organization settings > Directory](https://claude.ai/admin-settings/directory/submissions) in Claude.ai. See [Managing your listing](/docs/connectors/building/managing-your-listing) for what you can edit directly and which changes require review.

## Slugs are permanent

Your directory slug is fixed after publication. It determines your connector's permanent listing URL:

```text theme={null}
https://claude.ai/directory/connectors/SLUG
```

Share this URL from your own documentation or a "Connect to Claude" button to send users directly to your listing. Display names can change via the dashboard; the URL slug cannot.

## Delist your connector

To voluntarily remove your connector from the directory, email `[email protected]`.

connectors/building/authentication First recorded · 137 lines, first recorded

# Authentication for connectors ## Supported authentication types ## Anthropic-held client credentials ## DCR and CIMD details ## Cross-host authorization servers ## Callback URLs ## Token refresh ## Enterprise authentication ## Custom connectors ## Endpoint latency ## Network reference

The first capture of this source. The page was already there, and this is what it said.

# Authentication for connectors

> OAuth and authentication options for MCP servers in Claude

Authentication is the most common source of partner questions. Claude's auth support differs in a few places from the generic MCP specification, so read this page even if you're already familiar with MCP auth.

## Supported authentication types

Claude supports the following authentication types for remote MCP servers. The same infrastructure backs Claude.ai, Claude Desktop, Claude mobile, Claude Code, and Cowork.

| Type                    | Description                                                                                                                                             | Availability                                              |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| `oauth_dcr`             | OAuth 2.0 with Dynamic Client Registration ([RFC 7591](https://www.rfc-editor.org/rfc/rfc7591))                                                         | Supported out of the box                                  |
| `oauth_cimd`            | OAuth 2.0 with [Client ID Metadata Document](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents) | Supported out of the box                                  |
| `oauth_anthropic_creds` | OAuth 2.0 with Anthropic-held client credentials                                                                                                        | Contact `[email protected]`                        |
| `custom_connection`     | Custom URL or credentials supplied at connection time (for example, Snowflake-style)                                                                    | Contact `[email protected]`                        |
| `static_headers`        | Fixed credential (API key or bearer token) entered by an organization administrator as a request header when adding the connector                       | Beta                                                      |
| `none`                  | No authentication (authless server)                                                                                                                     | Supported. An optional partial-auth mode is experimental. |

Static bearer tokens and API keys are supported in beta through request headers (`static_headers`). An organization administrator enters the credential once when adding the connector, and Claude sends it on every request. The credential is shared by the organization rather than pasted per user. See [Authenticating with request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) for what administrators see and how to document the expected header for them.

Tokens or API keys passed in the connector URL (for example, `?token=`, `?apiKey=`, or `?userToken=` query parameters) are **not recommended**. A credential in a URL is a security vulnerability: URLs are routinely recorded in server logs, proxies, and browsing history, so a query-string credential is easy to leak. The MCP authorization specification explicitly [prohibits access tokens in the URI query string](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-requirements). Use OAuth or [request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) instead.

## Anthropic-held client credentials

A pure machine-to-machine `client_credentials` grant—where a server-to-server token is issued with no user in the loop—is **not supported**. Every connection requires user consent.

`oauth_anthropic_creds` is the consent-gated alternative. The flow works like this:

1. You create an OAuth `client_id` and `client_secret` in your own authorization server and send them to Anthropic.
2. Anthropic stores those credentials securely and associates them with your directory entry.
3. When a user connects your server, they go through a standard OAuth consent screen.
4. After consent, Anthropic uses the stored client credentials to complete the token exchange on the user's behalf.

This gives you a stable, registered OAuth client without requiring DCR or CIMD on your end, while keeping the user-consent step. Anthropic stores your credentials securely and uses them only for token exchange on behalf of consenting users; they are shared across the hosted Claude surfaces (Claude.ai web, Desktop, mobile, and Cowork). Claude Code runs its own OAuth flow on the user's machine and identifies itself with its own [Client ID Metadata Document](#callback-urls), so it does not use Anthropic-held credentials. Claude Managed Agents uses a separate credential set.

Anthropic-held credentials are bound to the authorization server that issued them. If you migrate to a new authorization server, email `[email protected]` with the new `client_id` and `client_secret` before cutting over. CIMD-based connectors don't have this constraint — a CIMD `client_id` is a self-hosted URL, so it works against any authorization server that fetches it.

To use this flow, email `[email protected]` with your `client_id` and secret.

## DCR and CIMD details

If your authorization server does **not** expose a `registration_endpoint` (i.e., does not support DCR), you have several options:

* Expose a `registration_endpoint`
* Support CIMD instead. Claude selects CIMD only when your authorization server metadata advertises **both** `"client_id_metadata_document_supported": true` **and** `"none"` in `token_endpoint_auth_methods_supported` — the second is required because Claude's CIMD client authenticates as a public client at your token endpoint. If either is missing, Claude falls back to DCR. See [lazy authentication](/docs/connectors/building/lazy-authentication#identify-the-client-with-cimd) for a worked CIMD example.
* Switch to `oauth_anthropic_creds`

For servers expecting high traffic from the directory, prefer **CIMD or `oauth_anthropic_creds` over DCR**. DCR causes Claude to register a new client on every fresh connection, which can result in very large numbers of registered clients on your authorization server. CIMD and Anthropic-held credentials avoid the registration call entirely.

Claude includes a [PKCE](https://datatracker.ietf.org/doc/html/rfc7636) `code_challenge` with `code_challenge_method=S256` on every authorization request, regardless of which registration mechanism it uses. Your authorization server must support S256 PKCE, and the [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection) requires it to advertise `"code_challenge_methods_supported": ["S256"]` in its metadata so spec-compliant clients can verify support before starting the flow.

To control which scopes Claude requests, include a `scope` parameter in the `WWW-Authenticate` header on your `401` response. If you don't, Claude requests the scopes your protected resource metadata advertises in `scopes_supported`. Claude also appends `offline_access` when your authorization server metadata lists it in `scopes_supported`, to obtain a refresh token. See [lazy authentication](/docs/connectors/building/lazy-authentication#return-401-not-a-tool-error) for the canonical `401` shape.

## Cross-host authorization servers

A cross-host authorization server doesn't need anything special on its own. The `authorization_servers` field in your [protected resource metadata](https://www.rfc-editor.org/rfc/rfc9728) tells Claude where the authorization server is, and Claude resolves it regardless of which host it points at. The thing to get right is making sure Claude can find the protected resource metadata in the first place.

**Always return a `401` with a `WWW-Authenticate` header** whose `resource_metadata` parameter points at your protected resource metadata document — the same handshake described in [Return 401, not a tool error](/docs/connectors/building/lazy-authentication#return-401-not-a-tool-error):

```http theme={null}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"
```

The `401` status is required — Claude does not honor a `WWW-Authenticate` header on a `200` response — and the `resource_metadata` URL doesn't have to be on the MCP server's origin; it can be any HTTPS location that serves the JSON document. That's what makes this the most reliable path for hosting platforms that can't serve `/.well-known/*` at the root, such as Supabase Edge Functions, Cloudflare Workers without a `/.well-known/*` route, and Lambda function URLs that only route a path prefix.

If your `401` doesn't include a `resource_metadata` pointer, Claude can still infer the metadata location by probing your MCP server's origin: `/.well-known/oauth-protected-resource/<your-mcp-path>` first, then `/.well-known/oauth-protected-resource`. Treat this as a fallback — it only works when your platform serves `/.well-known/*` paths, and it adds round-trips to every connection.

Whichever way Claude finds the document:

* The protected resource metadata document's `resource` field must match your MCP server URL exactly as the user enters it in Claude, including any path component.
* The metadata's `authorization_servers` field must list your authorization server's issuer URL. If you list more than one, Claude uses the first entry and does not fall back to later entries — list your primary issuer first.
* Your authorization server must serve its own discovery metadata — [RFC 8414](https://www.rfc-editor.org/rfc/rfc8414) authorization server metadata or [OpenID Connect Discovery 1.0](https://openid.net/specs/openid-connect-discovery-1_0.html) — at its `/.well-known/` paths, and that host must also be reachable from Anthropic's [published egress range](https://platform.claude.com/docs/en/api/ip-addresses). Discovery requests to the authorization server come from the same IP range as requests to your MCP server, so a WAF in front of your identity provider can break the flow even when your MCP server is reachable.

<Note>
  If your authorization server is Microsoft Entra ID, you must also register the MCP server URL as an Application ID URI on your Entra app registration, or the token request fails with `AADSTS9010010`. See [the troubleshooting entry](/docs/connectors/building/troubleshooting#microsoft-entra-id-rejects-the-resource-value) for the fix.
</Note>

If you control both hosts, an alternative is to serve the MCP endpoint and the authorization server behind a single custom domain that can route both `/.well-known/*` and your MCP path.

<Tip>
  A common symptom of a discovery failure is that your MCP server receives the initial request but your authorization server sees no traffic at all. That happens when neither path works: there's no `WWW-Authenticate: Bearer resource_metadata=…` header on your `401`, and the well-known paths on your MCP server's origin return `404`. With no metadata to read, Claude never learns where your authorization server is, and the connection fails with "Couldn't reach the MCP server." See [troubleshooting](/docs/connectors/building/troubleshooting) for the full diagnostic flow.
</Tip>

## Callback URLs

For the hosted Claude surfaces (Claude.ai web, Desktop, mobile, and Cowork), register the following redirect URI:

```
https://claude.ai/api/mcp/auth_callback
```

**Claude Code** is a native client and uses an RFC 8252 loopback redirect on an ephemeral port — for example:

```
http://localhost:3118/callback
```

The port varies per session. Claude Code declares `http://localhost/callback` and `http://127.0.0.1/callback` in its [Client ID Metadata Document](https://claude.ai/oauth/claude-code-client-metadata), so your authorization server must accept both with the port component ignored. [RFC 8252 section 7.3](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) requires this for the IP-literal form (`127.0.0.1`); apply the same port-agnostic match to `localhost` so Claude Code works, even though RFC 8252 section 8.3 discourages `localhost`. See [lazy authentication](/docs/connectors/building/lazy-authentication) for implementation details.

A Client ID Metadata Document can't prevent loopback impersonation on its own — any local process can bind a port and claim to be the legitimate client. The [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#localhost-redirect-uri-risks) requires authorization servers to display the redirect URI hostname clearly on the consent screen and recommends an extra warning when the only registered redirect URIs are loopback addresses.

## Token refresh

Claude refreshes tokens **reactively on a 401 response**, with a proactive refresh up to five minutes before the stored expiry. To avoid refresh failures:

* Return RFC 6749-compliant error codes (`invalid_grant`, not `invalid_request` or a custom code) when a refresh token is no longer valid
* Rotate refresh tokens for public-client connections. DCR and CIMD register Claude as a public client, and the [MCP authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#token-theft) adopts OAuth 2.1's requirement to rotate or sender-constrain refresh tokens for public clients. If you rotate, return the new refresh token in the same response that invalidates the old one.

Your `/token` endpoint must accept `Content-Type: application/x-www-form-urlencoded` per [RFC 6749 section 4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3). Claude sends both the initial token exchange and refresh requests with this content type. Some web frameworks default to JSON-only body parsing—if your endpoint returns `415 Unsupported Media Type`, register a form-urlencoded body parser. Dynamic client registration (`/register`) uses `application/json` per [RFC 7591 section 3.1](https://www.rfc-editor.org/rfc/rfc7591#section-3.1), so don't assume the same parser works for both.

## Enterprise authentication

<Note>
  Organizations using SSO can also connect their users to your server without an interactive OAuth consent step, using an identity assertion signed by their identity provider. See [Enterprise Managed Auth](./enterprise-managed-auth) for what your authorization server needs to support.
</Note>

Directory connectors use a **single shared OAuth application per connector**. There is no per-org OAuth client for directory connectors — enterprise customers connect to the same OAuth app as everyone else, and access is scoped by the user's own permissions on your service. Custom connectors are different: an admin can supply their own OAuth client credentials when adding the connector, which scopes the OAuth client to that organization. See [custom connectors](#custom-connectors).

## Custom connectors

When a user adds a custom connector by URL, the OAuth Client Secret field is **optional**. Supply it only if your authorization server requires confidential-client authentication.

Supplying your own pre-registered client ID (and secret, if your server requires one) as static client credentials is a good option when you want a stable OAuth client per organization: it avoids dynamic client registration entirely, and the credentials are scoped to the organization that entered them.

For servers that authenticate with a fixed API key or token rather than OAuth, request header authentication (`static_headers`) is available in beta. See [Supported authentication types](#supported-authentication-types) above and [Authenticating with request headers](/docs/connectors/custom/remote-mcp#authenticating-with-request-headers) for what administrators see.

## Endpoint latency

Claude waits up to **10 seconds** for a response from your OAuth discovery, registration, and token endpoints, and up to **30 seconds** for refresh token requests. If no response arrives within that window the flow is treated as a failure, even if your server eventually completes the request. Aim well under these limits; a token endpoint that takes several seconds to respond will produce intermittent connection failures for users.

If your token endpoint depends on slow downstream calls, return the HTTP response headers and body without buffering behind upstream work, and check that any reverse proxy, API gateway, or WAF in front of the endpoint isn't holding the response.

## Network reference

Anthropic's outbound traffic to your server originates from `160.79.104.0/21`. See the [IP address reference](https://platform.claude.com/docs/en/api/ip-addresses) if you need to allowlist Anthropic for conditional access or firewall rules.

connectors/building/directory-vs-custom First recorded · 79 lines, first recorded

# Directory connectors vs custom connectors ## Share an install link ### Directory connectors ### Custom connectors ## Suggested Connectors ## Use both: directory plus elevated custom ## Per-tenant URLs ## What the directory is not

The first capture of this source. The page was already there, and this is what it said.

# Directory connectors vs custom connectors

> Understand the difference between directory-listed and custom connectors

Directory connectors and custom connectors run on the **same MCP infrastructure**. The runtime, transport, authentication, and tool-calling code paths are identical. The difference is review, discoverability, and distribution.

|                                                                                | Directory connector                          | Custom connector                                           |
| ------------------------------------------------------------------------------ | -------------------------------------------- | ---------------------------------------------------------- |
| **Runtime**                                                                    | Same                                         | Same                                                       |
| **Anthropic review**                                                           | Yes                                          | No                                                         |
| **In-product discovery**                                                       | Browse, search, Suggested Connectors         | None                                                       |
| **Distribution**                                                               | [Directory link](#share-an-install-link)     | [Install link](#share-an-install-link) or manual URL entry |
| **Anthropic-held client credentials**                                          | Available                                    | Not available                                              |
| **[External link](/docs/connectors/building/mcp-apps/external-links) confirmation** | Can allowlist destinations to skip the modal | Always shows the modal                                     |
| **Appears as**                                                                 | Named card with logo                         | "Custom"                                                   |

For what directory and custom connectors look like to a Claude user, including the Verified and Community labels, see [connector verification](/docs/connectors/verification).

## Share an install link

Both directory and custom connectors have a URL you can share from your own documentation, a "Connect to Claude" button, or an onboarding email.

### Directory connectors

After publication, your connector has a permanent listing URL based on its slug:

```text theme={null}
https://claude.ai/directory/connectors/SLUG
```

For example, `https://claude.ai/directory/connectors/dovetail` opens the Dovetail listing with its description, screenshots, and a **Connect** button. You receive your slug when your submission is approved, and it [cannot change afterward](/docs/connectors/building/after-publishing#slugs-are-permanent).

### Custom connectors

For a connector that is not in the directory, link to the **Add custom connector** dialog with the name and URL prefilled:

```text theme={null}
https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=NAME&connectorUrl=ENCODED_URL
```

| Parameter       | Description                                                                                                 |
| --------------- | ----------------------------------------------------------------------------------------------------------- |
| `modal`         | Must be `add-custom-connector`.                                                                             |
| `connectorName` | Display name shown to the user.                                                                             |
| `connectorUrl`  | Your MCP server URL, [percent-encoded](https://developer.mozilla.org/en-US/docs/Glossary/Percent-encoding). |

For example, an install link for a server at `https://mcp.example.com/` looks like this:

```text theme={null}
https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Example&connectorUrl=https%3A%2F%2Fmcp.example.com%2F
```

When a user follows the link, claude.ai opens the dialog with the name and URL prefilled and shows a notice that the values came from an external link. The user reviews the values and confirms before anything is added. If the user is signed out, they are prompted to sign in first and then land on the prefilled dialog.

<Note>
  Install links only prefill the form. They do not bypass review by the user, and they do not grant your server any permissions the user has not confirmed.
</Note>

Organization administrators can use the same parameters on the admin path to prefill the org-wide connector dialog:

```text theme={null}
https://claude.ai/admin-settings/connectors?modal=add-custom-connector&connectorName=NAME&connectorUrl=ENCODED_URL
```

## Suggested Connectors

Directory connectors are eligible for **Suggested Connectors**—Claude can recommend your connector in-chat when it's relevant to the user's task. Custom connectors are never suggested. Every directory entry is automatically eligible; there is no separate opt-in.

## Use both: directory plus elevated custom

A supported pattern is to list a connector in the directory with safe, broadly-applicable defaults, **and** provide enterprise customers a separate URL to add as a custom connector with elevated permissions or tenant-specific configuration. Document both paths in your own product docs.

## Per-tenant URLs

If your server URL varies per tenant (for example, `{tenant}.mcp.example.com`), this is typically handled either as separate per-tenant directory entries or via the [`custom_connection`](/docs/connectors/building/authentication#supported-authentication-types) authentication type, where users supply their tenant-specific URL at connection time. `custom_connection` is enabled per partner—email `[email protected]` to request it. The directory does not currently template a single entry across tenant subdomains.

## What the directory is not

The Anthropic Directory is independent of the open [MCP Registry](https://registry.modelcontextprotocol.io) and the `modelcontextprotocol/servers` GitHub repository. Publishing to those does **not** surface your server in Claude. Submit through the [directory submission form](/docs/connectors/building/submission) to appear in Claude products.

connectors/building/enterprise-managed-auth First recorded · 168 lines, first recorded

# Enterprise Managed Auth for connectors ## How it works ## With lazy authentication ## Prerequisites ## Authorization server requirements ## Access token lifetime ## Testing your implementation ### Testing with the cross-app access playground ## Related resources

The first capture of this source. The page was already there, and this is what it said.

# Enterprise Managed Auth for connectors

> Accept identity assertions from enterprise SSO so users connect to your MCP server without a separate OAuth consent step.

<Note>
  Enterprise Managed Auth is in beta and is available on Claude Team and Enterprise plans. Organizations can [join the waitlist](https://claude.com/form/ema-waitlist) to request access. MCP server developers and identity provider vendors can [register interest](https://docs.google.com/forms/d/e/1FAIpQLSf1goHGNDVFK7rncYuh6wnRpWSy7eGOcgL1i8uw3oyKFO9UUA/viewform) in supporting this flow.
</Note>

Enterprise Managed Auth (EMA) lets a user connect to your MCP server silently, using the single sign-on session they already have with their organization. Instead of showing each user an OAuth consent screen, Claude presents your authorization server with an **identity assertion**: a signed JSON Web Token (JWT), issued by the customer's identity provider, that vouches for the user's identity.

Your authorization server validates the assertion and returns an access token in a single back-channel request. There is no browser redirect and no per-connector consent page. From the user's point of view, the connector is simply available as soon as their administrator enables it.

This flow is defined by the [MCP enterprise managed authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) and is built on the standard [JWT bearer authorization grant (RFC 7523)](https://datatracker.ietf.org/doc/html/rfc7523). The assertion profile follows the [Identity Assertion JWT Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/).

<Note>
  This page is for connector developers who need their authorization server to accept Enterprise Managed Auth. Identity provider setup and Claude admin console configuration are handled by the customer's administrator.
</Note>

## How it works

When a user whose organization has Enterprise Managed Auth configured invokes your connector, Claude obtains a signed identity assertion for that user and exchanges it directly at your token endpoint for an access token. The user never sees a browser redirect or a consent screen, and your MCP server receives the same kind of bearer token it would after the interactive OAuth flow.

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant Claude
    participant AS as Your authorization server
    participant MCP as Your MCP server

    Note over Claude: User is signed in to Claude through their organization's SSO
    Claude->>AS: POST /token (grant_type=jwt-bearer, assertion=signed JWT)
    AS->>AS: Fetch issuer JWKS and verify signature
    AS->>AS: Validate iss, aud, exp, sub, and client_id
    AS-->>Claude: access_token
    Claude->>MCP: Tool call with Bearer access_token
    MCP-->>Claude: Tool result
```

Two parties are involved in this exchange: the customer's identity provider signs the assertion, and your authorization server verifies it and issues the access token. Both roles are often served by commercial identity platforms, so the distinction here is about which tenant plays which role rather than about product type. The identity provider publishes its signing keys as a JSON Web Key Set, and your authorization server fetches that key set to verify each assertion.

## With lazy authentication

Enterprise Managed Auth also works with [lazy authentication](./lazy-authentication). When your server returns `401 Unauthorized` for a protected tool call, Claude normally shows the inline **Connect** card and runs the interactive OAuth flow. If the user's organization has Enterprise Managed Auth configured for your connector, Claude runs the silent JWT bearer exchange instead and retries the tool call without showing a prompt.

Your MCP server returns the same `401` with a `WWW-Authenticate` header as described in the [lazy authentication guide](./lazy-authentication#return-401-not-a-tool-error). Your authorization server must still meet the [requirements below](#authorization-server-requirements).

A fully authless server never returns `401`, so there is no point at which Claude can exchange an assertion. Enterprise Managed Auth does not apply to authless servers.

## Prerequisites

Before adding Enterprise Managed Auth, make sure the following are already in place.

* Your MCP server implements [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization), including Protected Resource Metadata (PRM) discovery, and follows the [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices). See our [authentication guide](./authentication) for Claude-specific requirements.
* Your authorization server registers Claude using either [Anthropic-held client credentials](./authentication#anthropic-held-client-credentials) or a [Client ID Metadata Document](./authentication#dcr-and-cimd-details).

<Warning>
  Dynamic Client Registration (DCR) is not supported with Enterprise Managed Auth. The identity provider stamps a fixed `client_id` into every assertion it issues, so your authorization server must already recognize that client before the first assertion arrives. A client created on the fly through DCR cannot satisfy this requirement because its identifier will never match the value in the assertion.
</Warning>

## Authorization server requirements

<Note>
  This section is for the authorization server operator. If your MCP server relies on a hosted identity platform, there is typically no code to write. Confirm that the platform supports the JWT bearer authorization grant and enable it for your tenant. If you run your own authorization server, the steps below describe what it needs to support.
</Note>

Support for this flow varies by product. The underlying capability is the JWT bearer authorization grant ([RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)), which lets an authorization server exchange a signed JWT for an access token. Some commercial authorization servers and identity platforms support it today and others do not yet, so the first step is to confirm that yours does and that the customer's identity provider can be registered as a trusted issuer.

<Steps>
  <Step title="Ensure the JWT bearer grant is supported">
    Your authorization server must accept `urn:ietf:params:oauth:grant-type:jwt-bearer` at its token endpoint and advertise it in the `grant_types_supported` array of its [authorization server metadata (RFC 8414)](https://datatracker.ietf.org/doc/html/rfc8414):

    ```json theme={null}
    {
      "issuer": "https://auth.example.com",
      "token_endpoint": "https://auth.example.com/token",
      "grant_types_supported": [
        "authorization_code",
        "refresh_token",
        "urn:ietf:params:oauth:grant-type:jwt-bearer"
      ]
    }
    ```

    Claude reads this metadata to discover whether your server supports Enterprise Managed Auth. The grant type must be listed here for the feature to be offered to the customer, even if your token endpoint would already accept it silently.
  </Step>

  <Step title="Register the trusted issuer">
    For each customer, your authorization server needs to trust that customer's identity provider as a JWT issuer. Your authorization server fetches the identity provider's JSON Web Key Set and uses it to verify the signature on every incoming assertion.

    Your authorization server is responsible for maintaining an explicit allowlist of trusted issuer URLs per tenant rather than accepting any well-formed JWT. An assertion whose `iss` is not on the tenant's allowlist must be rejected with `invalid_grant`, even if the signature is valid.

    <Warning>
      Never accept an identity assertion without full validation. As with all OAuth token handling, your authorization server must verify the signature, issuer, audience, expiry, and subject on every request. Use the JWT validation built into your authorization server product. If you need to inspect assertions in your own code, use the validation library or token introspection endpoint provided by your authorization server vendor rather than writing custom verification logic.
    </Warning>
  </Step>

  <Step title="Understand the token request">
    Claude sends a form-encoded `POST` to your authorization server's token endpoint:

    ```http theme={null}
    POST /token HTTP/1.1
    Host: auth.example.com
    Content-Type: application/x-www-form-urlencoded

    grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
    &assertion=eyJhbGciOi...
    &client_id=your-registered-client-id
    &scope=openid profile
    &resource=https://mcp.example.com
    ```

    The `assertion` parameter carries the signed JWT. The `client_id` is the value Claude is registered under at your authorization server. Claude also includes the `resource` parameter ([Resource Indicators, RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)) set to your MCP server URL whenever the customer's identity provider supports forwarding it. Some identity provider configurations cannot pass a resource indicator through, so your authorization server should accept the request whether or not `resource` is present and use it for audience binding when it is.

    Your authorization server validates the assertion according to the [JWT bearer token processing rules (RFC 7523 section 3)](https://datatracker.ietf.org/doc/html/rfc7523#section-3) and returns a standard OAuth token response. Claude then presents the returned access token as a `Bearer` credential on calls to your MCP server, exactly as it does after the interactive flow.

    <Note>
      The access token lifetime is set by your authorization server, and the assertion lifetime is set by the customer's identity provider. Anthropic does not control either value.
    </Note>
  </Step>
</Steps>

## Access token lifetime

Issue access tokens with whatever lifetime your security policy calls for. A short lifetime, such as one hour, does not force users to repeat single sign-on each time a token expires.

When a user signs in to Claude through their organization's SSO, Claude obtains a long-lived refresh token from the identity provider. Claude uses that refresh token to request a fresh identity assertion from the identity provider whenever it needs one, without any user interaction. Claude then exchanges the new assertion at your token endpoint for a new access token. From the user's point of view, the connection stays active for as long as the identity provider's refresh token remains valid.

The refresh token is issued by the customer's identity provider. Treat it as long-lived today. Identity provider administrators will be able to apply their own lifetime policy in the future.

## Testing your implementation

End-to-end testing requires a Claude organization with Enterprise Managed Auth enabled and an identity provider tenant configured to issue assertions for your authorization server's audience.

If your identity provider is Okta, refer to Okta's [Cross App Access participation guide](https://support.okta.com/help/s/article/claude-enterprise-managed-auth-with-okta-cross-app-access-xaa-beta-participation-guide?language=en_US) and configure your organization to be able to test your MCP's XAA implementation.

### Testing with the cross-app access playground

[Okta's cross-app access playground](https://xaa.dev) lets you exercise the flow without a Claude organization. This is useful while you develop, and when your organization's single sign-on is not on a supported identity provider. On the playground you can:

* Walk the full four-step flow end to end against a sandbox IdP, with every token shown decoded
* Point it at your own MCP server or REST API to check resource metadata discovery, the `WWW-Authenticate` hint on `401` responses, and token validation
* Point it at your own authorization server to check that it accepts an identity assertion over the JWT bearer grant, mints a scoped access token, and serves its metadata for discovery
* Bring your own OIDC or SAML identity provider in place of the sandbox one
* Re-run a single failed step and inspect service configurations, discovery documents, and a live event log

<Note>
  Enterprise Managed Auth is in beta. [Register interest](https://docs.google.com/forms/d/e/1FAIpQLSf1goHGNDVFK7rncYuh6wnRpWSy7eGOcgL1i8uw3oyKFO9UUA/viewform) to get onboarded for testing.
</Note>

## Related resources

<CardGroup cols={2}>
  <Card title="Authentication for connectors" icon="key" href="./authentication">
    Baseline OAuth requirements your server must already meet.
  </Card>

  <Card title="Lazy authentication" icon="lock-open" href="./lazy-authentication">
    Defer OAuth until a protected tool is actually invoked.
  </Card>

  <Card title="Testing your connector" icon="flask" href="./testing">
    Verify your connector works end to end in Claude.
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="./troubleshooting">
    Diagnose common authentication and connection issues.
  </Card>
</CardGroup>

connectors/building/index First recorded · 82 lines, first recorded

# Building custom connectors ## Getting started ### Key resources ## Transport & authentication ### Supported transports ### Authentication features ## Protocol features ### Supported ### Not yet supported ## Technical specifications ## Testing your server ## Related topics

The first capture of this source. The page was already there, and this is what it said.

# Building custom connectors

> Build your own MCP servers to connect Claude to your tools and data

## Getting started

<Note>
  **Authentication is the most common stumbling block.** Before you build, read the [authentication reference](/docs/connectors/building/authentication)—Claude's auth support differs from the generic MCP spec in a few important ways.
</Note>

Not sure whether to build an MCP server, a plugin, or both? See [what to build](/docs/connectors/building/what-to-build).

<Tip>
  **Build with Claude.** Install the official [`mcp-server-dev` plugin](https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev) in Claude Code—it walks you through building, testing, and packaging an MCP server interactively, using these docs as its reference.
</Tip>

### Key resources

* **SDK Examples**: [TypeScript](https://github.com/modelcontextprotocol/typescript-sdk) and [Python](https://github.com/modelcontextprotocol/python-sdk) SDKs contain server implementation examples
* **Protocol Specification**: [modelcontextprotocol.io](https://modelcontextprotocol.io)
* **Hosting Solutions**: Platforms like Cloudflare offer remote MCP server hosting with autoscaling and OAuth management
* **Auth Specifications**: Review the [authorization spec](https://modelcontextprotocol.io/specification/latest/basic/authorization) with emphasis on third-party service flows

## Transport & authentication

### Supported transports

Claude supports both Streamable HTTP and the legacy HTTP+SSE transport. The legacy HTTP+SSE transport is being deprecated in favor of Streamable HTTP.

### Authentication features

* Supports the [2025-03-26](https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization), [2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization), and [2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) auth specifications
* Dynamic Client Registration (DCR) enabled
* OAuth callback: `https://claude.ai/api/mcp/auth_callback` (hosted surfaces); loopback redirect for Claude Code — see [callback URLs](/docs/connectors/building/authentication#callback-urls)
* Token refresh and expiry support
* Custom credentials for non-DCR servers

## Protocol features

### Supported

* [Tools](https://modelcontextprotocol.io/specification/latest/server/tools), [prompts](https://modelcontextprotocol.io/specification/latest/server/prompts), and [resources](https://modelcontextprotocol.io/specification/latest/server/resources)
* [Text](https://modelcontextprotocol.io/specification/latest/schema#textcontent) and [image-based](https://modelcontextprotocol.io/specification/latest/server/tools#image-content) tool results
* [Text](https://modelcontextprotocol.io/specification/latest/schema#textresourcecontents) and [binary](https://modelcontextprotocol.io/specification/latest/schema#blobresourcecontents) resources

### Not yet supported

* Resource subscriptions
* Sampling
* Advanced/draft capabilities

## Technical specifications

| Constraint                             | Limit                                                    |
| -------------------------------------- | -------------------------------------------------------- |
| Claude.ai/Desktop max tool result size | \~150,000 characters                                     |
| Claude Code max tool result size       | 25,000 tokens (configurable via `MAX_MCP_OUTPUT_TOKENS`) |
| Claude Code timeout                    | Configurable via `MCP_TOOL_TIMEOUT`                      |
| Claude.ai/Desktop timeout              | 300 seconds (5 minutes)                                  |
| Transport protocol                     | Streamable HTTP (legacy HTTP+SSE being deprecated)       |

## Testing your server

1. Add directly to Claude via **Customize > Connectors**
2. Use the [MCP inspector](https://modelcontextprotocol.io/docs/tools/inspector) to validate auth flows
3. Add to Claude Code with `claude mcp add` and check `/mcp` for status. See the [Claude Code MCP quickstart](https://code.claude.com/docs/en/mcp-quickstart).

## Related topics

<Columns cols={2}>
  <Card title="MCP Overview" icon="plug" href="/docs/connectors/building/mcp">
    Understanding the Model Context Protocol.
  </Card>

  <Card title="Submit to Directory" icon="paper-plane" href="/docs/connectors/building/submission">
    Review requirements and submit your connector.
  </Card>

  <Card title="Test in Claude Code" icon="terminal" href="https://code.claude.com/docs/en/mcp">
    Connect and debug your server with the Claude Code CLI.
  </Card>
</Columns>

connectors/building/lazy-authentication First recorded · 247 lines, first recorded

# Lazy authentication for MCP servers ## Return 401, not a tool error ## Gate at the HTTP layer ## Serve the discovery documents ## OAuth discovery caching ## Step-up authorization ## Identify the client with CIMD ## Try it ## Adapting to your server

The first capture of this source. The page was already there, and this is what it said.

# Lazy authentication for MCP servers

> Let users call public tools immediately and defer OAuth until a protected tool is actually invoked.

Not every tool on an MCP server needs the user's identity. A product catalog can be browsed anonymously; an order history cannot. **Lazy authentication** (sometimes called *mixed auth*) lets a single server expose both: unauthenticated clients can connect, list tools, and call public ones, and the server only challenges for credentials when a protected tool is invoked. The challenge follows the [MCP authorization specification](https://modelcontextprotocol.io/specification/latest/basic/authorization).

In Claude, the challenge surfaces as an inline **Connect** card in the conversation. The user authenticates in a popup, Claude retries the same tool call automatically with the new token, and the turn continues — no context is lost.

<Note>
  If the user's organization has [Enterprise Managed Auth](/docs/connectors/building/enterprise-managed-auth) configured for your connector, the `401` triggers a silent token exchange instead of the **Connect** card. The tool call is retried automatically and the user sees no prompt.
</Note>

The examples below are drawn from a single-file Express app using `@modelcontextprotocol/sdk` over Streamable HTTP.

## Return 401, not a tool error

The only detail that matters is **how** the server refuses an unauthenticated call to a protected tool.

It must fail the **HTTP request** with `401 Unauthorized` and a [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc6750#section-3) header:

```http theme={null}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token", resource_metadata="https://example.com/.well-known/oauth-protected-resource/mcp", scope="orders:read"

{"error":"invalid_token","error_description":"Authentication required for this tool"}
```

The body is advisory; the `401` status and `WWW-Authenticate` header carry the protocol signal. The optional `scope` parameter tells Claude which scopes to request during authorization — include the minimum your protected tools need. If you omit it, Claude requests the scopes your protected resource metadata advertises in `scopes_supported` (plus `offline_access` if your authorization server metadata lists it), which can produce an over-broad consent prompt.

It must **not** return a successful HTTP response wrapping a tool error:

```http theme={null}
HTTP/1.1 200 OK

{"jsonrpc":"2.0","result":{"isError":true,"content":[{"type":"text","text":"Please sign in"}]},"id":1}
```

<Warning>
  A `200` with `isError: true` is an application-level tool failure. Claude passes the error text to the model as the tool result and moves on — there is no auth prompt. Only a transport-level `401` causes Claude to pause the call, run the OAuth flow, and retry. A `403` triggers re-authentication only when accompanied by `WWW-Authenticate: Bearer error="insufficient_scope"` for scope step-up; any other `403` is surfaced as a terminal error. If users are seeing "please sign in" text in the chat instead of a **Connect** button, the server is returning the wrong one.
</Warning>

The `resource_metadata` parameter in the `WWW-Authenticate` header points at the server's [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) Protected Resource Metadata (PRM), which in turn names the authorization server. That chain is how Claude discovers where to send the user without any of it being hard-coded in the client.

## Gate at the HTTP layer

Because the refusal must be an HTTP status, the check has to happen **before** the JSON-RPC message reaches the MCP SDK. Once a tool handler is running, its return value is already destined to be wrapped in a `200` response.

The sample inspects the parsed JSON-RPC body in the Express handler and short-circuits if the request is a `tools/call` for a protected tool and no valid bearer is present:

```ts src/index.ts theme={null}
const PROTECTED_TOOLS = new Set(["get_my_orders"]);

function callsProtectedTool(body: unknown): boolean {
  const messages = Array.isArray(body) ? body : [body];
  for (const msg of messages) {
    if (
      msg &&
      typeof msg === "object" &&
      (msg as { method?: unknown }).method === "tools/call"
    ) {
      const name = (msg as { params?: { name?: unknown } }).params?.name;
      if (typeof name === "string" && PROTECTED_TOOLS.has(name)) {
        return true;
      }
    }
  }
  return false;
}

const WWW_AUTHENTICATE =
  `Bearer error="invalid_token", ` +
  `error_description="Authentication required for this tool", ` +
  `resource_metadata="${BASE_URL}/.well-known/oauth-protected-resource/mcp", ` +
  `scope="orders:read"`;

async function handleMcpPost(req: Request, res: Response): Promise<void> {
  const token = extractBearer(req);
  const authed = isTokenValid(token);

  // Lazy-auth gate: fail with 401 BEFORE the MCP layer sees the request.
  // initialize, tools/list, and public tool calls fall through.
  if (!authed && callsProtectedTool(req.body)) {
    res
      .status(401)
      .set("WWW-Authenticate", WWW_AUTHENTICATE)
      .json({
        error: "invalid_token",
        error_description: "Authentication required for this tool",
      });
    return;
  }

  // Otherwise: stateless Streamable HTTP handling.
  const transport = new StreamableHTTPServerTransport({
    sessionIdGenerator: undefined,
    enableJsonResponse: true,
  });
  const mcp = buildMcpServer(authed ? "demo-user" : null);
  await mcp.connect(transport);
  await transport.handleRequest(req, res, req.body);
}

app.post("/mcp", (req, res) => {
  handleMcpPost(req, res).catch((err) => {
    console.error("mcp request error", err);
    if (!res.headersSent) {
      res.status(500).json({
        jsonrpc: "2.0",
        error: { code: -32603, message: "Internal error" },
        id: null,
      });
    }
  });
});
```

`initialize`, `tools/list`, and calls to `list_products` never hit the gate, so the connector is fully usable before sign-in. When the user already has a valid token, every request — public or protected — carries it and the gate is a no-op.

The same pattern covers **scope upgrades**: if the bearer is valid but lacks a required scope, return `403 Forbidden` with `WWW-Authenticate: Bearer error="insufficient_scope", scope="…"` and Claude prompts the user to re-consent. See [Step-up authorization](#step-up-authorization) below for what scopes Claude requests on re-consent and how the challenge is cached.

## Serve the discovery documents

After a 401, Claude fetches the URL from `resource_metadata` to learn which authorization server to use:

```ts src/index.ts theme={null}
function protectedResourceMetadata() {
  return {
    resource: `${BASE_URL}/mcp`,
    authorization_servers: [BASE_URL],
    bearer_methods_supported: ["header"],
  };
}

app.get("/.well-known/oauth-protected-resource", (_req, res) => {
  res.json(protectedResourceMetadata());
});

// Path-suffixed variant per RFC 9728 section 3.1 — clients try this first when
// the resource URL has a path component (/mcp).
app.get("/.well-known/oauth-protected-resource/mcp", (_req, res) => {
  res.json(protectedResourceMetadata());
});
```

Claude then fetches the authorization server's [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) metadata to find the `/authorize` and `/token` endpoints.

## OAuth discovery caching

Claude caches the discovery documents — your protected resource metadata and the authorization-server metadata it points to — **globally, keyed by URL**, with a staleness window of about five minutes by default. All Claude users connecting to the same server URL share a single cache entry, and distinct server URLs (for example, staging versus production) cache independently.

The refresh is lazy and best-effort: after you change `scopes_supported` (or any other discovery field), the new value is picked up by the first authorization that successfully re-runs discovery once the staleness window has elapsed, then propagates to everyone. There is no per-user expiry to wait for. If a refresh fails, Claude serves the stale entry and tries again on a later request, so an unreachable discovery endpoint doesn't immediately break existing connections — it just delays the change.

## Step-up authorization

The scope-upgrade case at the end of [Gate at the HTTP layer](#gate-at-the-http-layer) is the MCP specification's [Step-Up Authorization Flow](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#step-up-authorization-flow). When the bearer token is valid but missing a scope the requested tool needs, return `403 Forbidden` with a [`WWW-Authenticate`](https://datatracker.ietf.org/doc/html/rfc6750#section-3.1) challenge:

```http theme={null}
HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope", scope="orders:write"
```

Claude prompts the user to re-authorize and, on consent, retries the same tool call with the new token.

**Which scopes Claude requests on re-authorization.** Claude unions the scopes named in your `403` challenge with the scope your server advertises during discovery (the `scope` parameter on your initial `401` `WWW-Authenticate` response, or your protected resource metadata's `scopes_supported` if you don't send one). Scopes the user picked up in an earlier step-up aren't reliably carried forward into the next one. To make sure the user keeps a permission they still need, follow the [MCP spec's recommended approach](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#runtime-insufficient-scope-errors) and include it in the `403` `scope` value alongside the newly required scopes — don't return only the single missing scope and depend on the client to remember the rest.

If your `403` carries `error="insufficient_scope"` but **omits the `scope` parameter**, Claude still recognizes step-up and runs its normal scope selection: the discovery-time `WWW-Authenticate` scope first, then your protected resource metadata's `scopes_supported`, then the authorization server metadata's `scopes_supported`.

<Note>
  The `scope` value from your `403` is cached **per user, per server** for up to fifteen minutes and consumed by the next re-authorization that user starts against your server. The cache holds the most recent challenge — a new `403` overwrites the previous one — and is cleared once it's used. Combined with the [global discovery cache](#oauth-discovery-caching) above, a newly-added scope is available to step-up shortly after the discovery cache refreshes, typically within about five minutes of deploying the updated metadata.
</Note>

## Identify the client with CIMD

The sample does **not** implement Dynamic Client Registration. Instead it advertises support for **Client ID Metadata Documents** ([draft-ietf-oauth-client-id-metadata-document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/)) in its authorization-server metadata:

```ts src/index.ts theme={null}
function authorizationServerMetadata() {
  return {
    issuer: BASE_URL,
    authorization_endpoint: `${BASE_URL}/authorize`,
    token_endpoint: `${BASE_URL}/token`,
    scopes_supported: ["profile", "orders:read"],
    response_types_supported: ["code"],
    grant_types_supported: ["authorization_code", "refresh_token"],
    token_endpoint_auth_methods_supported: ["none"],
    code_challenge_methods_supported: ["S256"],
    client_id_metadata_document_supported: true,
  };
}
```

With CIMD the `client_id` is itself an HTTPS URL that dereferences to the client's OAuth registration metadata. There is no per-client database and no `POST /register` round-trip: at `/authorize`, the server fetches the `client_id` URL, verifies the document is self-referential (its `client_id` field equals the URL it was served from), and checks the requested `redirect_uri` against the document's `redirect_uris`. Because the document is self-asserted, the consent screen must display the **host of the `client_id` URL** (not the `client_name` field) as the relying party, and the listed `redirect_uris` should be required to be same-origin with the `client_id` URL.

<Note>
  Claude selects CIMD only when the authorization-server metadata advertises **both** `client_id_metadata_document_supported: true` **and** `"none"` in `token_endpoint_auth_methods_supported`. The second is required because Claude's CIMD client authenticates as a public client (`token_endpoint_auth_method: "none"`), so the token endpoint must accept [PKCE](https://datatracker.ietf.org/doc/html/rfc7636)-only requests without a client secret. If either property is missing, Claude falls back to looking for a `registration_endpoint`.
</Note>

For native clients, compare loopback IP `redirect_uri` values (`http://127.0.0.1/…`, `http://[::1]/…`) with the **port ignored**, per [RFC 8252 section 7.3](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) — native apps bind an ephemeral port at runtime. RFC 8252 section 8.3 discourages `http://localhost/…`, but Claude Code declares it in its CIMD and binds an ephemeral port at runtime, so apply the same port-agnostic match to `localhost` for compatibility. The sample's `redirectUriAllowed()` helper shows the comparison.

## Try it

<Steps>
  <Step title="Run the server">
    ```bash theme={null}
    npm install
    npm run build
    npm start
    ```

    The server listens on `http://localhost:3000/mcp`.
  </Step>

  <Step title="Call a public tool without auth: 200">
    ```bash theme={null}
    curl -s http://localhost:3000/mcp \
      -H 'Content-Type: application/json' \
      -H 'Accept: application/json, text/event-stream' \
      -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"list_products","arguments":{}}}'
    ```
  </Step>

  <Step title="Call a protected tool without auth: 401">
    ```bash theme={null}
    curl -si http://localhost:3000/mcp \
      -H 'Content-Type: application/json' \
      -H 'Accept: application/json, text/event-stream' \
      -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_my_orders","arguments":{}}}'
    ```

    Note the `WWW-Authenticate` header in the response.
  </Step>

  <Step title="Add it as a custom connector in Claude">
    Claude reaches custom connectors from Anthropic's infrastructure, so `localhost` is not reachable directly. Expose the server over a public HTTPS tunnel (for example, `cloudflared tunnel --url http://localhost:3000` or `ngrok http 3000`), then in **Customize > Connectors**, select **Add custom connector** and enter the tunnel's `/mcp` URL. See [Testing your connector](/docs/connectors/building/testing) for details.

    Ask Claude to list products (no prompt), then ask for your orders — the inline **Connect** card appears, and after authenticating the same call completes.
  </Step>
</Steps>

The sample's README includes a longer `curl` walkthrough that drives the stub `/authorize` and `/token` endpoints directly.

## Adapting to your server

* List your protected tools in `PROTECTED_TOOLS`.
* Replace `isTokenValid()` with real verification: JWT signature, `iss` matches your authorization server, `aud` equals the `resource` value you advertise in the PRM, and `exp`; or [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) token introspection against your IdP.
* Point `authorization_servers` in the PRM at your real issuer and delete the stub `/authorize` and `/token` handlers. Keep `client_id_metadata_document_supported: true` in your issuer's metadata if you want registration-free onboarding for Claude clients.
* If your server uses stateful Streamable HTTP sessions, the gate still belongs in the `POST /mcp` handler, before `transport.handleRequest`.

connectors/building/managing-your-listing First recorded · 86 lines, first recorded

# Managing your directory listing ## Access the dashboard ## Track submission status ## Server health and usage metrics ### What the metrics cover ### Health ### Topline metrics ### Error breakdown ### Usage by product ### Usage by tool ## Edit your listing

The first capture of this source. The page was already there, and this is what it said.

# Managing your directory listing

> Track submissions, monitor server health and usage metrics, and edit your Connectors Directory listing

Organizations that submit to the [Connectors Directory](/docs/connectors/directory) get a submissions dashboard in Claude.ai at [Organization settings > Directory](https://claude.ai/admin-settings/directory/submissions). Use it to track submissions through review, monitor your published server's health and usage, and edit your listing.

<Note>
  The dashboard covers directory-listed remote MCP servers only. Custom connectors and local servers (desktop extensions) don't appear here, and the dashboard shows only your own organization's submissions.
</Note>

## Access the dashboard

The dashboard is part of your organization's admin settings, so you need:

* **A Team or Enterprise organization**
* **Directory management access.** By default, only organization Owners and Primary owners have it. On Enterprise, an Owner can delegate access through a custom role with the **Directory** or **Libraries** permission; see [Before you start](/docs/connectors/building/submission#before-you-start) for the steps. Team plans don't have custom roles, so on Team this stays with Owners.

The same access covers everything on this page: viewing submissions, metrics, and reviewer feedback, and editing and submitting listings.

## Track submission status

The dashboard lists each of your organization's submissions with its current status. Open a submission to see its full details and any reviewer feedback. When reviewers request changes, their feedback appears on the submission's detail page; address it and resubmit from the same page.

## Server health and usage metrics

<Note>
  Metrics are in beta. They're computed daily from directory usage and can lag by up to 24 hours. Time windows with fewer than 5 calls, per-tool rows with fewer than 5 calls, and per-product rows with fewer than 50 calls are omitted.
</Note>

Once your server is published, its detail page shows health and usage data.

### What the metrics cover

All of the metrics on this page measure traffic from Claude: Claude.ai, Claude Desktop, Claude Code, and other Claude surfaces. Connections that people make to your server from other MCP clients, and local servers that run on a user's own machine, aren't visible to Anthropic and aren't counted. Your own server logs can therefore show activity that this page doesn't.

Tool call totals, error rates, and latency are measured at Anthropic's HTTP connector proxy. Tool call users and directory rank are measured from the MCP message stream, which covers both the HTTP and legacy WebSocket transports. If users reach your server only over the legacy WebSocket transport, you'll still see tool call users and a directory rank, but no tool call totals, error rates, or latency data.

### Health

The health badge summarizes your server's recent reliability:

| Status          | Meaning                                                                                                      |
| --------------- | ------------------------------------------------------------------------------------------------------------ |
| **Healthy**     | The 30-day disconnect rate is at or below 5%                                                                 |
| **Degraded**    | The 30-day disconnect rate is above 5%                                                                       |
| **Collecting…** | The server is published, but there isn't enough data yet to compute a disconnect rate (metrics update daily) |
| **Not live**    | The server isn't published yet; health appears after publication                                             |

The disconnect rate is measured against every distinct Claude account that sent your server any MCP message in the last 30 days, including connection attempts that never completed: it is the share of those accounts that chose to disconnect your connector during those 30 days.

### Topline metrics

* **Directory rank**: your position among published directory servers, highest first, ranked by the number of distinct Claude accounts that sent your server any MCP message in the last 30 days. Every MCP message counts toward the ranking, including `initialize` and `tools/list`, and it includes accounts whose connection attempt never finished authenticating — a broader population than the Tool call users card below. A "Trending" tag marks servers in the top 10 by recent growth in that same message-based count.
* **Tool call users (30d)**: the number of distinct Claude accounts that made at least one tool call (`tools/call`) to your server in the last 30 days. Accounts that only attempted to connect, or connected and browsed your tools without calling one, aren't counted. This card was previously labeled "Active users (30d)" and counted every MCP message, including handshakes from connection attempts that never completed; the renamed metric counts only accounts that actually used your tools, so it is usually much smaller than the number the old card showed.
* **Tool calls (30d)**: the number of `tools/call` requests Anthropic received for your server in the last 30 days. Protocol messages such as `initialize` and `tools/list` aren't counted here. This is a count of requests, not of users, so retries are included, as are requests that were turned away for authentication problems.
* **Error rate (30d)**: of the tool calls above, the fraction that either failed at the request level (for example, with a 5xx response or a timeout) or returned an MCP tool result with `isError: true`. Tool-call requests that were turned away for authentication problems aren't counted as errors, but they are included in the total number of tool calls that the rate is measured against. Shown with the most common error types.

### Error breakdown

A table breaks errors out over 1-day, 7-day, and 30-day windows: total calls, overall error rate, tool versus request error rates, HTTP 4xx and 5xx rates, and the top error types in each window.

### Usage by product

A per-product table shows 7-day calls, error rate, and p50/p95/p99 latency, broken down by the Claude product the calls came from, such as Claude.ai, Claude Desktop, Claude Code, and Cowork. Only a fixed set of Claude surfaces is shown, and Anthropic's own internal monitoring traffic is excluded.

Because this table covers a shorter window, drops low-volume rows, shows only a fixed set of Claude surfaces, and excludes internal monitoring traffic, its call counts won't add up to the 30-day tool call total above. That's expected.

A high error rate on a single product may reflect a client-side issue on Anthropic's end rather than a problem with your server.

### Usage by tool

A per-tool table shows 7-day calls, the overall error rate, and the tool-result error rate for your top 15 tools by call volume.

## Edit your listing

Open your submission's detail page to edit the listing. You can change directly:

* **Listing metadata**: tagline, description, categories, documentation and privacy policy links, support contact, and icon
* **Company details**: company name and website
* **Display name**: editable, but changing the name of a published server affects existing users and requires re-review

Save your edits as you go, then submit them for review. Submitted changes show as pending until a reviewer approves them, and you can discard pending changes before they're approved.

The URL slug is locked: it's permanent after publication, since it determines your listing URL.

For other edits or escalations, email `[email protected]`.