YouSpot

People the user has written to before whose latest email came after the user's latest email to them, in the last two weeks, longest wait first: name, email, mailbox, when they last wrote, when the user last wrote, and the days waited.

Change one of this person's web watches, named by monitor_key from get_web_watches. action check_now: check it right away instead of waiting for its schedule; anything new arrives as a change in a minute or two, read it with get_web_watches. A paused watch is not checked, and one still taking its first read answers status baseline. pause or resume: the watch and its agent together. stop: stop for good and pause its agent; what it found stays readable. update: a new frequency, or what is watched: watch for a page (a fresh first read follows; Pages only. What to watch: 'everything' (the default) for any meaningful change on the page, a preset (pricing, team, products, jobs, headline) for those fields only, or the person's own words, e.g. 'the number of open engineering roles'.), query or domains for a topic.

Given the author names from a page of posts, say which of them this user already knows. Ask in one call with every name, not one at a time. Each answer carries `standing`: 'dormant' means they know them and the correspondence stopped, which is the strongest reason to appear under a post; 'known' means they are still in touch; 'stranger' means they are not connected. Rank dormant first, known second, and keep a stranger only when the subject is squarely the user's own. `last_spoke` and `messages_exchanged` are there so you can say why this person is worth the reply.

Merge two duplicate records in the user's graph into one, person or company only. Every connection moves from the duplicate onto the kept record, fields the kept record lacks are copied over (never overwritten), and the duplicate is removed. Call with preview=true first and emit the merge_compare card it names: the card shows both records and merges when the user clicks, so never merge without an explicit yes. keep_id survives; merge_id goes. unmerge_graph_objects puts it back.

Send a message to one of the user's own agents by its handle (the name after the @ on its page) and start a run with it. Use this when the user asks you to hand something to a named agent: '@research, what changed at Acme?'. It returns at once with a trace_id; the agent's answer takes a minute or more, so read it later with agent_reply. Pass conversation_id to keep the exchange in one thread.

The objects in the user's graph directly connected to BOTH of two given objects — mutual contacts between two people, shared people between two companies. Only deliberate relationships count (bulk-import and system-inferred edges are excluded). Returns an empty list when there are none — report that honestly.

Today's Your day brief as it was written this morning: the Do list (each person, who they are to the user, why now, its state: 'ready' to send, 'question' waiting on one answer, or 'headsup' to read, the drafted note and what the user already decided on it), the Know lines, Coming up, What ran, and the page link, and `brand`: today's LinkedIn post and up to three conversations worth joining, each with a drafted comment, and when present `who_engaged`: who reacted to or commented on their posts this week, people they know with a note and first-timers with a profile link. Pass `date` (YYYY-MM-DD) for an earlier day. Pass `brief` to read one part of the day: 'relationship' (the people: Do, Know, Coming up) or 'branding' (the post, conversations and who engaged), as in 'what did my LinkedIn post say Tuesday?' or, from someone still using the old names, 'what did my branding brief say Tuesday?'; it reads only that part. Call it Your day, never two briefs. Pass `person` (a name, email or Brain object id) to get every item about that person from the last seven days of briefs instead. Call this for 'what do I need to do today?' and 'what's on my plate?' before anything else, and answer with the Do list first. Read-only: it never runs the brief again.

How this week is going on LinkedIn against the user's own post plan: the plan's subjects and whether each has a draft, what they posted this week and which plan subject each post was, the people they already know who reacted or commented (dormant first), and whether a nudge is due on Thursday. Use for 'how's my LinkedIn week going', 'did I post what I planned', 'who engaged with my post', 'who saw my post'. It never names strangers and has no impressions or follower counts; do not offer those. When plan is null, there is no plan for this week: offer to make one (the post-plan skill). When a subject has a draft_id, link it as [the draft](/graph/object/<draft_id> "note"). When plan is set, end with [See your week](/linkedin/manager), the page with the plan, its drafts, what went up and who noticed. switch says whether the daily LinkedIn manager is on, paused or off. When in_brand_brief is true, Your day keeps the week's subjects out of sight: tell them what is coming in plain words, never call it a plan page or the LinkedIn manager, never link /linkedin/manager or a plan object, say today's post arrives on [Your day](/your-day?show=brand) each morning, and offer a different post today (replace_todays_post). Use this for 'what's my post plan?'.

Work out what this user can speak to with authority, from what they have published, who is in their network, what they have been reading, and their profile — in that order of weight. Use this instead of asking them for keywords: they should never have to type a search query. Returns topics each carrying the source it came from and a short reason, plus `sentence`, one line naming what was picked and why, which you must show the user before anything you found. When `enough_to_go_on` is false there was too little to read and you should say so plainly and ask them what they care about, once — never guess.

Read an invoice PDF the user uploaded and return its fields: supplier, invoice number, dates, currency, subtotal, tax, total, PO number, payment terms, and every line item. Use it whenever someone asks what an invoice says, what they are being charged for, whether a bill adds up, or wants an invoice turned into data. Two parts of the result matter more than the fields. `unreadable` names what could not be read off the document — those are null, not guessed, and you must not fill them in yourself. `checks` lists where the document disagrees with itself: lines that do not sum to the subtotal, a total that is not subtotal plus tax, a quantity times a price that is not the line amount. Report every check to the user in plain language; they are the reason to read an invoice with a tool rather than an eye. Find the file first with search_graph_objects (type 'file') and pass its object_id, or pass part of the filename as name.

Work out what generating would use, rendering nothing and spending no draft or credit. Give it the kind (og_image for any image, email or pdf for any document) and whatever the user has said so far; it answers with the template it would use and that template's fields with their defaults, which required fields are still missing, the image sizes, the brand kit it would resolve to and the other kits with their ids, the page, orientation and footer a PDF would take from the kit, the templates the user has saved, the free drafts left, the unlock cost, and ready. Call it once before generate_og_image, generate_email or generate_pdf, then generate in the same turn unless one open choice would change the result.

Permanently delete one object from the user's graph, along with every connection touching it. Hard delete, no undo — confirm with the user before calling, and only when they asked for the deletion. Prefer delete_graph_object, which is reversible and asks the user to confirm on a card; use this one only when they have said they want the data gone. Purging a file or image also deletes the stored file from their Files. To remove a single connection and keep both objects, use disconnect_graph_objects instead.

Read back objects a skill wrote earlier, filtered precisely. Use this when you need to know whether something is already recorded rather than to find something by name: has this engagement already been flagged, was this client surfaced today, is there a plan for this week. Filters on type, on the source that wrote the row, on text within the name or description, and on a created-at window in days. Sorts newest, oldest or by name, and pages with offset. For a keyword or semantic hunt across the graph use search_graph_objects; for browsing a whole type use list_graph_objects.

People the user has not written to in a while, quietest first, with the date of the last thing they sent. Use when a skill needs to know who has gone quiet rather than to rank who is worth contacting: which clients have drifted, who is overdue a note, has anyone been silent since a given point. Judged on sent mail, so it measures what the user did rather than what arrived. `days` sets the line; the default is six months, which is the corpus's dormancy line rather than a tuned one.

Return a generated item itself, for showing it where a YouSpot link cannot be opened: a social image comes back as the PNG, a PDF as an image of each page, an email, document or Substack post as its text. Takes an artifact_id from a generator or list_artifacts. A draft comes back watermarked; the user unlocks the clean copy for a credit, or at no charge on a Solo or Pro plan.

Read the content of a file the user uploaded, use this when the answer may live in a document in their Second Brain: schedules, itineraries, contracts, exports, scans, decks. PDFs and images are returned as the actual document, so tables and scanned pages read correctly. Word (.docx), PowerPoint (.pptx) and Excel (.xlsx) files come back as their extracted text; text and Markdown files as written. Long text is cut after about 200 KB. Find the file first with search_graph_objects (type 'file') and pass its object_id, or pass part of the filename as name.

Read every new issue from the allowed publications into the brain, whole, so they can answer questions later. Returns what landed: `created` is new issues, `updated` is ones whose text changed, `unchanged` is ones already held, which is the normal case for a second run in a day. With no allowed sender it reads nothing and says so, which means the owner has not chosen yet — call find_my_newsletters and ask. `issues` names what arrived, newest first, so the summary can be written from it without another call.

Fetch and read the content of one public web page by URL — use when the user asks what a page or article says, or you need to read a prospect's or company's own site before a conversation. Reads the page as it renders in a real browser, so it works on JavaScript sites. Returns the page's readable text. Pass save=true to also keep the page in the user's graph as a web_link (searchable later); default is a one-off read that is not stored. Cannot read LinkedIn, social, or any sign-in-gated page — those are captured through the browser extension, and this tool says so rather than trying. Not for researching a company in general (that is research_company) or reading a file the user uploaded (that is read_file).

Record one dated touchpoint with someone in the user's graph — an email exchanged, a call, a meeting, a LinkedIn touch, or a manually noted contact — so 'when did I last talk to them?' has an answer. Creates an interaction object connected to the person it happened with; get with_object_id from search_graph_objects. occurred_at is ISO 8601 ('2026-08-28T15:00:00Z') and may be in the future ('we're meeting next Tuesday'). direction is from the user's point of view: inbound means they reached out to the user.

Who introduced the people in the user's graph, aggregated per introducer, so a skill can see which relationships actually produce work rather than which are warm. Returns each introducer with the people they introduced and how many of those became clients. Use for 'which relationships turn into work', 'who sends me business', 'what do my best clients have in common'. NOT a route to one stranger, which is find_paths, and not a warmth ranking, which is who has gone quiet.

Research one specific company in depth — the same engine behind the CompanyResearch.ai app. Takes a website domain (preferred) or a company name, and returns a profile: description, industry, size, revenue, funding history, founders, competitors, recent news, and answers to the user's saved research questions. Use this when the user asks to research, analyze, or get a briefing on a specific company. For discovering many companies by criteria, use find_companies instead; for a quick identity card, company_card markup is enough. The first run on an uncached company can take a while — that is normal.

Bring back objects the user deleted, up to 200 object_ids in one call: the undo for delete_graph_object and delete_selected_graph_objects. Only the user's own deleted objects come back. A record that was merged into another is not restored here; unmerge_graph_objects undoes a merge. Permanently purged objects are gone and cannot be restored.

Save a generated image, email or PDF as a template in the user's Second Brain, so the same inputs can be generated again from the generator or from chat. Takes the artifact_id a generator returned and a short name the user would recognise. Only the author's own draft can be saved. Returns the saved_template_id.

Download a file from a public http(s) URL and store it in the user's Second Brain as a file object. Use it when the user shares a direct link to a PDF, image, spreadsheet, or other file and asks to save, download, or keep it. The saved file shows up with their uploads and can be read afterwards with read_file. Not for web pages (that is read_web_page with save=true) and not for files behind a sign-in. Files over 50MB are refused.

Save text as a file the user can download from their Second Brain, most often a CSV: a contact list, an export, a table they want in a spreadsheet or another tool. Also .tsv, .txt, .md and .json. Files written anywhere else (a sandbox, a temp folder) are gone when you finish and the user never sees them, so this is the only way to hand over a file. Never tell the user a file is ready unless this returned saved: true. Link it in your reply as [filename](download_url).

Search the user's own LinkedIn connections by name, company, or job title. Use this to answer questions like 'who do I know at Stripe?', 'which of my connections are founders?', or to look someone up by name. Returns matching people with their company, title, headline and location. Omit all filters to list the most recent connections. On a miss the response also reports how many connections the user has imported at all: if no_imported_data is set, their connections are simply not loaded — say that, and never conclude from an empty result that they don't know the person.

Search the user's connected Gmail mailboxes and return matching messages, newest first: from, to, subject, date, and a short snippet of the body. `query` uses Gmail search syntax: 'in:sent to:[email protected]' for messages the user sent to someone, 'from:[email protected]' for messages they received, plus operators like subject:, newer_than:7d, and has:attachment. So 'show me the last 5 messages I sent to [email protected]' is query 'in:sent to:[email protected]' with max_results 5. Each result carries a `starred` flag; a message the user starred matters to them, so weight it accordingly; 'is:starred' finds starred mail directly. For 'how many' questions, use total_matches_estimate in the result (it is Gmail's estimate of ALL matches, beyond the messages returned). If it reports no Gmail account connected, give the user the link it returns. Rare header-only connections cannot run query search; the tool says so. Answer correspondence questions from the brain for those.

Find where something was said across the user's Granola meetings: a phrase, a name, a product, a number. Searches summaries and full transcripts of synced notes and returns each matching meeting with a short excerpt around the match. Use it for 'when did we discuss X' or 'what did she say about Y'; use get_granola_notes to browse by date.

Search the user's graph by matching a term against object names and descriptions, plus semantic matching over text-bearing objects (notes, facts, posts, links, files, emails), so a search finds what the user means, not just exact words. Use this to find a specific thing they mentioned (a person, company, file, saved web link, or fact) when you don't have its object_id. Optionally restrict to one type. A reply the user saved from chat is type 'chat', not 'note': search without a type, or with type 'chat', to find one. Returns matches with their object_id for follow-up with get_graph_object.

Look up a person or company in the user's connected HubSpot CRM, live, by email address, domain, or name. Use this for 'what do I have on [email protected]', 'is gusto.com in the CRM', 'is Acme a customer', or 'do we have a contact named Jane Doe'. An email finds that contact and the company at its domain; a domain finds the company and the contacts at it; anything else is a name search over both. Returns the matching records with their CRM properties and a url to open each in HubSpot. lifecyclestage says where a record stands (subscriber, lead, marketingqualifiedlead, salesqualifiedlead, opportunity, customer, evangelist, other), so 'a customer' means lifecyclestage is customer. found=false with no errors means the CRM has no such record. For aggregate questions over many records use ask_about_hubspot_contacts or ask_about_hubspot_companies instead.

Search the text of the user's imported LinkedIn messages (DMs), newest first. Filter by words in the message, by the person it was with, and by date. Use for 'who messaged me about hiring?', 'find the LinkedIn message where someone mentioned Shopify', 'what LinkedIn messages did I get last month?'. Returns snippets; read a whole thread with get_linkedin_conversation.

Search public LinkedIn posts by keywords. In chat, and for a watcher agent that collects posts, the matches are stored in the user's brain automatically, so do not re-save them with graph tools; an agent that only reads posts gets them back unstored, with no object ids. LinkedIn search matches loosely and returns posts that never say the keywords; those are verified away here and never stored, so what you get back has been checked, and discarded_count says how many were thrown out. The response splits posts into 'new' (never seen by this user before) and 'seen' (already stored on an earlier run). When running as a scheduled watcher, only report or email when 'new' is non-empty, and never include 'seen' posts. Link a post with [label](object:<object_id>) using the returned object ids. Pass found_by_object_id (your own agent node id, the id inside the [object:...] marker at the end of your instructions) so finds are filed under that agent.

Search the notes synced from the user's Obsidian vault, by keyword and by meaning, and get back where each one lives in the vault with an excerpt around the match. Use this when they ask what their notes say about something, or point at their vault ('in my notes', 'from my Obsidian'). Narrow with vault_id, folder (a vault path prefix like 'Meetings/2026'), or tag. Returns object_id and path for follow-up with get_obsidian_note, which returns the full note.

Search the Slack messages saved to the user's brain — by keyword and by meaning — newest first. Covers channels the user switched on and their DMs with YouSpot; nothing outside those. Optionally restrict to one channel (id or #name) or to messages since an ISO date. If it reports no Slack workspace connected, give the user the link it returns.

Search recent public posts on X (Twitter) by keywords — the X API covers roughly the last week. Uses the user's connected X account; if none is connected, give the user the link it returns. Results are stored in the user's brain automatically — do not re-save them with graph tools. The response splits posts into 'new' (never seen by this user before) and 'seen' (already stored on an earlier run). When running as a scheduled watcher, only report or email when 'new' is non-empty, and never include 'seen' posts. Link a post with [label](object:<object_id>) using the returned object ids. Pass found_by_object_id (your own agent node id, the id inside the [object:...] marker at the end of your instructions) so finds are filed under that agent.

Write the user's Daily Briefing now and email it to them, when they ask for it: 'send me my daily briefing', 'brief me', 'email me my briefing'. It covers what is new since the last briefing they were sent, and is sent even if the daily email is turned off. Queues the work and returns; the email arrives in a minute or two, so say it is on its way, not that it arrived. Pass focus only when they name a topic to lead with.

Send an email to the signed-in user at their own account email address. Use this when the user asks to be sent something — 'email me this', 'send myself a reminder', 'send me that summary as an email'. The recipient is fixed to their own address and cannot be changed. To write an email to anyone else, use create_gmail_draft instead — it drafts in their Gmail without sending. Compose a short, specific subject line yourself if the user didn't give one. The body is Markdown, rendered into the YouSpot email template before sending: '## ' subheadings, '- ' bullets, **bold**, > quotes and tables all work. Do not write HTML, and do not add a sign-off or a footer — the template supplies both. LINKS. Never write an absolute youspot.com URL; you do not reliably know them, and a wrong one reaches the reader as a dead link. Write one of these two forms instead and they are resolved for you: [Acme Corp](object:obj_4c1f88a2) — links to an object in the user's graph. The id must come from a graph tool result you actually ran; an id that is not theirs silently loses its link. [Which of these should I chase?](chat:Which of these prospects should I chase first?) — opens chat with that question ready to send. Link the objects you name, so the reader can go straight to what you are telling them about. End with one 'chat:' link offering the obvious next question — it is the cheapest way for them to act on what you found. The reader sends that question as their own, so never put their employer, title or role in it unless the About this user block states it; ask without naming a company rather than guess one.

Post a message to a Slack channel as YouSpot right now, optionally as a reply in a thread. Only for text the user already approved word for word in this conversation, or for an agent delivering its own report. When the user asks you to write, draft or prepare a Slack message, use draft_slack_message instead: nothing posts until they tap Send on the card. Only channels the bot has been invited to work; use list_slack_channels to find ids. '## ' headings, '- ' bullets, **bold** and [label](url) links all render.

Send a short text message (iMessage/SMS) to the user's own phone, the number they verified on the iMessage or SMS integration. Sends right now by default; pass send_at to schedule it for later (a reminder for tomorrow morning, a nudge before a meeting). send_at must be ISO 8601 WITH the user's UTC offset, e.g. 2026-09-18T09:00:00-04:00: work out their timezone from the conversation or ask, never guess UTC. Scheduled texts can be listed with list_scheduled_texts and cancelled with cancel_scheduled_text. The recipient is always the user themself; no other number can be reached. If no verified number is on file, the response says so and carries the link to connect one. Keep messages short and concrete; there is a rate cap, so never use this for routine chatter. If a send returns setup instructions, relay them and wait for the user to complete that step before retrying. Never report a failed send as delivered.

Make a brand kit the default for the user's active space, so social images, emails and PDFs render in it when no brand_kit_id is given.

Set a dated follow-up about an object in the user's graph — 'follow up with Jane in March'. Creates a follow-up fact carrying follow_up_at (ISO 8601, usually in the future) and an optional note, connected to the object it's about. Interim shape: there is no dated query tool yet, so to read follow-ups back ('what's due this week?'), list the user's fact objects and filter on json_data.follow_up_at yourself.

Rename or re-describe an object in the user's graph, or set any of its type-specific fields: a contact's phone, email, headline or location, a company's funding stage, and so on. 'name' and 'description' work on every type (files included); other field names come from the type's field dictionary, which get_graph_object returns as 'editable_fields'. Read that first rather than guessing a name, because a name the dictionary does not have is skipped. Pass null to clear a field. Identify the object by object_id (search_graph_objects returns it). To add to a note or any description without losing what is there, pass the new text in 'append' instead of rewriting 'description'.

Turn the user's LinkedIn manager on, pause it, or say what it is set to. On, it runs daily: plans the week from their recent work when there is no plan, drafts the posts in it, checks what went up against it, nudges once on a quiet Thursday, and names people they know who engaged, by email and only when there is something to say. It never posts. Use for 'turn on the LinkedIn manager', 'pause my LinkedIn emails', 'is my LinkedIn manager on', 'post twice a week'. posts_per_week (0 to 3) sets how many posts the plans it writes hold; 0 is Off, the same as pause. The same switch is on its card in Agents and on the Scheduled tab; when in_brand_brief is true it lives in Your day instead, as Posts per week in Your day settings at manage_url.

Turn the recurring emails YouSpot itself sends the user off or back on, when they ask to stop getting one, unsubscribe, or resume it. The emails: exec_briefings is the daily 'Daily Briefing' built from their Second Brain; post_reports is the 'Your posts' section of that briefing (a LinkedIn post that is new or gaining traction); process_emails are the one-off notices when an import or sync finishes; agent_emails is the mail their cloud agents and LinkedIn or X watchers send (the agents keep running, only the email stops); tracker_updates is the email when a web page tracker finds a change; checkout_reminders are the at most two notes after they leave a checkout unfinished. Pass only the settings they mean, false to stop. When they say 'this email' or 'the one I just got' without naming it, call with no arguments first: the result names the last email YouSpot sent them and the setting behind it, then call again with that setting false. This is for YouSpot's own mail only; for newsletters or senders in their Gmail use the Gmail tools. Confirm in plain words what is now off (or on) and that they can change it any time at the settings_url returned.

Put a generated item behind a public link, so it can be posted, embedded in a page or opened by someone with no YouSpot account. Anyone holding the link can see it. revoke true takes an existing link away again. Returns the URL.

Draw a view in the conversation for hosts that show MCP Apps: a saved view by artifact_id, or view source you wrote after calling view_components. The view runs its own Queries through the host, so call data tools first only to learn the shapes they return. Saves nothing; call generate_view to keep it.

The objects in the user's graph closest in MEANING to one object — nearest neighbours by stored embedding, so it finds related notes, facts, links, files, and posts even when no words match. Use it to browse outward from something search_graph_objects found. Only text-bearing objects carry embeddings (built in the background), so an empty result usually means the source has none yet.

This week's Slack conversations whose latest message waits on the user: a DM, an @mention, or a reply in a thread they wrote in, newest first. Each carries the kind, who wrote it, the channel, the message, when, how many replies and a link. Covers only the channels the user switched on and their DMs.

Turn Your day on for the user and start writing their first brief now, from their inbox. Call this when they ask to start Your day, their morning brief, their relationship brief or their personal branding brief (also called the brand brief), or say yes to one. Pass `brief` when they named one: 'relationship' (who needs a reply or a nudge today, note written) or 'branding' (who engaged with their posts, next post drafted). The first brief takes a few minutes; the brief card under your reply waits for it and fills in, so say it is being written and stop.

Pull the user's newest Granola notes into their brain right away instead of waiting for the six-hourly sync. Queues the sync and returns; notes appear over the next minute or two. Say it was queued, not that it finished.