insaight
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INSAIGHT_HOME | No | Directory where data lives (default: ~/.insaight). Override to use a custom location. | |
| REFLECT_EVERY | No | Number of outreach outcomes before reflection is proposed (default: 10). | |
| APIFY_API_TOKEN | Yes | Your Apify API token, used for scraping LinkedIn data. | |
| ANTHROPIC_API_KEY | No | Optional Anthropic API key, used for categorizing posts. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_accountsA | List all tracked LinkedIn accounts (companies and profiles) in the database. Returns each account's slug (short name), full URL, post count, and date of most recent post. ALWAYS call this first to discover what accounts are available and learn the correct slugs to use in other tools. |
| list_postsA | Return a slim index of posts (metadata + 150-char snippet, NO full content). Use this to survey what posts exist before deciding which ones to read in full via get_posts(). Fetching slim records first is far more token-efficient. Args: account: Slug (e.g. "acme-charging") or full LinkedIn URL. Empty = all accounts. Use list_accounts() to find slugs. category: Filter by semantic category (e.g. "product", "hiring"). days_ago: Only posts from the last N days (0 = no limit). min_engagement: Only posts where likes+comments+shares >= this value. limit: Max posts to return (default 30, max 100). |
| get_postsA | Fetch full content for a specific list of posts by their URNs. Use this after list_posts() to read only the posts you actually need. Accepts up to 20 URNs per call. URNs come from the 'urn' field in list_posts results. Args: urns: List of post URN strings to fetch (max 20). |
| search_postsA | Full-text search across post content (case-insensitive keyword/phrase match). Returns full content for matched posts only — use for targeted lookups rather than open-ended browsing (use list_posts for that). Args: query: Word or phrase to search for in post text. account: Slug or full URL to restrict search to one account (optional). days_ago: Only search posts from the last N days (0 = no limit). limit: Max results (default 15, max 50). |
| get_statsA | Return a DB-wide overview: total posts, accounts, date range, category breakdown. Useful for a quick orientation before diving into posts. |
| scrape_profileA | Scrape fresh LinkedIn posts from any company or personal profile URL via Apify and store them in the database. Works for profiles NOT yet in the database. Use this when the user asks about a LinkedIn account that list_accounts() doesn't return, or when they want up-to-date posts for an existing account. Requires APIFY_API_TOKEN to be set in the project .env file. Args: url: Full LinkedIn URL of the company or person to scrape. Examples: https://www.linkedin.com/company/acme-charging https://www.linkedin.com/in/williamhgates max_posts: Maximum number of posts to fetch (default 30, max 100). |
| scrape_peopleA | Scrape and store company employees/leadership from LinkedIn via Apify. Results are stored in the database so subsequent calls to list_people() are instant without any Apify cost. Run this once per company; re-run only when you need fresher data (people data is updated by upsert, not duplicated). Args: url: Full LinkedIn company URL. Example: https://www.linkedin.com/company/acme-charging job_titles: Optional list of job titles to filter by on LinkedIn. Example: ["CEO", "Founder", "CTO", "Head of", "Director"] Leave empty to scrape all visible employees (up to max_items). max_items: Maximum number of profiles to fetch (default 50, max 200). For leadership only, use 10–20 with specific job_titles. full_mode: If True, uses Full profile scraper mode ($8/1k) to also fetch about, experience, education, skills, certifications, languages, volunteer, projects, recommendations. Default False (Short mode, $4/1k) which returns only name, headline, location, current role. Use True when you need commonality-mining data for outreach. |
| scrape_person_profileA | Enrich ONE LinkedIn profile with full data (experience, education, skills, certifications, languages, volunteer, projects, recommendations, about). Use this when you need commonality hooks for outreach — e.g. overlapping past employers, shared schools, mutual volunteer work, common languages. The result is upserted into the people table, so existing short-mode data is preserved and the extended fields are merged in. Uses harvestapi/linkedin-profile-scraper ($4/1k without email, $10/1k with). Args: url: Full LinkedIn profile URL. Example: https://www.linkedin.com/in/williamhgates with_email: If True, also runs email search ($10/1k instead of $4/1k). Default False. company_url: Optional LinkedIn company URL to associate this person with. If empty, uses the person's current company from Apify (or falls back to the profile URL itself). |
| list_peopleA | List stored employees/leadership for a company from the local database. This is instant (no Apify call). If the result is empty, call scrape_people() first to populate the database for this company. Args: account: Slug (e.g. "acme-charging") or full LinkedIn company URL. Use list_accounts() to discover available slugs. role: Optional keyword to filter by — matched against name, headline, and job titles. Examples: "CEO", "founder", "sales", "engineer". Leave empty to return all stored people. limit: Max results to return (default 50). |
| scrape_post_commentsA | Scrape and store comments on a LinkedIn post via Apify. Use this to research who is engaging with a specific post — comments often reveal warm leads, decision-makers, competitor mentions, and pain points. Args: post_url: Full LinkedIn post URL. Either /posts/_-activity-XXX or /feed/update/urn:li:activity:XXX form is accepted. max_items: Max comments (and replies) to fetch (default 50, capped at 200). include_replies: If True, also fetch nested replies (default True). profile_mode: "short" (free profile data attached to each comment) or "main" ($0.002/profile, more author detail). Default "short". |
| list_commentsA | List stored comments for a post, ranked by likes desc then time. Provide either post_urn (e.g. "urn:li:activity:7451209045283254272") or post_url (the full LinkedIn URL — the URN is extracted automatically). Args: post_urn: Post URN. Use this OR post_url. post_url: Full LinkedIn post URL. The URN is extracted from it. limit: Max comments returned (default 100). min_likes: Only return comments with at least this many likes. include_replies: If False, only top-level comments are returned. |
| log_outreachA | Record an outreach message the user actually SENT. Call this when the user says they sent a message ("I sent it", "log this outreach"). The stored ledger replaces a manual sent-log: it powers prior-contact checks, reply-rate stats, and the reflection loop that learns what works. The response includes any prior contact with the same target — surface that to the user if present. Args: target_url: LinkedIn profile URL (or email address) of the recipient. message: The exact message text that was sent. target_name: Recipient's name (optional but recommended). company: Recipient's company (optional). channel: "dm" | "email" | "other" (default "dm"). variant: Which draft variant was sent: "warm" | "direct" | "follow-up" | free text. hook_type: Opening hook used: "question" | "statement" | "story" | "stat" | "commonality" | free text. Used for reply-rate breakdowns. notes: Anything worth remembering about this send (optional). |
| record_outcomeA | Record what happened to a sent outreach message. Call when the user says the target replied, booked a meeting, or went quiet. Identify the record by outreach_id, OR by target_url (resolves to that target's most recent pending message). The response includes reflection_due — when true, tell the user that enough outcomes have accumulated and offer to run the insaight-reflect skill. Args: outreach_id: Row id returned by log_outreach() (preferred). target_url: Alternative lookup: the target's URL/email. outcome: "replied" | "positive" | "meeting" | "ghosted". (positive = reply with clear interest; meeting = call booked) reply_snippet: A short quote from the reply — evidence for reflection. notes: Optional context (e.g. "replied after the follow-up nudge"). |
| list_outreachA | Query the outreach ledger, newest first. Use for prior-contact checks ("have I messaged this person?"), reviewing pending sends, or pulling recent messages for reflection. Args: outcome: Filter: "pending" | "replied" | "positive" | "meeting" | "ghosted". Empty = all. target: Substring match on target URL, name, or company. limit: Max records (default 30, max 100). full: If True, include full message text (use for reflection); default False returns a 150-char snippet. |
| get_outreach_statsA | Reply-rate breakdown of the outreach ledger: totals plus per-hook_type, per-variant, and per-channel rates (pending sends excluded from rates), and the current reflection state. This is the evidence source for the insaight-reflect skill — cite these counts (e.g. "question hooks: 4/9 replied") in any proposed memory update. |
| get_memoryA | Read the distilled outreach memory: the style guide and the strategy playbook. The draft-outreach and draft-post skills should read THIS (a few hundred tokens) instead of re-deriving style from raw history. Returns both files plus whether they've been learned yet and the reflection state. If not yet learned, fall back to reading recent outreach (list_outreach) or the Notion log, and suggest running insaight-reflect once a few outcomes are logged. |
| update_memoryA | Rewrite a memory file. ONLY call this after the user has approved the proposed content (the insaight-reflect skill shows a draft first — never overwrite memory silently). Args: kind: "style" or "playbook". content: The full new Markdown content of the file (not a diff). mark_reflection_done: Set True on the LAST update of a reflection run — resets the outcomes-since-reflection counter. |
| get_configA | Return the user's insaight config (Notion pages, company name/slug). Skills call this first to learn where to save research and whose voice to write in. The file lives at /config.md (default ~/.insaight/config.md); it is created with placeholder values on first call. If values are still placeholders, ask the user to edit the file. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/spirosbax/insaight'
If you have feedback or need assistance with the MCP directory API, please join our Discord server