Get the user's full Remoet profile. IMPORTANT: Always call this first before making any changes.

PROFILE GAP ANALYSIS: After fetching, run a full evaluation and proactively surface findings ranked by impact. Offer to fix each issue on the spot. Be encouraging, not critical — "Your profile has a solid foundation, here are a few things that could make it stand out."

CHECK 1 — SUMMARY & DISCOVERABILITY (highest impact):

• Summary empty or weak? Under 100 chars, no tech stack mentioned, no years of experience, or no differentiator = needs rewriting. See update_profile for guidance. This is the first thing companies read.

• Call get_visibility. If NONE, suggest STARRED — creates a two-way match where starred companies can discover the user.

• Check get_starred_listings. Zero stars = empty job feed. Help them find and star companies matching their tech stack.

• Cross-reference starred companies' tech stacks against the user's skills. Flag mismatches that add noise.

CHECK 2 — PROJECTS (what makes them special?):

• Zero projects = #1 gap for junior/mid developers. Projects differentiate candidates with similar job histories. Ask about side projects, open source, personal apps, hackathons, scripts, blogs.

• Projects without URLs or descriptions are barely better than no projects.

CHECK 3 — WORK HISTORY (can they do this?):

• Zero jobs = critical gap. Walk user through adding experience or importing from CV.

• Jobs without descriptions = missed opportunity. Each role should explain what was built, what tech was used, and what impact it had.

• Descriptions without measurable impact? Push for specifics: users served, performance gains, revenue impact, team size. "Built React frontend" → "Built React frontend serving 50K monthly users, reducing load time by 40%."

• Technologies array empty on jobs with tech in the description? Ask to add them — they feed into job matching.

• Remote experience not highlighted? If they've worked remotely, ensure isRemote: true — remote hiring managers look for proof.

CHECK 4 — BASICS (will they even look?):

• Avatar missing? Profiles without photos get less engagement.

• Location vague? "Europe" is too broad. Companies need timezone and jurisdiction. "Lund, Sweden" is specific.

• GitHub/LinkedIn missing? Table stakes for developers.

CHECK 5 — EDUCATION:

• Empty education? Ask about degrees, bootcamps, certifications, notable courses.

If the user shares a CV, resume, or website, populate their entire profile (update_profile, create_work_experience, create_project, create_education), then search and star matching companies, and finally surface relevant jobs — all in one go.

Get the user's work experience / job history (each entry returns its ID for update/delete). Use this to ground anything you say about the user's background. After fetching: flag duplicates, placeholder data, missing descriptions, missing technologies arrays, or missing measurable impact. Each weakness is something you can fix on the next turn — surface them ranked by impact and offer to fix.

Get the user's projects and portfolio items (each entry returns its ID for update/delete). For junior/mid developers, projects are the #1 differentiator — two candidates with similar job histories are separated by what they built. Flag: zero projects (massive gap, ask about side work, OSS, hackathons, scripts, blogs), projects without URLs, projects without technology arrays. Offer to fix each via update_project or create_project.

Get the user's education history (each entry returns its ID for update/delete). Education matters most when a user has limited work history — for senior candidates it's a tiebreaker. Flag: empty education (ask about degrees, bootcamps, notable certifications, MOOCs), entries without dates, entries without field of study. Offer to fix each via create_education.

Get the user's social and professional links (GitHub, LinkedIn, Twitter, website, etc.). These are table-stakes for most companies — recruiters click them before reading anything else. After fetching, flag missing critical links: GitHub is mandatory for engineering roles, LinkedIn is expected by most companies, a personal site/portfolio is a strong differentiator. If any are missing, offer to add them via update_profile.

Update the user's Remoet profile. Only provide the fields you want to change — omitted fields are left as-is. Pass null to clear a field. Always read the current profile first with get_profile. If the source data (CV, website, etc.) is missing information for a field, ask the user rather than guessing or leaving it blank. Write professional, clean descriptions — never copy placeholder text like "lorem ipsum".

SUMMARY WRITING GUIDE: The summary is the most important field — it's the first thing companies read. A strong summary follows this pattern: [Role] with [X years] experience in [core tech stack]. [One differentiator or achievement]. Example: "Senior Full-Stack Developer with 8 years of experience in React, Node.js, and AWS. Built and scaled a SaaS platform serving 200K users." Keep it under 500 characters — enough for a second differentiator sentence if needed. Avoid generic fluff like "passionate developer" or "team player" — be specific and quantifiable.

Add a work experience entry to the user's profile. Before creating, always check existing entries with get_work_experience to avoid duplicates. If the source data is incomplete (e.g. missing dates, company name, or description), ask the user to fill in the gaps rather than guessing. Dates must be accurate — ask the user to confirm approximate dates if the source only says something like "2019" or "Summer 2020". Write clear, professional descriptions. Do not fabricate or embellish information.

DESCRIPTION QUALITY: Every job description should answer WHAT (built/designed/led what), HOW (which technologies, methodologies), IMPACT (users served, performance gains, revenue, uptime), and SCOPE (team size, user base). If the user gives a vague description like "Worked on the backend", ask follow-up questions: "What did you build specifically? What tech did you use? How many users or requests did it handle? What was the team size?" Push for measurable outcomes — numbers make descriptions 10x stronger.

TECHNOLOGIES: Always populate the technologies array — it feeds into job matching. If the description mentions technologies not in the array, ask to add them.

Update an existing work experience entry. Only provide the fields you want to change — omitted fields are left as-is. Use get_work_experience first to find the ID. Prefer this over delete + recreate — it preserves the entry ID.

Remove a work experience entry from the user's profile. Use this to clean up duplicates, placeholder/test entries, or obviously incorrect data. Always confirm with the user before deleting entries that look like they could be real data.

Add a project to the user's portfolio. Before creating, always check existing projects with get_projects to avoid duplicates. If the source data is incomplete (e.g. missing description, technologies, or dates), ask the user to fill in the gaps. Dates must be accurate — ask the user to confirm if unclear. Write clear, professional descriptions. Do not fabricate or embellish information.

PROJECT COACHING: Many users underestimate what counts as a project. Help them recognize work they might not think of: side projects, open-source contributions, hackathon entries, internal tools, scripts that saved time, blogs/tutorials, personal apps, browser extensions, Discord bots. Even small projects demonstrate initiative and practical skills. For junior/mid developers, projects are the #1 differentiator — two candidates with similar job histories are separated by their projects.

Update an existing project. Only provide the fields you want to change — omitted fields are left as-is. Use get_projects first to find the ID. Prefer this over delete + recreate — it preserves the entry ID.

Remove a project from the user's portfolio. Use this to clean up duplicates, placeholder/test entries, or obviously incorrect data. Always confirm with the user before deleting entries that look like they could be real data.

Add an education entry to the user's profile. Before creating, always check existing education with get_education to avoid duplicates. If the source data is incomplete (e.g. missing dates, field of study, or institution URL), ask the user to fill in the gaps. Dates must be accurate — ask the user to confirm approximate dates if the source is vague. Do not fabricate or embellish information.

Update an existing education entry. Only provide the fields you want to change — omitted fields are left as-is. Use get_education first to find the ID. Prefer this over delete + recreate — it preserves the entry ID.

Remove an education entry from the user's profile. Use this to clean up duplicates, placeholder/test entries, or obviously incorrect data. Always confirm with the user before deleting entries that look like they could be real data.

Search for companies on Remoet. Only companies are returned (not freelance platforms or job boards). Returns a summary for each company — use get_listing with the slug to see full details (description, perks, URLs).

CRITICAL: Only star companies whose tech stack OVERLAPS with the user's skills. A JavaScript developer should NOT star a company that only uses Go, Rust, or Java. Stars are the user's noise filter — irrelevant stars pollute their job feed with jobs they can't apply to. Every star must make sense for THIS user.

Best approach: 1) Read the user's profile to understand their tech stack and experience, 2) Search listings filtering by the user's actual technologies, 3) Review results and only star companies where the tech stack genuinely matches.

SEARCH LOGIC: Relevance scoring ranks results by: exact name match (+10), name starts with query (+5), name contains query (+2), and each tech stack match (+20 per matching technology). Text search also matches description and about fields. Technologies are auto-normalized (e.g. "ts" → "TypeScript", "react" → "React"). Combine searchQuery and techStack for best results.

If the user's interests aren't clear from their profile, ask them what kind of companies they're looking for.

Get the list of companies the user has already starred. Returns a summary per company — use get_listing with the slug for full details. Use this to audit their current stars — if any starred company's tech stack doesn't overlap with the user's skills, suggest unstarring it (but warn that unstarring consumes unstar budget).

STAR QUALITY AUDIT: Cross-reference the user's profile technologies against each starred company's tech stack. Flag companies with zero overlap — e.g. a React/Node developer starring a company that only uses Go and Rust. Suggest companies they should star but haven't — search for companies matching their tech stack and compare against current stars. A curated star list is the foundation of a useful job feed.

Get detailed information about a specific company listing by its slug. Use this to review a company before deciding whether to star it. Returns the company's full description, tech stack, perks, job count, and URLs. Pair with get_star_count to check budget before starring.

Star/save a company listing. Starring subscribes you to their job postings — starred company jobs appear in get_starred_jobs. IMPORTANT: Only company-type listings can be starred. Starring is FREE — it does not consume budget. However, there is a limit on how many active stars you can have at once (based on your plan). Call get_star_count to check remaining star slots. CRITICAL: Only star companies where the user's tech stack genuinely overlaps with the company's tech stack. A React/Node developer should NOT star a company that only uses Go or Java. Irrelevant stars pollute the job feed with noise. Every star must be a deliberate, high-quality match.

Remove a star from a company listing. WARNING: Unstarring consumes from your unstar budget (per billing period). This prevents unlimited cycling of stars. Call get_star_count first to check your remaining unstar budget. Only unstar if the company is truly not relevant.

Get your star and unstar budget status. Starring is free but capped at maxActiveStars. Unstarring consumes from a per-period unstar budget to prevent unlimited cycling. Returns: currentStars (active stars), maxActiveStars (cap for your plan), starSlotsRemaining (how many more you can star), unstarBudgetUsed (unstars this period), unstarBudgetLimit (max unstars per period, or "unlimited"), unstarBudgetRemaining (unstars left, or "unlimited"), resetsAt (when the unstar budget resets), and plan (your subscription tier). Help the user make every star count — choose companies carefully.

Get job postings from your starred companies. This is the user's main job feed — if the user has no stars, this returns nothing. Quality depends on starring the RIGHT companies (ones whose tech stack matches the user's skills). If results are empty or poor, check get_starred_listings and suggest better stars. Starring is free so they can star more companies to improve their feed. Supports filtering by search query, location, tech stack, remote policy, experience level, and minimum salary. Results are paginated. Use save_job to bookmark good matches so the user doesn't lose them.

SEARCH STRATEGY: For job recommendations, run multiple searches and merge results: first a broad search (no filters) to see what's available, then targeted searches by the user's top 1-2 technologies. This ensures comprehensive coverage — a single filtered query can miss good roles. The techStack filter uses AND logic — specifying ["React", "TypeScript", "Node.js"] only returns jobs matching ALL three, so start with 1-2 core technologies, not the user's entire stack. If results are sparse, drop filters one at a time. Use searchQuery for role-based searches ("senior engineer", "frontend", "platform") and techStack for technology-based filtering.

Save a job to the user's list for later. Supports both AI-extracted jobs (from get_starred_jobs) and internal partner jobs. This gives the agent memory across sessions — saved jobs persist so the user doesn't lose track of interesting roles. Optionally attach a note (e.g. "Great fit for React skills", "Follow up next week"). Each job can only be saved once.

Get the user's saved jobs list. This is the user's job search memory — shows all jobs they've bookmarked across sessions, with notes and job details. Includes both AI-extracted jobs and internal partner jobs (see jobType field). IMPORTANT: Always call this before get_starred_jobs when helping with job search — it shows the user's existing pipeline so you can avoid re-recommending jobs they've already saved or dismissed. Paginated, newest saves first. Each saved job includes isActive and deactivatedAt fields. If isActive is false, the job is no longer appearing on the company's careers page — this usually means it was filled or expired, but could also be a temporary scraper issue (there is a grace period before deactivation). If job is null, the listing was deleted entirely. Suggest the user check the company's careers page directly if a saved job they care about gets deactivated.

Update the note on a saved job. Use this to add context, track application status, or record follow-up reminders. Pass null to clear the note.

Remove a job from the user's saved list. Use get_saved_jobs first to find the saved job ID. Confirm with the user before removing.

Get the user's current profile visibility setting. Three states: NONE (hidden — this is the default for new accounts), STARRED (visible only to starred companies — the recommended setting), ALL (visible to every company on Remoet). If the user is at NONE and has starred companies, flag it: they're cutting off a key benefit of the platform (being discovered by companies they already like). Offer to switch to STARRED via update_visibility.

Update who can see the user's profile in company candidate lists. There are 3 levels:

• NONE — Profile is hidden from all companies. Maximum privacy.

• STARRED — Profile is visible ONLY to companies the user has starred. This is the recommended setting and the default — it means companies you've chosen to follow can discover you as a candidate, but no one else can.

• ALL — Profile is visible to every company on Remoet. Maximum exposure, but less privacy.

Always explain the trade-offs to the user before changing this. STARRED is the sweet spot for most users — it creates a two-way match (you follow them, they can find you).

Get the user's job digests — weekly email summaries of new jobs from their starred companies. Returns the 20 most recent digests. For weekly email summaries only. Always use get_starred_jobs for real-time job searching — digests are delayed (free tier is 1 week behind the current scrape) and less interactive. Only use this tool if the user specifically asks about their digests or email summaries.

Get a specific digest by ID. Returns the full digest content — a markdown-formatted summary of jobs found from the user's starred companies during that period. Each job entry includes the title, application URL, salary, remote policy, experience level, and tech stack. Note: Free tier digests are 1 week behind the current scrape — the jobs shown may no longer be open. For real-time jobs, use get_starred_jobs instead.

List approved apps built on the Remoet platform. These are community and official apps that extend Remoet's functionality. Each app has a repo URL for deployment and a demo URL to try it out. Use this to help users discover tools that complement their Remoet workflow — e.g. portfolio sites, CV generators, job trackers, etc. You can filter by category or tag.

Get all the user's link tree pages (each returns its ID and slug). Link trees are shareable single-page URLs the user can put on a CV, email signature, or job application — Remoet tracks views and clicks per link, so recruiter engagement is measurable. If the user has none, suggest creating one via create_linktree pulling their social links from the profile.

Get a specific link tree page by its public slug. Returns the page content plus engagement data (views, clicks per link) — useful if the user asks "has anyone looked at my link tree?". Use get_linktrees first if you need the slug.

Create a link tree page — a shareable page with the user's links (social media, portfolio, GitHub, etc.). Link tree limits: Free 1, Pro 10, Max unlimited. The slug becomes the public URL. Slug rules: 5-20 characters, lowercase letters, numbers, and hyphens only, cannot start/end with a hyphen. Must be unique. Use the user's name or handle as a base for the slug. Pull links from the user's profile (get_profile) — githubUrl, linkedinUrl, twitterUrl, url, etc.

TIP: Suggest the user adds their link tree URL to their CV or job applications. Remoet tracks views and link clicks, so they can see if a recruiter has opened it.

Delete a link tree page. Use get_linktrees to find the ID first. Confirm with the user before deleting.

Apply to an internal job posting on behalf of the user. The job must be published and not expired. The user can only apply once per job — duplicate applications are rejected.

IMPORTANT: Before applying, confirm with the user that they want to apply. Review the job details (use get_starred_jobs or get_listing) and cross-reference against the user's profile. Flag any gaps between the job requirements and the user's skills — e.g. "This role asks for Go experience which isn't on your profile. Still want to apply?" This helps the user make informed decisions and avoids wasting applications. Do NOT apply to jobs without the user's explicit consent.

Only works for internal jobs (applicationType: "internal"). For external jobs, direct the user to the applicationUrl instead.

Get the user's job applications. Returns a paginated list with status, job title, company name, and timestamps. Use this to help the user track their application pipeline. Filter by status to focus on active applications, pending offers, etc.

Get details of a specific job application by ID. Returns the application status, job info, company info, and timestamps.

Withdraw a job application. This is irreversible for applications that have been accepted or rejected. Confirm with the user before withdrawing.

Accept a job offer. Only works when the application status is "offer_extended". Confirm with the user before accepting.

Reject a job offer. Only works when the application status is "offer_extended". Confirm with the user before rejecting.

Add a private note to a job application. Notes are only visible to the user (not the company). Use this to help the user track thoughts, prep notes, follow-up reminders, or any context about the application. Max 1000 characters.

Get the timeline of events for a job application. Shows status changes, notes, messages sent, interview scheduling, and other milestones. Events are sorted chronologically (oldest first). Public events are visible to both parties; private events (like notes) are only visible to the user.

Send a message to the company on a job application. Messages are visible to both the user and the company. Use this for follow-ups, questions about the role, or any communication with the hiring team. Max 1000 characters.

IMPORTANT: Do NOT write or draft messages for the user. Ask the user to write their own message — it should be in their voice, not yours. You can remind them to keep it concise and specific, but the words must be theirs. Once they give you the message text, confirm they're happy with it before sending.

Get the message thread for a job application. Shows all messages between the user and the company, sorted newest first. Paginated.

Get the user's current subscription plan, all plan limits, and today's usage. Call this when a limit is hit to show the user where they stand and what upgrading would unlock. Returns plan tier, star caps, unstar budget, daily request limits, job data delay status, link tree cap, and today's MCP/API request counts.

Get the user's current usage against every budget the platform enforces: active star count vs star cap, unstars used this month vs monthly unstar budget, MCP requests made today vs daily MCP cap, REST API requests made today vs daily REST cap. Each budget includes a "resetsAt" ISO timestamp so you can tell the user exactly when the counter clears.

Calling this tool is free: it does not count against the daily MCP cap or the API key's request count, so check eagerly. Call it when the user asks "how close am I to my limit?" or "when does X reset?", or before firing 3+ write tools in a row (star_listing, update_profile, apply_to_job, etc.) so you can pace yourself. A limit value of "unlimited" means no cap for that budget.

Get a Stripe Checkout URL the user can open to upgrade their subscription. This tool does NOT charge the user — it only returns a link; payment happens in the browser when the user completes Stripe Checkout. Present the "checkoutUrl" as a clickable link. Supports upgrades only: free→pro, free→max, pro→max. For downgrades or cancellation, direct the user to https://www.remoet.dev/settings.

Confirm with the user before calling this. Note: for a user who already has a paid subscription, changing tier (pro→max) may apply IMMEDIATELY with prorated billing against their existing payment method (response "message" instead of "checkoutUrl") — i.e. it can charge without a checkout step, so get explicit confirmation first. free→paid always returns a checkoutUrl (no charge until the user completes Stripe Checkout).

This tool is environment-aware. The response includes an "environment" field (local | stage | production). Only "production" charges real money — local and stage run Stripe in test mode (the response includes a sandboxNote field with test-card instructions). Always tell the user which environment they're entering before they click through.