"Buddy" matching MCP tools:

• listCrewCandidatesA

  mcpA

  Matching crew candidates for a job RE-STAFFING candidates for a CONFIRMED, SCHEDULED job (not yet completed/archived) — any earlier or later stage returns 409 JOB_REQUEST_INVALID_TRANSITION. This is the pool of technicians who could REPLACE the current crew: the currently assigned lead and buddies are deliberately excluded (they are the status quo, not an option), so on a small roster an empty `leads` list is a normal answer, not an error. For pre-booking discovery ("who could take this job before it is confirmed?") use listJobRequestBookingWindows / listMatchingSlots / the time-segments grid instead. Candidates are matched and ranked by the smart-assignment engine — skills per crew slot, weekly availability, existing schedule, time off and travel are all checked; each carries a score breakdown (distance, travel, matched skills) plus the exact on-site session plan they would work. NOT a raw roster list (use GET /technicians for that). Returns the ranked feasible LEAD pool by default; pass include_buddies=true to also return per-slot buddy pools, include_vehicle=true to include the available-vehicle list. force_lead_id checks one specific technician: returns only that lead (with their crew combo) if feasible, else 409 JOB_REQUEST_NO_TECHNICIAN_AVAILABLE.

  ConnectorAPI key

• propose_page_updateA

  Voicescape — on-chain identity and tipping for AI agentsB

  Propose a content update to a blockpage your human owns — the KEYLESS operation path for agents that cannot hold private keys. Authenticate with a Bearer <redacted> (NOT a key — your human issues it once via the request_capability_token issuance link; it lives in your secure credential storage, never in chat): pass it as the capability_token argument, OR send it as the HTTP Authorization: Bearer <redacted> — if your runtime injects vault-held credentials as a header, OMIT the argument entirely so the value never appears in chat, logs, or tool-call records. The token only lets you PROPOSE: the server verifies your human owns the page on-chain, pins nothing yet, and returns an approval_url — share that link with your human in YOUR OWN chat; they open it, review, tap Approve, and sign ONCE in their wallet (a few cents of HBAR gas). The proposal is also queued as a one-tap card in their Buddy chat inbox. Nothing executes without that tap. Pass the FULL desired page content (not a diff): read the current page first, then propose the complete new version. The token cannot move funds, change ownership, touch keys, or do anything outside proposing updates — see /docs/agent-capability-scope.md for the exact allow-list and exclusions. NOTE: this is the keyless path. If you hold your own funded Hedera key, update your own pages by calling the Registry's updatePage directly with your key — no proposal and no human tap needed.

  ConnectorNo auth

• createVehicleA

  mcpA

  Add a vehicle to the fleet Registers a van, truck or car in the business's own fleet. Vehicles are what a confirmed job's crew travels in: at confirm, Crisphive auto-selects one vehicle for the whole crew from the lead technician's vehicles, then from unowned fleet vehicles, and blocks a vehicle already booked for an overlapping job. `name` is the only required field, so a bulk fleet import needs nothing else; brand, model, year, plate_number, current_mileage and vehicle_type (van, truck or car) can be filled in later with updateVehicle. Names and plate numbers must be unique in the business (VEHICLE_DUPLICATE_NAME / VEHICLE_DUPLICATE_PLATE). `owner_id` records who has CLAIMED the vehicle as their primary one. The owner must be a lead technician or a management role; a buddy- or float-tier profile is refused with VEHICLE_OWNER_TIER_NOT_ALLOWED, an unknown profile with VEHICLE_INVALID_OWNER. Deciding which vehicles a technician may USE is a separate relation: use replaceTechnicianVehicles for that, not this tool. Send an Idempotency-Key header (the `idempotency_key` argument over MCP) so a retried call replays the original response instead of creating a duplicate vehicle.

  ConnectorAPI key

• vault_get_characterA

  Embers: Tabletop RPG ToolkitA

  Fetch one character document by id. Defaults to a summary shape: combat-relevant top-level fields (attributes, defense, offense, AC, HP, actions, skills) preserved; bulk text bodies on populated rule/item/spell refs and inline snapshots trimmed; notes/trackables reduced to names + key fields. Pass `detail: 'full'` for the populated shape with every description inline. The `companions[]` array (buddy ties — see vault_attach_companion) rides along untrimmed in both shapes, overlay `state` included; each row's `_ref` is a bare character id you can fetch with this tool. `linkGroup`, when present, is the id shared by this persona's linked sheets in other rulesets (created via vault_spawn_linked_character); it rides reads only and is not writable through the update tool.

  ConnectorOAuth

• vault_attach_companionA

  Embers: Tabletop RPG ToolkitA

  Attach a buddy (animal companion, hireling, follower, granted NPC, stock monster) to a Main character the user may edit (their own, or any for an admin with Admin Mode on). The row appears in the sheet's Companions section. Mode is decided by ownership: 'owned' for a character the Main character's owner already owns (its values are then edited on its own document via vault_update_character — the row is a live window, no copy is made, no character slot is used); 'link' for a character someone else owns (the source is never written; track its hit points and uses via vault_update_companion_state). The same source may be attached more than once — each row is independent. Response is `{ companion, companions, updatedAt }`; ADOPT the returned `updatedAt` as the Main character's fresh stamp for any follow-up write.

  ConnectorOAuth

• vault_update_companion_stateA

  Embers: Tabletop RPG ToolkitA

  Write a LINK-mode companion row's transient overlay — the locally-tracked hit points, temp HP, hit dice, death saves, exhaustion, stress marks, and trackable/free-cast counters for a buddy the user doesn't own. The source character is never written. The `state` you send replaces the row's stored overlay wholesale: vault_get_character the Main first, modify that row's `state`, send it back complete. Maximums never belong in the overlay (they derive from the source; vault drops them). Rows in 'owned' (or legacy 'clone') mode have no overlay — edit the referenced character directly with vault_update_character instead. REQUIRES baseUpdatedAt: copy `updatedAt` from a fresh vault_get_character read of the MAIN character; a stale value is rejected with OUT_OF_SYNC and nothing is written.

  ConnectorOAuth

• createTechnicianA

  mcpA

  Add a technician Creates a technician membership under the current business. If the phone/email matches an existing user, their account is linked. Otherwise a new user identity is created. Either way the membership starts active. The new member is notified (live mode only, best-effort): an email when `email` is supplied, an SMS when `phone` is supplied, both when both — informational only, no activation step (login stays passwordless: magic link / OTP). Re-adding someone: if the person is currently SUSPENDED on this business (a dashboard action — not reachable via this API), the create REACTIVATES that existing membership (same technician id, their existing group; also notified). A technician REMOVED with deleteTechnician is a closed membership: re-adding the same email/phone links the SAME underlying person (no duplicate identity) but creates a FRESH membership with a NEW id — history stays under the old one. Owner/Administrator groups cannot be assigned via API key, and not at all in sandbox mode. `assignment_tier` (what the scheduler assigns jobs by) is ignored — stored empty, no error — for the Booking Coordinator, Administrator and Viewer roles, which are never assigned jobs; a reactivated member of those roles also comes back without a tier. Optional relations (all validated; any missing id → 404 TECHNICIAN_NOT_FOUND with `missing_ids`): `buddy_ids` sets this technician's buddy list (use when creating a lead); `lead_ids` adds this technician as a buddy of each named lead (use when creating a buddy — the buddy-side way to attach the same lead↔buddy relation); `service_area_ids` assigns the technician to those service areas. `start_location_type=office` snapshots the business address + coordinates into the technician at create time; `address`, `start_location_lat`, `start_location_long` in the body are ignored. Requires the business to have coordinates set (else 400 BUSINESS_LOCATION_MISSING). `start_location_type=home` (or empty) uses the address + coordinates from the body.

  ConnectorAPI key

• deleteTechnicianA

  mcpA

  Remove a technician from the business Closes the technician's membership: the profile is set to deactive and soft-deleted, and their access to this business ends on their next request. In the same operation they are removed from every other technician's buddy list, vehicles they own are released, and any personal-calendar connection they made for this business is revoked. Fires the technician.deleted webhook. Their underlying user identity is untouched, and so are memberships at other businesses. Removal is REFUSED while the member is still staffed on an open job, as the lead or through a crew session, where open means not completed, not archived and not deleted (409 TECHNICIAN_HAS_OPEN_JOBS; nothing is written). data.open_job_count is the exact count and is always present. data.jobs lists up to 20 of them (id, short_code, current_status_key, scheduled_at when confirmed) ONLY when the caller also holds job_manage (a credential that may manage the team but not the job board gets the count alone; the key is then absent). Re-staff them first: reassign each with listCrewCandidates, re-plan whole days with previewAbsenceResolve / commitAbsenceResolve (which needs a time-off record covering those days; create one with createTechnicianTimeOff), or, from the dashboard, complete or archive the job. To cut someone's access immediately while their work is re-staffed, suspend them from the dashboard: suspension is not gated. This is a closed membership, not a pause. Re-adding the same email or phone later with createTechnician links the SAME person but opens a FRESH membership with a NEW technician id and none of the old buddy, vehicle or area links. If you expect the person back, suspend them from the dashboard instead; a suspended member is reactivated in place by createTechnician, keeping their id and group. The last active Owner cannot be removed (TECHNICIAN_LAST_OWNER). API keys the person created are NOT revoked (an HR action must not take an integration down); if any are still active, the business Owners and Administrators are emailed a list of them.

  Connector

  Destructive

  API key

• vault_update_characterA

  Embers: Tabletop RPG ToolkitA

  Patch fields on an existing character by id. Only supplied fields change, with one distinction: object sub-docs (defense, core, offense, speed, personality, settings) deep-merge — nested keys you omit are preserved — but ARRAY fields (items, spells, rules, skills, actions, trackables, attributes, notes) are atomic: the array you send replaces the stored array wholesale. To add or edit one array entry, vault_get_character first, modify the returned array, and send the complete array back. Sending null for a field is treated the same as omitting it (the field keeps its current value) — null does NOT clear; to clear a text field send an empty string. This is also the canonical tool for editing a play campaign character's HP, conditions, or inventory; play characters are pointers to vault characters and play has no direct character-write endpoint. AC caution: when the character's `settings.autoPassiveBonuses` is true (the default for new characters in rulesets with sheet automation), the armor and shield rows of `defense.armorClass` are derived from equipped items and recomputed on every sheet load — change AC by setting `equipped` on the character's armor/shield items, not by writing those rows; when the toggle is false, `defense.armorClass` is manually authored and writing it directly is correct. Caution: mutations may affect any active play campaign or expedition referencing this character. Consider running vault_get_character first to inspect linkage. REQUIRES baseUpdatedAt: copy `updatedAt` from a fresh vault_get_character read; a stale or fabricated value is rejected with OUT_OF_SYNC and nothing is written — writing from memory of an earlier read is not possible. `companions` is NOT writable here (it is stripped): manage buddy ties with vault_attach_companion / vault_detach_companion, and a linked buddy's tracked values with vault_update_companion_state. `linkGroup` is NOT writable here either (also stripped): linked-sheet group membership is created by vault_spawn_linked_character and only vault's unlink endpoint clears it.

  ConnectorOAuth

• va_evidence_that_winsA

  VetAid — VA Claim IntelligenceA

  MEASURED evidence-vs-outcome data for one VA condition, from the full text of the public BVA archive (1.8M+ decisions): for each kind of evidence — a positive nexus opinion, a private physician letter/DBQ, buddy statements, service treatment records that document the condition (or are silent), a Board hearing, and how the Board read the record (credibility, benefit of the doubt, inadequate exam) — how often the issue was GRANTED when the record had it versus when it did not, with the raw fractions. Single-issue decisions only, so each evidence flag attaches to exactly one decided issue. Use this to say which missing evidence has historically mattered most and by how much; it is an association in appealed cases, not a prediction. Aggregate data only — no PII. Args: condition: VA condition keyword, e.g. 'ptsd', 'sleep apnea', 'back', 'knee', 'tinnitus'. benefit: 'service_connection' (default), 'increased_rating', 'tdiu', 'effective_date', or 'all'.

  ConnectorNo auth

• prepare_agent_claimA

  Voicescape — on-chain identity and tipping for AI agentsB

  Prepare a blockpage claim as a one-tap approval LINK for the human to sign — the Sovereign onboarding path. The human's EXISTING wallet owns the page: no new wallet, no new seed phrase, no wallet-switching. Supports HUMAN pages too (owner_type: "human") — a person can have their AI agent build their whole blockpage from chat. CUSTOM LAYOUTS: pick any template via list_templates, or pass a freeform theme (custom colors/font), plus socials[] (any of their social profiles) and links[] (any project URLs) — the page is assembled server-side from validated parts, and the human sees a live preview on the approval page before signing. Validates the username is free on-chain; when an owner account is given, confirms it exists and is funded. Returns an approve_url: the human opens it in any browser (no signup, no sign-in), reviews the preview + plain-words summary, taps Approve, then connects their wallet and confirms once in the wallet's own screen — ONE signature publishes the blockpage and registers it (Review → Approve → Connect → Done). The page registers to the wallet they connect. Nothing is pinned and no transaction is built until the human taps. Pure preparation — no keys, no signing, no submission, no spending. When an owner account is provided, the package is also queued as a one-tap approval card in the owner's Buddy chat (they approve inline in the chat thread — no extra screens).

  ConnectorNo auth

• replaceTechnicianBuddiesA

  mcpA

  Replace a technician's buddies Overwrites the technician's buddy list with the provided set of technician IDs. Sending an empty list clears all buddies. Each buddy ID must be an active technician of the same business; a technician cannot be their own buddy.

  Connector

  Destructive

  API key

• link_production_itemsA

  socialloop-mcpA

  Interconnect production items on a live event — link an item to others across the graph (task→project, project→teams/places/milestones, vendor→projects, programming→talent/places, inventory→team/place/project, receipt/transaction→team/vendor/project, place→parent, cue→place/programming/talent, milestone→projects/tasks, meal→shift, task→place, team→depends_on, buildUnit→unit_lead/unit_team/environments/build_tasks, scholarship→applicant, invitation→nominated_by/applicant, person↔person via modes→roommates/buddy/mentor/significant_other/sharing_vehicle_with/paying_for/ticket_sending_to/ticket_receiving_from). op add/remove/set. Denormalized names + team counters stay in sync automatically. Requires event_id + entity + item_id + relation + target_ids; host.

  ConnectorNo auth

• replaceTechnicianLeadsA

  mcpA

  Replace a buddy's leaders (buddy side) Sets the full set of leads this buddy belongs to (many-to-many favorites). Replace-semantics — lead_ids is the complete new list; [] clears every leader. Managed by business staff.

  Connector

  Destructive

  API key

• listTechniciansA

  mcpA

  List technicians Returns the field workforce roster: paginated technicians (field workers / engineers) with status, assignment tier (lead, buddy, float), skills and crew relations — the people the dispatch engine schedules onto jobs. Discover the `preferred_technician_id` accepted on customer records here. Supports the `since` cursor for incremental workforce sync.

  ConnectorAPI key

• getTechnicianA

  mcpA

  Get a technician Returns one technician's full profile: contact info, employment status, assignment tier, skills/qualifications, buddy (crew) relations and assigned vehicles — the dispatch-ready view of a field worker.

  ConnectorAPI key

• build_onboarding_planB

  ruzoraB

  A 30-60-90 day plan for a new software engineer: least-privilege day-1 access, first PR in week one, a buddy plan, and milestones tied to the role scorecard.

  ConnectorNo auth