Foundaree

Reviewed 1d ago.

• tools: 14 tools scanned
• metadata: scanned

No findings.

Tools (14)

• my_bookings

  List the booking requests people sent to the signed-in user: who asked, what they need, when, and whether it is still waiting for an answer. Use it when the user asks what is waiting on Foundaree, who wants to book them, or what they have not answered yet. Needs the user to have connected their Foundaree account. Lead with the ones still waiting, and offer to answer them with respond_to_booking.

• respond_to_booking

  Answer one booking request sent to the signed-in user. Get the id from my_bookings first. Always read the request back to the user and get a clear yes before calling this: it is their answer to a real person, not yours. Accepting does not arrange a time — the user still has to call them — so say that.

• my_connection_requests

  List the connection requests waiting for the signed-in user, and the ones they sent that are still pending. Use it when the user asks who wants to connect, or what is waiting on Foundaree. Offer to answer them with respond_to_connection.

• respond_to_connection

  Answer one connection request sent to the signed-in user. Get the id from my_connection_requests first. Tell the user who it is and what they wrote, and get their yes before calling this. Declining removes the request quietly; the other person is not told they were declined.

• set_my_availability

  Change the signed-in user's availability on their Foundaree profile: available (free for work now), open_to_offers (working, but will listen), or not_looking. This is public and it changes who finds them in search, so confirm with the user before calling it. Useful when they say they have finished a job, are fully booked, or want to be found again.

• find_and_ask

  Hand the whole errand to Foundaree: "find me a plumber in Kochi for Saturday morning". Foundaree searches, ranks the way its website does (people free now first), sends a booking request to the best one to three, and reports who was asked. Use this instead of search_people + request_appointment when the user wants it sorted rather than a list to choose from. Needs the user’s OWN name and phone number, which they gave you, and their clear yes before calling: real people will be contacted. Each person asked calls the user back if they can take it; nothing is confirmed until they do, so say that. Keep the returned errandId and use check_errand later to see who said yes. No account needed.

• check_errand

  Check on an errand started with find_and_ask: which of the people asked have accepted, declined or not answered yet. Use it when the user asks "did anyone get back to me?". Someone who accepted will call the user on the number they gave; Foundaree does not arrange the time.

• search_people

  Search public Foundaree profiles by free-text query and/or structured filters; give at least one. Free-text matches name, headline, bio, location, skills, experiences and projects. Each result carries `services` (what the person offers with prices), `languages`, `serviceAreas` (areas they cover) and `workingHours` (one entry per day, 24-hour HH:MM) when they gave them, so you can compare before booking. Each result has `updatedAt`, when the person last edited their profile: prefer recent ones when details matter, and say so when a profile is old. Among equally good matches, recently updated profiles rank a little higher. Structured filters: location (substring), area (neighbourhood substring; also matches the areas a person says they cover), language (a language they work in, e.g. Malayalam), workType (exact: local_service = blue-collar, hands-on work; professional = white-collar work), category (comma-separated trades/professions, OR semantics), availability (exact: available, open_to

• match_people

  Rank public Foundaree profiles against a list of required skills — use when the user describes a need ("a co-founder who knows React and has sold to enterprises", "a dentist in Pune", "someone to rewire my kitchen in Kochi") rather than searching for a known person. Give the required skills as `skills` (or describe the need in `q`; skill terms are then derived from it and `q` also narrows candidates by full text). location, area, workType, category, availability and lookingFor are hard filters; the skills only score: score = matched ÷ required (0–1), where a listed skill counts 1 and a term found in the person's category or lookingFor counts ½. Someone with 3 of 5 skills still appears, below someone with 5; ties break on availability (available first), then founding members (Foundaree's first 150 members), then recency. When nobody matches a single skill, the filtered candidates come back with score 0 and `fallback: true` instead of an empty list. Returns JSON with `items` (each: `pers

• get_person

  Retrieve the full public profile for a username, including skills, experiences, projects, `services` (what they offer with prices: name, price in whole currency units or null for "ask", currency, per job/hour/day/visit/session/month, from = starting price, note), `licence` (a registration number Foundaree's admin looked up on its public register, e.g. a doctor's NMC number: body, number, checkedAt; only once verified, and then "licence" is also in `verifiedBy`), and the phone, WhatsApp and contact email (`phone`, `whatsapp`, `contactEmail`) when the person made them public. `workProof`, when at least one kind is proven, is a count, not a score: "Proof: `proven` of `total`" over GitHub, website and LinkedIn (LinkedIn has no proof yet), with the facts of each proven one: `github` (public facts of a GitHub account they proved is theirs by signing in with it: repos, stars, followers, top languages, last push, and when Foundaree read them) and `website` (their website links back to this pro

• search_organizations

  Search public company and organization pages on Foundaree by name, what they do, or city: "design studios in Kochi", "a clinic in Pune", "startups building for farmers". Use it when the user needs a company or team rather than one person. Returns JSON with `items` (each: `username`, `name`, `description`, `website`, `location`, `pageUrl`) and `total`. Foundaree is new, so there may be few or none: say so rather than guessing. A company's open roles come from search_opportunities.

• search_opportunities

  Search public openings on Foundaree: jobs, freelance work, internships, projects, co-founder and advisory roles. Use it when the user is looking for work or a role ("React jobs in Bengaluru", "a co-founder role in fintech", "internships in design"), or asks what a company is hiring for. Matches the title, description, city and skills. Only open listings are returned unless `includeClosed` is true. Returns JSON with `items` (each: `username`, `title`, `type`, `companyUsername`, `location`, `description`, `skills`, `status`, `listingUrl`, `companyUrl`) and `total`. People apply on the listing page on Foundaree; this tool does not apply for anyone. Foundaree is new, so there may be few or none: say so rather than guessing.

• create_profile_draft

  Start a Foundaree profile for the user. Use it only when the user asks to join Foundaree, to be listed on it, or to create their own profile. Fill in only details the user gave about THEMSELVES: never about someone else, and never guess. Only `name` is required. Nothing is published: this saves a private draft and returns one link (finishUrl). The user opens it, checks the profile, signs in and taps Publish; until then nobody can find it. Show the user the link. It works once, for 7 days. Nobody is emailed or texted.

• request_appointment

  Send a booking request to one person on Foundaree, for the user: "book this plumber for Saturday morning", "ask this dentist for an appointment". Use it only when the user asked to book or contact that person, and only with the user's OWN name and phone number, which they gave you: never guess or reuse another number. Before calling, tell the user what you will send and to whom, and get their yes. The person sees the request on Foundaree and by email, and calls the user back on that number if they can take it; nothing is confirmed until they do, so say that to the user. Find the username with search_people or match_people first. One open request per phone number and person; a few per number a day.