get_activities
ChatGPTReturns the activity timeline for a single entity - notes, custom activities, meetings (calendar events + meeting/call summaries), and emails - newest first. WHEN TO USE: - "Recent activity on candidate X", "what's happened with X lately". - "Notes on X", "emails with X", "meetings/summaries for X", "custom activities for X". - "Summarize interactions with X" (fetch, then summarize the timeline). WHEN NOT TO USE: - Finding/counting candidates -> search_candidates. - A candidate's current title/company/tags/jobs -> search_candidates enrich=true. - Account-wide activity ("everything logged today") - this is per-entity only. REQUIRED WORKFLOW: 1. Resolve the entity to an id first: candidates via search_candidates. If a name matches multiple, ask which one. 2. Call get_activities with entity_type + entity_id. Optionally pass activity_types to narrow (e.g. only notes). ACTIVITY TYPES: - note: logged notes. - custom: custom activity-log entries (tenant-defined types). - meeting: calendar events (title/time/attendees) plus meeting/call SUMMARIES (summary text, not the full transcript). - email: emails exchanged (subject + body). Candidates only. ENTITY SUPPORT: - candidate: note, custom, meeting, email. (Jobs and other entities are not available yet - calling with an unsupported entity_type returns an error.) RESULTS: Returns {entity_type, entity_id, fetched_count, has_more_available, page, page_size, activities}. fetched_count is the number of activities loaded after merging requested types (NOT the full database total). Results are capped per type at 100 each (notes, emails, custom activities, calendar events, and meeting summaries). When has_more_available is true, tell the user additional activities may exist beyond what was fetched. When fetched_count > page * page_size, paginate with a higher page number to see more within the fetched set. Each activity: {type, time, title, body, author, attendees, source} - fields absent when not applicable (e.g. no attendees on a note). Activities are merged across types and sorted newest first.
get_candidate_custom_fields
ChatGPTLists the account's CANDIDATE custom fields - the resolution tool for filtering on custom fields via search_candidates. WHEN TO USE: - The user references a field that is not in the standard filter catalog ("filter by visa status", "candidates with notice period under 30 days") - it is probably a custom field. - Before building any custom_field.<id> filter. WHEN NOT TO USE: - Standard filters (name, skills, stage, ...) -> get_candidate_filters. - Do not call repeatedly - the field list does not change within a conversation. RESULTS: Returns {custom_fields}: [{id, name, field_type, choices, has_more_choices}]. field_type is one of: text, number, money, date, yes_no, single_select, multi_select. choices lists the valid options for select fields (capped; has_more_choices true when capped). Build the search_candidates filter with key "custom_field.<id>" and the payload shape the custom_field catalog entry documents for that field_type. Match the user's wording to a field NAME here - never guess ids.
get_candidate_filters
ChatGPTReturns the full catalog of filters accepted by search_candidates: for each filter its key, type, allowed conjunctions, value format, detailed usage guidance (when to use, when not to, common phrases, caveats, related filters), and a copy-ready example payload. WHEN TO USE: - Once per conversation, BEFORE the first search_candidates call. - When unsure which filter matches the user's request or how to format its values. - After a search_candidates validation error, to re-check the filter construction. WHEN NOT TO USE: - Job filters -> get_job_filters. - Do not call repeatedly in the same conversation - the catalog does not change. RESULTS: Returns {filters, usage}. Build search_candidates filter objects exactly from the documented examples - send only the documented fields; the server fills in type and status.
get_contact_custom_fields
ChatGPTLists the account's CONTACT custom fields - the resolution tool for filtering on custom fields via search_contacts. WHEN TO USE: - The user references a contact field that is not in the standard contact filter catalog ("filter contacts by relationship tier", "contacts in the EMEA region field") - it is probably a custom field. - Before building any custom_field.<id> filter on search_contacts. WHEN NOT TO USE: - Standard contact filters (name, client, contact_status, ...) -> get_contact_filters. - CANDIDATE custom fields -> get_candidate_custom_fields (the two field sets are separate; ids are not interchangeable). - Do not call repeatedly - the field list does not change within a conversation. RESULTS: Returns {custom_fields}: [{id, name, field_type, choices, has_more_choices}]. field_type is one of: text, number, money, date, yes_no, single_select, multi_select. choices lists the valid options for select fields (capped; has_more_choices true when capped). Build the search_contacts filter with key "custom_field.<id>" and the payload shape that field_type requires (same contracts as candidate custom fields). Match the user's wording to a field NAME here - never guess ids.
get_contact_filters
ChatGPTReturns the full catalog of filters accepted by search_contacts: for each filter its key, type, allowed conjunctions, value format, detailed usage guidance, and a copy-ready example payload. WHEN TO USE: - Once per conversation, BEFORE the first search_contacts call. - When unsure which filter matches the user's request or how to format its values. - After a search_contacts validation error, to re-check the filter construction. WHEN NOT TO USE: - Candidate filters -> get_candidate_filters. Job filters -> get_job_filters. - Do not call repeatedly in the same conversation - the catalog does not change. RESULTS: Returns {filters, usage}. Build search_contacts filter objects exactly from the documented examples - send only the documented fields; the server fills in type and status.
get_file_content
ChatGPTReads ONE file from get_files and returns its extracted plain text - not the original bytes. Same visibility as the download link: the caller can read exactly the files get_files lists for them. WHEN TO USE: - The user wants a file READ, summarized, compared, quoted, or reformatted: "summarize X's resume", "pull the terms from this contract", "rewrite this resume in my template" (read the text here, then produce the new document yourself). - Reformatting/template asks must end in a DOCUMENT: this server never generates files, so after writing the new version, CREATE it as a downloadable file (e.g. a PDF) using your own file-creation ability - do not just print the text. Only when your environment cannot create files, present the text and say so. WHEN NOT TO USE: - The user wants the FILE itself (to open, send, or keep) -> give the download_link from get_files as a markdown link instead. - Images or archives (png, jpg, zip, ...) - no text to extract; offer the download link. REQUIRED WORKFLOW: 1. Call get_files on the entity and pick the file (ask the user when several match). 2. Call get_file_content with the SAME entity_type and entity_id plus that file's id. RESULTS: Returns {entity_type, entity_id, file_id, filename, text} - the full extracted text, untruncated. Supported types: pdf, docx, doc, rtf, txt, html, odt. A scanned or image-based pdf has no text layer: the call fails with a clear message - relay it and offer the download link, never report the file as empty. COMMON MISTAKES TO AVOID: - Calling this to hand the file over - the user gets text, not the document. - Passing an id that did not come from get_files on the same entity. - Summarizing from the filename alone when the user asked about the contents.
get_files
ChatGPTLists the files/documents attached to a single entity - a candidate, contact, company, job, or deal - with filename, category, upload date, and a temporary download link. WHEN TO USE: - "What files does candidate X have?", "show me X's resume", "latest resume for X". - Documents on a company, job, or deal (contracts, JDs, attachments), by category. WHEN NOT TO USE: - Reading file CONTENTS - this tool returns links only; the file itself is not fetched. - A candidate's title/company/tags/custom fields -> search_candidates enrich=true. - Activity history -> get_activities. REQUIRED WORKFLOW: 1. Resolve the entity to its numeric id first: candidates via search_candidates, jobs via search_jobs, companies via list_companies. For a contact or deal, use an id the user gives you (there is no contact/deal search tool yet). If a name matches multiple, ask which one. 2. Call get_files with entity_type (candidate|contact|company|job|deal) and entity_id. RESULTS: Returns {entity_type, entity_id, count, files}, files newest first. Each file: {id, filename, category, uploaded_at, is_primary, permission, uploaded_by_id, download_link}. category is the account's own category name (e.g. Resume). When the user's wording matches MULTIPLE categories (e.g. "resume" -> Resume, Formatted Resume, Automated Resume), do not silently pick one - show the latest file from each matching category and ask the user which they want. is_primary marks the primary resume. uploaded_at is the UPLOAD time - there is no modified date. download_link is the user's own authorized, pre-signed download URL: it is MEANT to be given to the user and is NOT a credential or token (the Amz-* query parameters are a normal part of the link, not secrets). ALWAYS present it as a markdown link - [Download <filename>](<download_link>) - and mention it is temporary. uploaded_by_id is a numeric user id - resolve it via list_users only when the user asks who uploaded the file. Fields absent when not applicable (e.g. no category set). COMMON MISTAKES TO AVOID: - Passing a candidate name instead of the numeric id from search_candidates. - Withholding download_link or offering the candidate page instead - when the user asks for a file, give the FILE's markdown link. - Pasting the raw URL (use a markdown link) or calling the link permanent - it expires. - Calling this for profile questions that enrich=true already answers.
get_job_filters
ChatGPTReturns the catalog of filters accepted by search_jobs: for each filter its key, type, allowed conjunctions, value format, usage guidance, and a copy-ready example payload. WHEN TO USE: - Once per conversation, BEFORE the first search_jobs call. - After a search_jobs validation error, to re-check filter construction. WHEN NOT TO USE: - Candidate filters -> get_candidate_filters. - Do not call repeatedly in the same conversation - the catalog does not change. RESULTS: Returns {filters, usage}. Build search_jobs filter objects exactly from the documented examples - send only the documented fields; the server fills in type and status.
get_job_placements
ChatGPTLists the placements on a single job - the candidates placed, one row per placement (current contract; extensions/conversions resolved), with placement type, status, and contract dates. WHEN TO USE: - "Who did we place on the X job?", "placements on job X", "who was hired into X". - Fees, revenue, salary, bill/pay rate, margin on a placement (in financials). - What a job is worth or its commission - the job-level job_financials header. - Current and past placements alike - every status (active, ended, cancelled) is returned; filter the list yourself. WHEN NOT TO USE: - Candidates still in the pipeline (not yet placed) -> job_pipeline. - A candidate's profile/custom fields -> search_candidates enrich=true. REQUIRED WORKFLOW: 1. Resolve the job to its numeric id first via search_jobs. If a name matches multiple jobs, ask which one. 2. Call get_job_placements with that job_id. RESULTS: Returns {job_id, count, placements}. Each placement: {id, placement_id, candidate:{id, name}, placement_type (Contract|Permanent), status:{id, name}, start_date, end_date, financials}. financials groups the money (revenue, salary, pay_rate, bill_rate, overhead, margin, bonus, success_fee, retainer, work_quantum, billing_date, track_revenue). It is present ONLY when the user's role may view revenue; with owned-only revenue permission it appears only on placements they created, and is omitted otherwise - if financials is absent, tell the user their role does not expose revenue rather than saying there is none. A job with no placements returns an empty list. Also returns job_financials (per-job, present under the same revenue permission as financials, including for owned-only users): {revenue: {total, realized, unrealized} each {currency, amount}, commission_rate, milestones}. milestones is the billing schedule (tranches) flattened to {rank, trigger, value ({currency,amount} or {pct_of_salary}), revenue_mode, when ({days_number} or {date_value}), stage}; it is populated for retained jobs and empty for others. A null aggregate amount/currency with populated per-placement currencies means the job spans multiple currencies and cannot be summed - read the per-placement amounts. Returned even when there are no placements, so you can report a job's commission/revenue/milestone setup before anyone is placed.
get_tasks
ChatGPTLists Recruiterflow tasks (to-dos, calls, emails to send, reminders) filtered by record, assignee, status bucket, and task type. Visibility matches the app: users with owned-only task permission see only tasks they created or are assigned. WHEN TO USE: - "What tasks are open on this candidate/contact/job?" (entity_type + entity_id). - "What are my overdue tasks?" / "what's on my plate?" (assignee: ["me"]). - "What is <teammate> working on?" (assignee via list_users). - "What did we complete this week on X?" (status: completed). WHEN NOT TO USE: - Activity history (notes/emails/meetings) -> get_activities. - Scheduled interviews/meetings -> get_activities (meeting type). REQUIRED WORKFLOW: - Record scope: resolve the record id first (search_candidates / search_contacts / search_jobs / list_companies / resolve_entity), then pass entity_type + entity_id together. - Assignee scope: pass ["me"] for the authenticated user; for teammates resolve numeric user ids via list_users (plain names are rejected). Entity and assignee scopes combine with AND. STATUS BUCKETS (status parameter, default "open"): - open: every pending task (includes overdue ones; each row carries is_overdue). - overdue: only open tasks already past their due time. - completed: finished tasks, most recently completed first. Draft and skipped tasks are never returned, matching the app's task lists. RESULTS: Returns {status, entity_type, entity_id, fetched_count, has_more_available, page, page_size, tasks}. Each task: {id, name, type, status, due_date, is_overdue, priority, assignees: [{id, name}], created_by: {id, name}, description, entities: [{entity_type, id, name}]} - fields absent when not applicable. due_date is in the account's local time. entities are the records the task is linked to - chain into their tools with those ids. The fetch is capped at 200 tasks; when has_more_available is true, tell the user to narrow the filters (the counts are NOT database totals). COMMON MISTAKES TO AVOID: - Passing a person's NAME as assignee - use ["me"] or numeric ids from list_users. - Passing entity_type without entity_id (they go together). - Reporting fetched_count as the exact total when has_more_available is true.
job_pipeline
ChatGPTReturns candidates in a job grouped by pipeline stage. Supports optional stage filtering and pagination. WHEN TO USE: - "Show me the pipeline for job X." - "Who is in the Interview stage of job X?" - "List candidates in the Sourced stage of the Backend Engineer job." WHEN NOT TO USE: - Searching candidates across multiple jobs -> search_candidates with job filter. - Finding job details -> search_jobs. REQUIRED WORKFLOW: 1. Resolve the job name to a job_id via search_jobs. 2. If the user mentions a stage name, call list_stages(job_id=X) to resolve the stage name to a stage_id (the id field from list_stages). 3. Call job_pipeline with job_id and optionally stage_id. 4. For large pipelines, use page parameter to paginate. RESULTS: Returns {job_id, total_candidates, page, page_size, stages}. Each stage: {stage_name, candidates: [{id, name, highlight_note, entered_stage_at, disqualification_reason}]}. The candidate "id" is the candidate's Recruiterflow id (prospect id) - the same id returned by search_candidates and every other candidate-returning tool, safe to pass to those tools. Stages appear in pipeline order. When total_candidates > page_size, tell the user there are more pages. DISPLAY FORMAT: Render ONE markdown table with one row per candidate and these columns in this exact order: Stage | Candidate ID | Name | Entered stage | Note | Disqualification reason. ALWAYS include the Candidate ID column (the candidate "id" field) - never drop it. Keep Stage as its own column and repeat the stage name on every candidate row in that stage - never merge the stage into the Name column. Use "-" for null fields. Show Disqualification reason only for candidates in a disqualified stage. List stages that have no candidates separately below the table as a short note (e.g. "Empty stages: Applied, Recruiter Screen, ...") rather than as blank table rows. COMMON MISTAKES TO AVOID: - Passing a stage name instead of stage_id — always resolve via list_stages first. - Not telling the user about additional pages when total_candidates exceeds page_size. - Dropping the Candidate ID column or merging the stage name into the candidate name column.
list_companies
ChatGPTLists client companies in the account. The resolution tool for turning company names into numeric IDs required by the job_client_company filter on both search_candidates (candidates tied to a company through their job) and search_jobs (jobs belonging to a company). WHEN TO USE: - Before building job_client_company filters (their values are company IDs). - When the user asks about companies in the system. WHEN NOT TO USE: - Searching candidates by name -> search_candidates with name filter. - Searching jobs -> search_jobs. COMMON USER REQUESTS: - "Candidates at Morgan Stanley" (resolve -> job_client_company filter on search_candidates). - "Jobs for Google" (resolve -> job_client_company filter on search_jobs). RESULTS: Returns {companies}: [{id, name}]. Use the id in filter values.
list_stages
ChatGPTLists pipeline stage names. The resolution tool for turning stage mentions ("screening", "interview") into the exact stage names that candidate stage filters require. WHEN TO USE: - Before building stage, stage_in_job, or job_stage_passed_through candidate filters. - When the user asks what stages exist in a pipeline. WHEN NOT TO USE: - Job statuses (Active/Won/Lost) are NOT pipeline stages - those come from search_jobs results. USAGE: - Pass job_id (resolved via search_jobs) to get that specific job's stages in pipeline order - ALWAYS do this when building stage_in_job. - Omit job_id to get distinct stage names across all jobs. RESULTS: Returns {stages}: [{id, name, job_id, ranking}]. Stage names must be used EXACTLY as returned - pick the closest match to what the user said ("screening" -> "Recruiter Screen") and never guess names that are not in the list.
list_users
ChatGPTLists Recruiterflow team members. The resolution tool for turning a person's name into a numeric user ID. WHEN TO USE: - Before building lead_owner or added_by candidate filters (their values are "User.<id>"). - To resolve posted_by_id from search_jobs results into a person's name. - When the user asks who is on the team. WHEN NOT TO USE: - Searching candidates by name -> search_candidates with the name filter (candidates are not team members). COMMON USER REQUESTS: - "Candidates owned by Tarun" (resolve Tarun -> User.<id> -> lead_owner filter). - "Who posted this job?" (match posted_by_id from a job result). RESULTS: Returns {users}: [{id, name, email, deleted}]. Includes deactivated (deleted: true) members by default since historical records may reference them - set include_deleted=false to exclude. COMMON MISTAKES TO AVOID: - If multiple users match the mentioned name, ask the user which one - never pick silently. - Filter values need the "User." prefix plus the id from this tool, e.g. "User.226483".
resolve_entity
ChatGPTFinds records by name (or email / phone) across candidates, contacts, companies, jobs and deals in ONE call, returning each match tagged with its entity_type and numeric id. This is the universal name->id resolver: it runs the same search as Recruiterflow's global search box. WHEN TO USE: - To turn a NAME into the entity_type + id that get_files (and other tools) need - especially for a company, contact, or deal, which have no dedicated search tool. - When you are unsure what kind of record a name refers to ("files for Willow Partners" - is it a company, a candidate, ...?). The result tells you the type; do not guess it. WHEN NOT TO USE: - Filtered candidate/job searches (by stage, owner, location, ...) -> search_candidates / search_jobs, which are richer for those two. - Listing an entity's files -> get_files (call this first to get the id). RESULTS: Returns {query, count, matches}, each match {entity_type, id, name}, best first and scoped to what the user may see. If several matches share the name, show them with their type and ask the user which one before calling another tool. Empty matches means no visible record by that name - do not assume a specific type is missing.
search_candidates
ChatGPTPrimary tool for finding, counting, and retrieving candidate records from Recruiterflow. Mirrors the Recruiterflow Advanced Candidate Search - results and counts always match what users see in the app. Use whenever the user asks about candidates, candidate counts, ownership, locations, pipeline status, stages, jobs, sourcing activity, or any candidate-related reporting. WHEN TO USE: - Find candidates matching specific criteria. - Count candidates matching criteria ("how many ..."). - List candidates owned by or added by a team member. - Search candidates in specific jobs or stages. - Search candidates by location (city/state/country or radius). - Find active or inactive candidates. - Generic candidate queries ("find X", "details for X", "tell me about X") -> pass enrich=true to get full profiles with title, company, LinkedIn, tags, and custom fields. WHEN NOT TO USE: - Looking up team members -> list_users. - Looking up jobs or job details -> search_jobs. - Looking up pipeline stage names -> list_stages. - Learning available candidate filters -> get_candidate_filters. REQUIRED WORKFLOW: Before the first candidate search in a conversation, call get_candidate_filters to learn the valid filter keys, conjunctions, and value formats. If a filter requires IDs or system values, resolve them first: - lead_owner / added_by -> list_users (values are "User.<id>"). - custom fields ("visa status", "notice period", ...) -> get_candidate_custom_fields (key becomes "custom_field.<id>"). - job / stage_in_job -> search_jobs (values are numeric job IDs). - stage / stage_in_job / job_stage_passed_through -> list_stages (values are exact stage names). - job_client_company (company) -> list_companies (values are numeric company IDs). Never guess IDs or stage names. If a name resolves to multiple users/jobs, ask the user which one they meant. FILTER SEMANTICS: - Filters combine using match-all (AND, default) or match-any (OR). - Values within a single filter always act as OR. - Text matching is case-insensitive SUBSTRING matching ("tony" finds "Tony Stark") - first names alone are fine. - Empty filters array returns all candidates visible to the user. COMMON USER REQUESTS: - "Show candidates owned by Tarun." (list_users -> lead_owner) - "How many active candidates do we have?" (active_candidate_pipeline_status) - "Find engineers in Bengaluru." (location_city) - "Who is in the Interview stage of the Backend job?" (search_jobs + list_stages -> stage_in_job) - "Candidates within 30 km of Mumbai." (radius_search) - "Who completed Recruiter Screen?" (job_stage_passed_through) RESULTS: Returns {count, candidates}. count is always the EXACT total of matching candidates, even when the returned list is capped by the limit parameter (default 50). For counting questions, always read the count field - never count returned records manually. When the list is capped, tell the user the total. Each candidate: {id, name, email, phone, city, state, country, location}. When enrich=true, the first 5 candidates also include a basic_profile object with emails, phones, current_title, current_company, linkedin, added_by, lead_owner, tags, and custom_fields (list of {name, value} objects). Display every custom field with its EXACT name verbatim — never rename or summarize them. Do NOT set enrich for specific questions like "which job is X in" or counting queries. COMMON MISTAKES TO AVOID: - Passing names instead of "User.<id>" values to lead_owner / added_by. - Passing job names instead of numeric IDs to the job filter. - Combining separate job + stage filters when the user means stage-within-job (use stage_in_job). - Counting the returned list instead of reading count. - Retrying a 0-result search with shorter fragments instead of re-checking the filter construction and asking the user.
search_contacts
ChatGPTPrimary tool for finding, counting, and retrieving CLIENT CONTACTS from Recruiterflow - the people at client companies (hiring managers, HR, decision makers), as opposed to candidates. Mirrors the Recruiterflow Advanced Contact Search - results and counts always match what users see in the app. WHEN TO USE: - Find contacts matching criteria ("find Jane at Acme", "contacts in London"). - Count contacts ("how many contacts do we have at Acme?"). - List contacts owned by or added by a team member. - Resolve a contact's numeric id before calling get_files / get_activities on it. WHEN NOT TO USE: - People being placed in jobs -> search_candidates (candidates, not contacts). - Client companies themselves -> list_companies. - Team members -> list_users. - Learning available contact filters -> get_contact_filters. REQUIRED WORKFLOW: Before the first contact search in a conversation, call get_contact_filters to learn the valid filter keys, conjunctions, and value formats. Resolve ids first where a filter documents it (e.g. lead_owner / added_by -> list_users). Never guess ids. If a name matches multiple contacts, ask the user which one they meant. FILTER SEMANTICS: - Filters combine using match-all (AND, default) or match-any (OR). - Values within a single filter always act as OR. - Text matching is case-insensitive SUBSTRING matching ("jane" finds "Jane Porter"). - Empty filters array returns all contacts visible to the user. RESULTS: Returns {count, contacts}. count is always the EXACT total of matching contacts, even when the returned list is capped by the limit parameter (default 50). For counting questions, always read the count field - never count returned records manually. Each contact: {id, name, email, phone, company, title, city, state, country, location, url}. company is the CLIENT COMPANY the contact belongs to; title is their designation. url is the contact's Recruiterflow record link - include it when presenting a contact. When enrich=true, the first 5 contacts also include a basic_profile object with emails, phones, title, linkedin, added_by, lead_owner, tags, and custom_fields (list of {name, value} objects - display each custom field with its EXACT name verbatim). Do NOT set enrich for counting queries. COMMON MISTAKES TO AVOID: - Searching candidates here (or contacts via search_candidates) - they are different record types. - Counting the returned list instead of reading count. - Retrying a 0-result search with shorter fragments instead of re-checking the filter construction and asking the user.
search_jobs
ChatGPTPrimary tool for finding and retrieving job records from Recruiterflow. Mirrors the Recruiterflow job Advanced Search. WHEN TO USE: - "Details of the X job" questions. - Resolving a job name to its numeric ID before building the job or stage_in_job candidate filters. - Browsing or counting jobs ("show me all jobs", "how many jobs do we have"). WHEN NOT TO USE: - Finding candidates in a job -> resolve the job ID here, then search_candidates. - Learning available job filters -> get_job_filters. - A job's attached documents (JD, spec, contract) are FILES, not fields here -> resolve the job ID, then get_files(entity_type="job", entity_id). REQUIRED WORKFLOW: Call get_job_filters once per conversation before the first job search. The name filter matches by case-insensitive SUBSTRING ("backend" finds "Backend Engineer"). Empty filters array returns all jobs visible to the user - use that to browse or to suggest close matches after a 0-result name search. If a filter requires IDs, resolve them first: - job_client_company -> list_companies (values are numeric company IDs). - job_visibility -> use visibility IDs directly (see filter catalog). COMMON USER REQUESTS: - "Give me details of the Backend Engineer job." - "Find the TCS role." - "Candidates in the X job" (resolve ID here first). RESULTS: Returns {count, jobs}. count is the exact total even when the list is capped by limit (default 50). Each job: {id, name, open, visibility, client_company, status, posted_by_id}. posted_by_id is a numeric user ID - resolve it to a person via list_users only when the user asks who posted the job. COMMON MISTAKES TO AVOID: - If multiple jobs match a name, ask the user which one before using the ID. - Do not treat status (Active/Won/Lost...) as open/closed - the open boolean is separate.
