---
name: recruiter-workspace
description: Search and maintain projects, job descriptions, contacts, and project-specific recruiting history through the connected Recruiter Workspace MCP server. Use for workspace data lookup or user-requested record changes.
---

# Recruiter Workspace

Use the configured Recruiter Workspace MCP connection. Authentication selects the workspace and member; never supply or infer another tenant identity. If the connection is unavailable, explain the missing connection and refer to the workspace's MCP & Skills setup page.

## Find the intended record

Use `unified_search` for a name, employer, role code, JD phrase, or exact LinkedIn URL. Use `parse_batch_names` for multiple names, optionally with employer after a comma. Search results are suggestions: when identity is ambiguous, obtain the user's selection before modifying a record. Never invent a LinkedIn URL or silently create a person because a search returned no match.

Read the selected record with `read_record`, or use `get_record_context` for its project relationships, notes, and communication history. The connection's live tool schemas are authoritative for tool arguments. `list_records` can retrieve projects and job descriptions needed to resolve explicit associations.

## Save requested changes

Work within the user's requested scope. Use `create_record`, `update_record`, `archive_record`, and `restore_record`; do not modify the underlying database directly. Updates require `data.version` from the latest read. Archive and restore require the current `version` alongside the record ID. On a version conflict, reread the record and reconcile the user's intended change with the new state before retrying.

Use a stable `idempotency_key` for each logical write and reuse it only when retrying that same payload. A different change needs a different key. On an uncertain write result, reread or retry with the original key before creating another record. Stop retries when authentication fails or a conflict needs user input.

Keep a person's progress on their `project_contacts` relationship, so different roles can have different states. Preserve the exact linked `job_description_id`. Similar JD search results are not evidence of an existing association or of a sent JD.

Queued work and drafts do not establish that an invitation was sent. Record actual sent or received communication only when the user supplies that outcome or a reliable existing record supports it. A sent-JD communication requires an explicit `job_description_id`. This service stores communication records; it does not send LinkedIn messages.

## Report the result

Distinguish retrieved facts, proposed changes, and confirmed saved changes. After a write, use the returned record and, when needed, a fresh read to report which person and project changed. Surface ambiguity, version conflicts, and missing data without filling gaps with guesses.