YouSpot
Query one person's YouSpot second brain: their contacts, companies, notes and files, plus the Gmail, Google Calendar, HubSpot, LinkedIn, Slack and X accounts…
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноТолько чтение
Что умеет
- What Needs Attention: What this user should deal with right now, computed from their sent mail, their calendar and their LinkedIn export: people who went quiet after real correspondence, people they a
- Research Company: 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,
- Company Signals: Recent news and hiring movement for companies the user already knows, several at once, split into what is new since the last check and what was already reported. Use for watching comp
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Query one person's YouSpot second brain: their contacts, companies, notes and files, plus the Gmail, Google Calendar, HubSpot, LinkedIn, Slack and X accounts they have connected.
Endpoint: https://youspot.com/mcp/v1 (streamable HTTP). initialize, ping and tools/list need no credential; every tools/call uses OAuth 2.1 with PKCE and dynamic client registration, because every tool reads one member's own CRM.
Try it without an account at https://youspot.com/mcp/sandbox, the same read tools over a demo account. Docs: https://youspot.com/docs/mcp
Список инструментов сервера (60)
Технические названия из tools/list. Нужны только разработчикам.
| what_needs_attention | What this user should deal with right now, computed from their sent mail, their calendar and their LinkedIn export: people who went quiet after real correspondence, people they are meeting this week, who they write to most, invitations nobody answered, and the shape of their network. Each item carries the reason and where the numbers came from. Call this for 'what needs my attention', 'who am I forgetting', 'who should I follow up with', 'what should I do today' and anything else that asks who to deal with without naming one person. Then show an attention_list card and never write the items out yourself. `readiness` says whether the mailbox has finished being read: when it is 'pending' or 'partial', say so rather than presenting a short list as the whole picture. |
| research_company | 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. |
| company_signals | Recent news and hiring movement for companies the user already knows, several at once, split into what is new since the last check and what was already reported. Use for watching companies over time: what has happened at my clients, is anyone hiring, anything I should know before I reach out. When running on a schedule, report only the new items and stay silent when there are none. For one company in depth use research_company; for the open web use web_search. |
| get_domain_info | Look up the public registration (WHOIS) record for a website domain: who registered it, which registrar holds it, when it was created and last updated, when it expires, its nameservers, and its registry status codes. Use this ONLY when the user explicitly asks about the domain/WHOIS/DNS itself: 'who owns stripe.com?', 'when does our domain expire?', 'how old is this domain?', 'is this domain registered?'. Never call it for general questions about a company — this is public registrar data about a domain on the internet; it is not the user's own account data, and it says nothing about the company behind the domain. Registrant details are often masked by a privacy service, in which case the registrant fields name the proxy rather than the real owner; say so instead of presenting the proxy as the owner. |
| get_domain_value | Estimate what a domain name is worth (the /domainvalue appraisal): an estimated market value in dollars with the signals behind it — comparable sales, marketplace listings, an appraisal model, SEO data. Use when the user asks what a domain is worth, whether one is a good buy, or to compare domain values. A fresh appraisal can take up to a minute; repeat lookups within 48 hours are cached and instant. Include the report_url in your reply so the user can open the full report. |
| send_email | 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. |
| read_file | 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. PDFs and images are returned as the actual document, so tables and scanned pages read correctly. Find the file first with search_graph_objects (type 'file') and pass its object_id, or pass part of the filename as name. |
| save_file_from_url | Download a file from a public http(s) URL and store it in the user's Second Brain as a file object — use 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. |
| import_contacts_from_file | Import every contact or company from a file the user uploaded — a CSV or spreadsheet export, a .vcf of contacts, or a zip. Use this whenever they want more than a couple of records created from a file: it reads the whole file at once, so never read a contact list with read_file and create the records one at a time. Find the file first with search_graph_objects (type 'file') and pass its object_id, or pass part of the filename as name. Pass a description of what the file holds when the user gave one — it is what tells the column mapper that 'Ref' is a phone number. |
| search_gmail_messages | 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:jane@acme.com' for messages the user sent to someone, 'from:jane@acme.com' for messages they received, plus operators like subject:, newer_than:7d, and has:attachment. So 'show me the last 5 messages I sent to jane@acme.com' is query 'in:sent to:jane@acme.com' 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, tell the user to connect one at /user/integrations. Rare header-only connections cannot run query search — the tool says so; answer correspondence questions from the brain for those. |
| get_gmail_message | Fetch one Gmail message by its id from the user's connected mailbox, including the full plain-text body (rare header-only connections get headers and the snippet instead). Use this to read a message found via search_gmail_messages (which returns ids and snippets only), or when a triggering event hands you a Gmail message_id to analyze. |
| list_gmail_labels | List the labels in the user's connected Gmail mailboxes — system labels (INBOX, STARRED, ...) and the user's own labels, with their ids. Use it when the user refers to one of their labels by name. |
| create_gmail_draft | Create a DRAFT email in the user's connected Gmail mailbox, addressed to anyone — 'draft an email to jane@acme.com about X'. Nothing is sent: the draft lands in Gmail's Drafts folder for the user to review, edit, and send themselves. Compose a specific subject and a plain-text body (no HTML or markdown) in the user's voice. Use this whenever the user wants an email written to someone else; send_email remains only for mailing the user their own address. Only works on mailboxes connected under a legacy modify grant — current connections are read-only and cannot create drafts; the tool says so if not. |
| archive_gmail_message | Archive one Gmail message — it leaves the inbox but stays in All Mail, fully recoverable. Use only when the user asked for the archive; confirm first if it's your own suggestion. Only works on mailboxes connected under a legacy modify grant — current connections are read-only and cannot change the mailbox; the tool says so if not. |
| get_calendar_events | List events from the user's connected Google Calendar, ordered by start time — summary, start/end, location, organizer, attendees and their RSVP status, and a meeting link when there is one. With no time range it returns upcoming events from now. `time_min` and `time_max` are RFC3339 timestamps ('2026-08-19T00:00:00Z'), so 'what's on my calendar tomorrow' is time_min/time_max spanning that day; past ranges work too. `query` free-text matches event titles, descriptions, and attendees. For 'how many meetings…' questions over long ranges (a quarter, a year), set count_only=true — it sweeps the whole range and returns the total plus a per-month breakdown instead of the events themselves, so a 12-month count is one call. By default this reads the primary calendar; to read a named calendar ('my Family calendar'), first get its id from list_google_calendars, then pass calendar_id. If the result says no Google account is connected (or the account lacks calendar access), show the user the message and link them to /user/integrations/gmail. |
| list_google_calendars | List the calendars in the user's connected Google account(s) — name, id, whether it's the primary, and the user's access role. Use it to find a named calendar ('Family', 'Content schedule') before reading its events with get_calendar_events(calendar_id=…). If it says the account needs reconnecting, link the user to /user/integrations/gmail. |
| create_calendar_event | Create one new event on the user's Google Calendar — title (summary), start, and end are required; description and location are optional. Use only when the user asked for the event — it lands on their real calendar immediately. start/end are RFC3339 timestamps ('2026-08-25T19:00:00-04:00'). By default the event goes on the primary calendar; to use a named calendar, get its id from list_google_calendars and pass calendar_id. Attendees are deliberately not supported — Google would email them invites. If the result says the account needs reconnecting, link the user to /user/integrations/gmail. |
| update_calendar_event | Update one Google Calendar event — change its title (summary), description, location, or start/end times. Only the fields you pass change; everything else stays. Get the event's id (and its calendar_id, if it isn't on the primary calendar) from get_calendar_events first. Use only when the user asked for the change — edits land on their real calendar immediately, and other attendees can see them. start/end are RFC3339 timestamps ('2026-08-25T19:00:00-04:00'). |
| list_graph_objects | List objects in the user's graph, newest first, with counts by type. The graph is their personal CRM's object store: person, company, hubspot_contact, linkedin_connection, file, fact, web_link, note, connected spaces, and more. Filter by type to browse one kind ('what files do I have?', 'list my facts'), or omit it to see what the graph holds overall. For finding something by name, prefer search_graph_objects. |
| get_graph_object | Get one object from the user's graph, with the objects connected to it (its edges, e.g. a person's spaces, a note's subject). Identify it by object_id (exact, preferred — search and list return it) or by name. Use this when the user asks about a specific thing in their graph, or to follow a connection you found on another object. |
| set_graph_object_fields | 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). |
| search_graph_objects | 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. Returns matches with their object_id for follow-up with get_graph_object. |
| create_graph_object | Create a new object in the user's graph. Use when they ask to add something — a project, note, fact, web link, person, company, product, event, group, tag, or prompt. If an object of the same type and name already exists it is returned instead of duplicated; pass allow_duplicate=true only when the user confirms they want a second one. Returns the object with its object_id for follow-up connecting. |
| create_tracker | Set up a standing search the user wants watched — 'track LinkedIn posts that mention hubspot', 'track tweets mentioning @dharmesh', 'watch acme.com/pricing for changes'. query is what to watch for; tracker_type says where to watch (LinkedIn posts unless they ask for tweets/X or a specific page URL — a URL to watch means web_page, with the URL in url and query as a short label for it). linkedin_post and twitter_search requests become a daily cloud agent that emails a digest of new posts; web_page creates a tracker in their brain that runs daily and emails changes, filtered by the prompt. Always give the user the returned page_url as a link — that page is where they review and manage it. |
| connect_graph_objects | Connect two objects in the user's graph with a directed edge — e.g. connect a file or note to a project, a person to a company, a web link to an event. Use the object_ids that create, search, or list returned. connection_type names the relationship ('part_of', 'works_at', 'related_to', …); connecting twice with the same type is a no-op, not an error. One name is not free-choice: when the user says somebody introduced or referred them to someone, the edge type is exactly 'introduced', running from the person who made the introduction to the person they introduced. That is the only spelling anything reads, so 'intro' or 'referral' records the fact and hides it. |
| delete_graph_object | Delete an object from the user's graph. Use only when the user explicitly asks to delete or remove a specific object — never to tidy up on your own initiative. The delete is soft: the object disappears from lists, search, and chat, but its data is retained and a restore is possible later. Identify the object by object_id (search_graph_objects returns it). Only objects the user owns can be deleted, and never their root user node. In chat, this tool does not delete directly — it returns instructions for showing the user a confirmation card, and the card performs the delete. |
| delete_graph_objects | Delete EVERY object of one type from the user's graph, however many there are: what to reach for when they ask to clear out a whole category ('delete all my HubSpot contacts') rather than one record. Deleting one object is delete_graph_object instead. This delete is permanent, and at this scale it is the only kind that helps: a synced portal can be millions of records. Use only when the user explicitly asked for a category to go, never on your own initiative, and name one type per call (contacts and companies are two calls). In chat this tool deletes nothing: it counts the records and returns instructions for a confirmation card, and the user's click starts the deletion. |
| record_interaction | 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. |
| merge_graph_objects | 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), a merged_from audit marker is appended, and the duplicate is deleted. This is destructive and cannot be undone: ALWAYS show the user both records side by side and get an explicit yes before calling. keep_id survives; merge_id is deleted. |
| purge_graph_object | 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. To remove a single connection and keep both objects, use disconnect_graph_objects instead. |
| disconnect_graph_objects | Delete one connection between two objects in the user's graph — the edge from_object_id -> to_object_id of the given connection_type, nothing else; both objects stay. Use get_graph_object to see an object's connections and their types and directions first. |
| find_paths | How two objects in the user's graph are connected: the shortest chain of real relationships between them, up to 3 hops, e.g. person -[worked_with]- person -[works_at]- company. Only deliberate relationships count — bulk-import and system-inferred edges are excluded, so a path is evidence. Returns the path as a list of hops, and an EMPTY list when there is no connection: report that honestly, never invent a path. |
| mutual_connections | 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. |
| similar_objects | 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. |
| set_follow_up | 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. |
| query_graph_objects | 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. |
| quiet_contacts | 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. |
| referral_paths | 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. |
| ask_about_hubspot_contacts | Query the user's HubSpot contacts — the people synced from the HubSpot portals they've connected. Use this for any question about their CRM contacts: engagement filters ('show me people with more than 10 page views'), lifecycle and pipeline ('how many customers do I have?', 'leads with an open deal'), firmographics ('contacts at Google', 'people in Boston'), attribution ('which source brought the most contacts?'), email activity, deal amounts, lead scores, or form conversions. Answered by generating a read-only SQL query over the synced contact table, so it returns columns and rows rather than prose — summarize the rows for the user, and say how many there were. If it reports no contacts synced, tell them to import at /hubspot/import. Keep the question under 500 characters. |
| ask_about_hubspot_companies | Query the user's HubSpot companies — the companies synced from the HubSpot portals they've connected. Use this for any question about their CRM companies: firmographics ('software companies with more than 100 employees'), lifecycle and pipeline ('companies with an open deal', 'how many customer accounts?'), location ('companies in Boston'), funding and size ('which companies raised money?', 'biggest companies by revenue'), or attribution. Answered by generating a read-only SQL query over the synced company table, so it returns columns and rows rather than prose — summarize the rows for the user, and say how many there were. If it reports no companies synced, tell them to run a company sync for their portal. Keep the question under 500 characters. |
| get_hubspot_summary | Overview of the user's synced HubSpot data: which portals they have connected, how many contacts and companies came from each, and when each was last synced. Use this for questions about how much HubSpot data they have, which portals are connected, or whether their data is up to date — and to check they have any data before promising an answer. For questions about the records themselves, use ask_about_hubspot_contacts or ask_about_hubspot_companies. |
| search_hubspot_crm | 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 dshah@hubspot.com', '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. |
| list_integrations | What the user has connected, and what they could connect. Returns every integration available to this account with `connected` true/false, the accounts behind it, the tools it unlocks, and the URL to connect or manage it. Call this BEFORE telling anyone to connect anything, and before saying a source is unavailable: guessing is how the assistant has told people to connect accounts they already had. An integration missing from the list is not offered to this user at all, so do not suggest it. `suggested` is what is worth connecting next, best first, each with the payoff in the user's terms: use it when asked what would help, and lead with the first one rather than listing the shelf. Connecting is a browser grant: hand the user the URL, never claim to have done it. |
| get_integration_connect_url | The URL that starts connecting one integration, for surfaces that cannot render a card (Slack, SMS, email). In chat, show the integrations_list card instead. Never claim to have connected anything: only the user can grant it, in their browser. |
| disconnect_integration | Disconnect one connected account. Destructive and not undoable: disconnecting a HubSpot portal also deletes every record it synced. Never call this to check anything; call list_integrations for that. Only call it when the user has asked to disconnect, in their own words, naming what. |
| parse_invoice_pdf | 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. |
| search_connections | 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. |
| get_connection_details | Get the full profile for one of the user's LinkedIn connections: work history, education, skills, and their About summary. Use this after search_connections when you need depth on a specific person. Identify them by name, or by linkedin_url for an exact match. A found:false response carries the user's imported-connection count: if no_imported_data is set, nothing was searched, so report the missing import rather than a missing person. |
| ask_about_connections | Ask a free-form question about the user's LinkedIn connections that the other tools can't express: aggregates and rankings ('which companies do I know the most people at?'), date ranges ('who did I connect with in 2023?'), location filters ('my connections in Boston'), or several conditions at once ('founders in New York I connected with this year'). Answered by generating a read-only SQL query, so it returns columns and rows rather than prose. Prefer search_connections for a simple name/company/title lookup — it is faster. Keep the question under 500 characters. |
| ask_about_invitations | Ask a question about the user's LinkedIn invitations — the requests they sent and received. This is the only tool that can see invitations. Use it for questions like 'which invitations I sent were never accepted?', 'who invited me recently?', or 'how many requests did I send last month?'. Acceptance is inferred by checking whether the other person now appears among their connections. Note the LinkedIn export only covers recent and still-pending invitations, not lifetime history — say so when it matters. Returns columns and rows. Keep the question under 500 characters. |
| get_connections_summary | Overview of the user's imported LinkedIn data: how many connections, invitations and messages they have, when it was last imported, and the companies they know the most people at. Use this for questions about the shape of their network as a whole, or how much data is loaded. |
| get_my_linkedin_posts | The user's own LinkedIn posts with engagement numbers (reactions, likes, comments, shares): newest first by default, their earliest with sort='oldest', or their best-performing with sort='top'. sort='top' is what answers 'my top 10 posts', 'my best posts' and 'what performed well'. Answer those from here rather than from linkedin_analytics, which needs an OAuth grant this user may not have given. The response always includes total_posts_stored, so this also answers 'how many posts do I have?' and 'what was my first post?'. Use it for questions about their posting activity and performance — 'what did I post last week?', 'what's the average number of likes on my last 5 posts?', 'which recent post got the most comments?'. Compute averages and comparisons from the returned rows. like_count is the thumbs-up reaction alone; total_reaction_count is all reaction types combined. Pages: when has_more is true, call again with offset set to the next_offset from the response to continue through their history. |
| linkedin_analytics | The user's LinkedIn post analytics from LinkedIn's own API (their connected account) — impressions, unique members reached, reactions, comments, and reshares. Use for questions like 'how many impressions did I get last month?' or 'how are my posts performing?'. Omit dates for lifetime totals; pass start_date/end_date for a window; set daily=true (with one specific metric) for a per-day series to describe trends. Numbers are live from LinkedIn, unlike get_my_linkedin_posts whose per-post counts come from a periodic sync. |
| get_messages_summary | Overview of the user's imported LinkedIn messages (DMs): how many messages and conversations they have, the date range covered, and how many they sent versus received. Use for 'how many messages do I have?' and questions about the shape of their message history. |
| top_message_correspondents | The people the user has exchanged the most LinkedIn messages with, most-messaged first, with how many messages and when they last spoke. Use for 'who have I exchanged the most messages with?', 'who do I talk to most on LinkedIn?', and similar. |
| search_linkedin_posts | Search public LinkedIn posts by keywords and store the results 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. |
| analyze_recent_posts | The raw material for an engagement analysis of the user's most recent LinkedIn posts: per-post stats, a sample of the actual comments left on them (who said what), and the LinkedIn headlines of everyone who engaged. Use when they ask for an analysis of their recent posts, what people are saying about them, or who their audience is. From the returned data, cover: what's getting traction, one or two key insights from the commentary including its overall sentiment, and an audience breakdown (roles, seniority, industries) drawn from the headlines. When comments_synced is false the engagement sync has not run for them yet: analyze the stats alone and say the comment data is still syncing. |
| job_changes | People in the user's network who have moved to a different company since we last looked, newest first, with where they were and where they are now. Use when they ask who has changed jobs, who has moved recently, whether anything has changed at their contacts, or who is worth congratulating. Also the read behind a scheduled watcher: on a run with nothing new it says so and there is nothing to report. Reports a change of employer only, so a rewritten job title at the same company does not appear. NOT a list of who to contact, NOT the history with one person, NOT news about a company. |
| send_text_to_user | Send a short text message (iMessage/SMS) to the user's own phone — the number they verified on the iMessage integration. Use it to notify them of something important or time-sensitive: a reminder they asked for, a result from a long-running task, an alert a scheduled agent was set up to watch for. The recipient is always the user themself; no other number can be reached. If no verified number is on file, the response says so — tell them to connect one at /user/integrations/imessage. Keep messages short and concrete; there is a rate cap, so never use this for routine chatter. |
| set_notification_emails | 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 'Exec Briefing' built from their Second Brain; post_reports is the recurring 'Insights from your LinkedIn posts' traction report; process_emails are the one-off notices when an import or sync finishes. 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. |