From creator search to signed contract, in one conversation

Two MCP servers in the same chat window: Upfluence finds the creators, Usign contracts them. No CSV, no copy-paste, and a human confirmation before anything is sent.

Booking a creator campaign is two jobs that never share a tool. Discovery lives in an influencer platform — filters, audience quality, rate estimates. Contracting lives somewhere else entirely — a template, a merge-field spreadsheet, and an afternoon of clicking send. The handoff between them is a CSV, and the CSV is where the mistakes live.

Both halves now speak the same protocol. Upfluence and Usign each publish an MCP server, so an agent that can reach both can carry a roster from search result to signed PDF without either list ever leaving the conversation.

What you need

Two connectors, each authorised with an account you already have. Neither needs an API key, a config file, or a developer.

Everything below is written for Claude, because that is where both servers have been used together. Usign's server is a standard OAuth 2.1 MCP server over Streamable HTTP, so any client that implements that specification should be able to connect — but Claude (claude.ai, Desktop, Code) is what we test against and what we can vouch for today.

Connect both servers

In claude.ai, go to Settings → Connectors → Add connector, choose a custom MCP server, and add each URL in turn. Both use OAuth, so Claude discovers the auth metadata on its own and opens a browser tab for you to approve. Full detail for the Usign side is in the five-minute connection guide.

Start a new chat with both connectors enabled. That is the whole setup.

The run, step by step

Here is the conversation as it actually goes. Each numbered step is one or more tool calls; the words in italics are what you type.

1. Find the roster

Find me 25 US-based skincare creators on Instagram with 20k–150k followers and an engagement rate above 3%. Show me audience authenticity and an estimated post rate for each.

Claude calls Upfluence's get_creators to run the search, then enriches the shortlist with get_audience for authenticity signals and get_estimated_costs for pricing. You get a table back in chat. Cut it down conversationally — drop anyone under 2% authentic — until the roster is the one you want.

2. Get the contact details

get_email_address resolves verified contact addresses for the creators you kept. This is the step that used to be an export: the emails now sit in the conversation, already attached to the handles they belong to.

3. Learn the contract's shape

Which Usign templates do I have? Use the Creator Collab one and tell me what it needs.

usign_list_templates resolves the spoken name to a template, and usign_get_template returns the thing that matters: the template's signer roles and its required merge fields. That response is the schema Claude has to fill in — a name, a handle, a fee, a deliverable date, whatever your template declares.

4. Check one before you make thirty

Preview the contract for the first creator so I can read it.

usign_preview_contract renders the contract against your values and returns a validation block — without writing anything to the database. Missing required fields and unfilled roles come back here, as validation errors, rather than as thirty failed creates. Read the render, fix the wording or the fee, preview again.

5. Draft the batch

Looks right. Draft all 24 on that template.

usign_create_contracts_bulk takes up to 300 entries in one call. Every entry is created as a draft. Nothing is emailed. You get back one result per entry, each carrying either a contract_id or its own error — a malformed address on entry 9 does not sink the other 23.

{
  "contracts": [
    {
      "template_version_id": "tv_9k2...",
      "name": "Spring Skincare - @maya.okonkwo",
      "client_name": "Aurelia Skincare",
      "campaign_name": "spring-2026-skincare",
      "external_reference": "campaign:spring-2026-skincare/creator:maya.okonkwo",
      "merge_field_values": {
        "creator_name": "Maya Okonkwo",
        "instagram_handle": "@maya.okonkwo",
        "payment_amount": "1,200.00",
        "deliverable_date": "2026-09-15"
      },
      "signers": [
        { "email": "maya@example.com", "display_name": "Maya Okonkwo", "role_id": "role_creator" }
      ]
    }
  ]
}

6. The gate

Claude summarises the 24 drafts and stops. It has to — there is no argument to usign_create_contracts_bulk that also sends. Read the list. This is the moment where a wrong fee or a stale email is still free to fix.

7. Send

Confirmed. Send them.

usign_send_contract runs once per contract: status flips to sent, signing tokens are minted, and the please-sign email goes out. This tool is annotated destructiveHint: true, so a well-behaved client raises its own confirmation on top of yours.

Why the gate is structural, not a setting

The two-phase model is the reason this is safe to run conversationally. Creating and sending are different calls, and no combination of arguments collapses them into one. An agent that misreads your instruction produces drafts — a recoverable, unsent, unbilled mistake — rather than 24 legal agreements in 24 inboxes.

That property is what makes the whole flow above defensible. It is worth its own read: why create and send are two different calls.

Tag the batch so you can find it later

Three fields on every contract earn their keep the moment the campaign is live:

• campaign_name — the campaign this contract belongs to. Filterable, substring-matched.
• client_name — the brand you are contracting on behalf of. Also filterable.
• external_reference — your own stable handle for this row, e.g. campaign:spring-2026-skincare/creator:maya.okonkwo. This is what makes a retried call idempotent and what your webhook handler will match on later.

Set them at creation. Retrofitting a correlation key onto a batch you have already sent is not a thing you get to do.

Chasing it from the same chat

Who hasn't signed the spring skincare batch yet?

usign_list_contracts filters by campaign_name, client_name, external_reference, template_id, or status — any of draft, sent, viewed, partially_signed, signed, declined, voided, expired. Ask for the unsigned ones a week later and you get the chase list without opening a dashboard.

If one needs to be pulled, usign_void_contract cancels it with a required reason and emails the unsigned signer a withdrawal. There is no delete — a contract that existed continues to have existed, which is the point.

What this does not do

Worth knowing before you build a process on it:

• Templates stay in the editor. No MCP tool creates or publishes a template version. Authoring is deliberate, human work; the agent only fills in a template you already published.
• The agent is the sender, never the signer. It cannot sign on anyone's behalf and cannot touch signature-on-file images.
• Sending is per contract. Bulk creation is one call; dispatch is one call each. That is deliberate.
• Upfluence's data stays in Upfluence. Usign has no concept of a creator, a campaign object, or a contribution — just the strings you chose to write into campaign_name and merge_field_values.
• Contract admin stays in the app. API keys, webhooks, members, and branding are not reachable over MCP.

The part that actually changed

None of the individual steps here are new. Upfluence has always been able to find those creators; Usign has always been able to draft those contracts. What changed is that the list never has to be serialised into a file and re-parsed by a human on the other side — the roster stays a live object in one conversation from search to signature, and the only manual step left is the one you actually want to keep: reading the batch before it goes out.