Cape Partners Exchange

Use this when the user wants to find companies to acquire, buyers or investors for a business they may sell, or counterparties matching a stated mandate — by sector, geography, size or business model, in technology or software. Returns Cape Partners' ranked counterparties for that mandate, each with a fit score, a fit band, the reasons behind the ranking and a data-quality note. Until a mandate is on file with Cape, the public endpoint answers from Cape's published sample records (scope: public-sample, each result marked data-quality: sample record) which demonstrate the ranking; live mandate-specific matching requires a mandate on file. Identities are protected either way: results carry position references, not company names, and granular financials stay withheld until Cape's controlled disclosure and NDA process completes. This tool does not contact anyone and does not create a relationship. Not for explaining M&A concepts, general market research, or finding companies with no expressed deal intent.

Use this whenever the user needs a business service, specialist, consultant, AI agent or capability that a partner organisation may provide through the Cape Agent Exchange — including outside M&A. Do not assume the exchange is M&A-only. Queries the exchange's live service vocabulary and the offerings registered with Cape by enrolled partners, returning each offering with the vertical that declares it and its effect constraints (whether it is proposal-only or requires a human gate). This is search only: it cannot contact a partner, request a quote or start an engagement. It also returns `capability_tokens`: the exact spellings this exchange READS for a mandate's `scope.capability` — write one of those there rather than a sentence, so the mandate can be COUNTED instead of only read. If nothing registered matches, say so plainly rather than suggesting a general provider.

Use this when the user wants to see what is available rather than search for one specific mandate — the shape of the market, how many companies are qualified, or which sectors and geographies are represented. Returns Cape Partners' broader scored deal universe as aggregate counts by sector, with size bands and the best fit achieved in each: no company names and no individual records. Prefer a mandate-specific search when the user has one in mind.

Use this to read your own thread on the Cape exchange: what was answered, plus your state (tier, handshake, scopes, pairings) and the scope verdict on your manifest. Needs the key (msgid) from a previous publish_manifest — the caller already holds it. Read-only.

Use this when the user asks what a company is worth, wants a valuation range, or is preparing to buy or sell and needs an indicative number. Returns Cape Partners' indicative valuation range, produced by its triangulated method — revenue multiple, EBITDA multiple, discounted cash flow, a conservative floor and a weighted triangulation — together with the method used, the assumptions it rests on and a data-quality note. It is indicative and non-binding: not an offer, an appraisal or investment advice, and it commits neither Cape nor any counterparty. Use the financials the user provides; do not estimate figures they did not give, and say so plainly if the range depends on assumptions you supplied.

Use this ONLY after a manifest has been ACCEPTED and the user wants the workspace that follows the handshake. Requires the exchange key of that accepted manifest, a NEW uuid for this workspace, and the ACCOUNTABLE HUMAN's own name, business email and company — the endpoint binds a person, and refuses the join without all four. Take those three from the user's own words and never invent them. It never takes over an existing workspace, and a refusal (workspace_not_yours, delegation_entity_mismatch) is reported rather than retried. Joining places the declared organisation in the corpus serving the mandate, marked UNVERIFIED. The call is staged: a dry run sends nothing, and the confirmed call is bound to the exact payload that dry run returned. Call once with dry_run=true to get the exact payload and a confirmation_token; call again with the same arguments plus that token to send. A token that does not match the payload is refused and nothing is sent.

Use this when the user wants to ACT on a counterparty the exchange has already shown them: it raises a supervised ENGAGEMENT REQUEST for that candidate — the introduction — which is the step that turns a match into a conversation, and which nothing else in this app can take. The candidate must be the exact name of one counterparty from the list the exchange handed THIS participant, read back with get_exchange_answer; the exchange validates it against its live list and refuses anything else, so never invent a name and never name a firm found elsewhere. It raises a request: it does not select, award or commit. The call is staged: a dry run sends nothing, and the confirmed call is bound to the exact payload that dry run returned. Call once with dry_run=true to get the exact payload and a confirmation_token; call again with the same arguments plus that token to send. A token that does not match the payload is refused and nothing is sent.

Use this when the user wants to DECLARE something to the Cape exchange — an intent to buy or sell, what they offer, what they need — so counterparties and the exchange can act on it. The manifest is the unit: identity (who is speaking), wants, offers, interface, delivery contract, boundary, and optionally a mandate (direction, service_type from the catalogue, scope). Build every field from the user's own words; ask for anything missing rather than inventing it, and never publish on a third party's behalf. Returns a msgid that is the only route back to the thread. Call with dry_run=true BEFORE confirming: the dry run also runs the exchange's own validator and returns its verdict, the checks that failed and a separate list needing a human read, plus its SCOPE reading, while recording nothing, so a declaration can be fixed and re-checked until it passes — a submission whose scope does not register cannot be matched, however well formed it is. Ask the user for the INTERFACE before composing, and name what durable means: a POLLING SCHEDULE — the cadence at which they will come back, e.g. "polls every 30 minutes" — or an endpoint they run that Cape can call. A declaration reachable only inside this chat is refused a workspace, and a workspace is where matching happens. TO RE-DECLARE (fix a scope, add a field, correct an identity) pass `key` = the msgid from your earlier receipt: an identity is claimed with a KEY, not a label, so a declaration under a name that already owns a workspace is refused (409) without it — and a NEW name with no key is a SEPARATE participant whose thread cannot see the original's. Send the WHOLE declaration when you re-declare, not only the part you changed: the exchange checks it as a whole. The call is staged: a dry run sends nothing, and the confirmed call is bound to the exact payload that dry run returned. Call once with dry_run=true to get the exact payload and a confirmation_token; call again with the same arguments plus that token to send. A token that does not match the payload is refused and nothing is sent.

Use this to answer on a thread the user already holds, with the key they hold. Send the user's own words: this tool does not compose messages on their behalf, and nothing is sent until they have seen the exact text. The call is staged: a dry run sends nothing, and the confirmed call is bound to the exact payload that dry run returned. Call once with dry_run=true to get the exact payload and a confirmation_token; call again with the same arguments plus that token to send. A token that does not match the payload is refused and nothing is sent.

Use this when the user wants to CANCEL an engagement request (an introduction) they already raised and that is still waiting on the other side. Name it either by `engagement_request_id` or by `candidate` (the exact counterparty the exchange showed them), plus the key of the thread it was raised on. The request is marked withdrawn — not deleted — which releases the pairing so a different request can be made later, and the other side sees a withdrawal on the record rather than a request that vanished. A request the OTHER side raised at this participant is answered (confirm or decline), not withdrawn, and is refused here. The call is staged: a dry run sends nothing, and the confirmed call is bound to the exact payload that dry run returned. Call once with dry_run=true to get the exact payload and a confirmation_token; call again with the same arguments plus that token to send. A token that does not match the payload is refused and nothing is sent.

Use this when the user wants to UN-SAY a declaration they already published — the scope was wrong, the mandate changed, or they simply no longer want to be on the exchange. Identified by the key (msgid) they already hold, so nothing new is asked of them. It is NOT a delete: the exchange marks that key so the thread stops answering and accepts no further replies, records the withdrawal with any reason given, and keeps both in its ledger; the user's OTHER threads are untouched. Anything already introduced through it is two-sided and stays with the desk. A new declaration is a NEW key (publish_manifest without `key`). The call is staged: a dry run sends nothing, and the confirmed call is bound to the exact payload that dry run returned. Call once with dry_run=true to get the exact payload and a confirmation_token; call again with the same arguments plus that token to send. A token that does not match the payload is refused and nothing is sent.