Prompt library · AI · 12 prompts
Prompts from the guide
MCP connectors: USB-C for AI
12 prompts from this guide. Fill in whatever sits in [square brackets] — your own context, the document text or the name of your tool. That context is exactly what separates a generic answer from a usable one.
Checking what it's actually allowed to do
List out everything you can do with my connected connectors: - which connectors are active - for each one: what specific actions you can take with it - split them into actions that only read, and actions that change or create something - for every action that changes something, describe exactly what would happen if I asked you to do it At the end, tell me 3 things I might expect you can do but actually can't.
Mail: searches your inbox can't do
Go through my mail from the last [7] days and give me three lists: 1. What someone wants from me and I haven't replied yet — for each one, the sender, what it's about in one sentence, and how old it is. 2. What I promised — find phrases like “I'll send,” “I'll prepare,” “I'll get back to you” in my sent messages and list which ones have no visible follow-up. 3. What looks like an approaching deadline — dates, due dates, payment terms. Sort by urgency, not by date. Don't send anything and don't reply to anything, just list it for me.
Calendar: finding time instead of emailing about it
Look at my calendar and [colleague's name]'s calendar for the next two weeks and suggest three slots for a one-hour meeting. Conditions: - no sooner than the day after tomorrow, so I have time to prepare - ideally mid-morning, between 9 and 12 - not on Monday (I have a standing meeting) and not on a day I already have three or more meetings - leave at least 30 minutes of buffer before and after For each slot, explain why you picked it, and what I might have to move because of it. Don't create anything — I'll pick one and send the invite myself.
Document storage: company memory that answers back
In our shared storage, find everything related to [client / project / topic]. Then tell me: - which documents are relevant, sorted from newest, with one sentence each on what they contain - what we promised the client and which document it's in - where documents contradict each other (different numbers, different dates, different scope) - what seems to be missing on the topic, in your view For every claim, state which file it came from. Don't assert anything that isn't in the documents.
Notion and the company wiki: no more archaeology through old notes
In Notion, find the notes from the last meeting of the [name] team and put together prep for the next one: 1. Tasks from last time: what was assigned, to whom, with what deadline, and which of them have a visible completion 2. Items that got pushed “to next time” — and how many times that's already happened 3. Decisions that were made and are worth reiterating 4. A proposed 45-minute agenda, ordered so whatever's blocking other things gets handled first Don't change anything in Notion. Write the output to the chat, I'll review it and create the notes myself.
Slack and team communication
Go through the channels [#channel1, #channel2] for the last [5] days and write me a summary for someone who's been out for a week: - what got decided and who decided it - open questions nobody answered - where I got mentioned and what's expected of me - threads with more than [15] messages — for each one, one sentence on what it's about and how it turned out Make it readable in two minutes. Don't post anything to Slack.
Combinations: where the real value is
Put together my prep for Monday's meeting. Use mail, calendar, and Notion for this: 1. From Notion: unfinished tasks from the last meeting and who owns each one 2. From mail over the past week: what came in that relates to the topics from item 1 — sender and date for each 3. From the calendar: what the team has scheduled this week and where it conflicts 4. A proposed agenda for [45] minutes with a time estimate for each item 5. Three questions I should raise at the meeting to get things moving Back up every claim with a source (link or document name). Where you're not sure, say so instead of guessing.
Phase 4: how to write requests when working with connectors
The previous answer doesn't look right. Before you fix it, walk me through what you did: - which connectors you used and in what order - what exactly you searched for in each one (the query) - how many results it returned and how you chose among them - which claims in the answer come from data you found and which are your own conclusion Then suggest how I should rephrase the request so you also find [what was missing from the answer].
Reviewing permissions
Give me an overview of my connected connectors as a table: Connector | what I can do with it | read / write | what I've actually used it for in the last month Only put in the last column what you actually learned from me in conversations, not a guess. Where you don't know, write “don't know.” Then suggest which connectors or which permissions I could turn off without losing anything.
What it involves
We want to expose our [internal system — e.g. inventory, CRM, order tracking] to an AI assistant through a custom MCP server. We're still gathering what it should be able to do. I'm attaching [a system description / list of reports / sample data]. Prepare material for a meeting with the system's users: 1. 15 questions you think people most often need answered from this system — phrased the way a person would ask them, not as database queries 2. For each one: is it a read, or would it mean changing something? 3. Which of them could be answered by a single capability, and which need a combination of several 4. 8 questions I should use at the meeting to find out what I missed 5. Risks: where could data leak out through an integration like this that shouldn't Don't propose a technical solution — that's the developer's call.
What it involves
Based on this collection of questions [paste the output from the previous step], write a spec for a developer for a custom MCP server. Structure: 1. Purpose: what the server should enable and for whom 2. A list of capabilities — for each: name, what it does, what it needs as input, what it returns, whether it only reads or also changes something 3. Permissions: rights are derived from the logged-in user, describe what that means for each capability 4. What the server deliberately doesn't do, and why (scope boundaries) 5. Open decisions that we need to make, not the developer 6. How we'll know in three months whether it was worth it — concrete, measurable signs Factual, no marketing, don't propose the technology.
From a request to a routine
I want to set this process up as a recurring routine: [paste the prompt that works]. Before I use it as a routine, adjust it: - make sure the output always has the same structure (headings, section order), so it can be compared week over week - add a sentence about what to do when it finds nothing interesting (so it doesn't send me made-up content) - remove anything that could send or change something - add a “What I should verify myself” section at the end Then tell me what schedule makes sense, and why.