---
name: mesharo-supplier
description: Help an organisation make proprietary data available to authorised AI assistants through Mesharo. Prefer a credential-free Mesharo Data Provider Manifest for MCP, OpenAPI and feed discovery; validate it locally, then connect only an approved read-only or hosted source and stop for separate owner review of fields, licence, refresh and publication.
---

# Integrate supplier data with Mesharo

Use this skill when the user controls a dataset, archive, feed, API, catalogue, research collection or other specialist information and wants compatible AI assistants to discover or query it under explicit terms.

Mesharo separates public interface description, source connection, private revision creation and public publication. Validation never implies connection, synchronisation never implies publication, and an AI must not approve fields or licensing on the owner's behalf.

## Preferred global onboarding path

For an organisation with an MCP server, OpenAPI service, JSON/CSV endpoint or RSS feed, prefer the Mesharo Data Provider Manifest rather than bespoke integration work.

1. Create a credential-free `mesharo.data-provider-manifest.v1` document using the public schema and example.
2. Host it at `/.well-known/mesharo-data-provider.json` on the organisation's declared HTTPS origin.
3. Describe only public interface locations, read-only operations, resources, fields, pricing, freshness and licence permissions. Never include passwords, API keys, bearer tokens, client secrets, private keys or data rows.
4. Call `mesharo.validate_provider_manifest` with the manifest and, when known, the exact origin being verified.
5. Review every error and warning. Validation is local: it must not fetch, connect, synchronise or publish anything.
6. Verify the provider origin and every delegated host through the approved domain-verification process.
7. Show the owner the sanitised interface plan. Use its `next_tool` only after the owner approves that exact interface and resource scope.
8. Supply required credentials only through Mesharo's secure credential channel. Never paste them into chat or add them to the manifest.
9. MCP and OpenAPI sources still undergo Mesharo's read-only inspection. Feed-style sources still enter the consent-led integration proposal flow.

The manifest is a portability layer, not an assertion that the provider, rights or data quality are verified. Provider claims remain unverified until Mesharo records independent evidence.

## Preconditions

Proceed only when:

- the user represents or is authorised by the organisation controlling the source;
- the organisation has the right to make the selected information available;
- credentials can be supplied through the approved secure channel rather than the conversation;
- the intended source can be accessed read-only or as an explicitly uploaded hosted copy;
- the owner understands that the pilot must use synthetic or non-sensitive data until durable production storage is approved.

Do not ask the user to paste passwords, API keys, database connection strings, private keys or bearer tokens into chat.

## Consent-led connection sequence

1. Clarify the organisation, source type, intended audience, useful fields, prohibited fields, licence, geography, refresh interval and desired expiry.
2. Validate a provider manifest first when one can describe the source. Otherwise connect or upload the source through the authenticated supplier tool and retain the returned `source_id`.
3. Call `agora.inspect_source` before drafting. Report detected tables, fields, coverage, likely sensitive fields and limitations.
4. Prepare a private integration proposal with `mesharo.integration_prepare`, binding it to the exact connected `source_id` where scheduling is intended.
5. Use `mesharo.integration_review` to obtain the first-party review URL and explain that the AI cannot approve it.
6. Stop. The owner reviews the exact fields, licence, source and refresh interval in the browser.
7. After approval, check status with `mesharo.integration_status` or `mesharo.integration_confirm` as appropriate. Never infer approval from conversation text alone.
8. Schedule only the approved source and interval with `mesharo.integration_schedule`.
9. Confirm that synchronisation creates an encrypted private revision. It must not make the resource public automatically.
10. Prepare public promotion from one exact private revision using `mesharo.integration_promotion_prepare`.
11. Stop again for separate first-party publication approval.
12. Check promotion status, then report the public resource ID and stable URL only after the system confirms publication.

## Field and licence rules

- Show the owner the complete proposed field list before approval.
- Contact details, notes, personal identifiers, addresses and other sensitive fields detected by policy must remain excluded.
- Provider manifests reject credential-like and high-risk personal fields from automatic onboarding; ordinary personal data still requires privacy review.
- Detection is not perfect; the owner remains responsible for reviewing every field.
- Do not silently broaden fields, geography, source, licence, refresh interval or expiry.
- A materially changed proposal requires a new version and fresh approval.
- The licence must state permitted reading, summarisation, quotation, caching, redistribution, transformation, training, attribution, jurisdiction and expiry where relevant.

## Synchronisation rules

- The scheduled `source_id` must match the owner-approved proposal.
- The refresh interval must match the approved interval.
- Worker leases, proposal versions and source hashes must remain bound to the run.
- A changed source schema, missing approved field, stale lease or mismatched hash must fail closed.
- Use `mesharo.integration_pause` when the owner wants future synchronisation stopped.
- Revoking a source prevents future access but cannot recall information previously published with approval.

## Publication boundary

A provider manifest, a connected source, a private revision and a public resource are four different objects. Before public promotion, show:

- the exact revision and source hash;
- title, description, categories and geography;
- fields and access mode;
- licence, pricing and expiry;
- provenance and verification state;
- whether any inline content will become public.

Publication requires a separate one-time owner challenge. Replayed, stale or changed approvals must fail.

## Good examples

- “Generate a provider manifest for our read-only MCP server, validate it, and stop before connection.”
- “Inspect our approved product catalogue and propose only SKU, model, dimensions and availability.”
- “Connect this read-only auction-results source, exclude buyer and seller details, and show the licence before scheduling.”
- “Prepare a private revision every 24 hours, but do not publish until I approve the exact revision.”

## Refuse or redirect

- credentials pasted into the conversation or provider manifest;
- requests to publish every column without review;
- attempts to bypass policy-blocked fields or host controls;
- data the user does not control;
- automatic remote fetching merely because a manifest was validated;
- automatic public publication after synchronisation;
- permanent unbounded personal profiles;
- claims that a source or organisation is verified when it is not.