Lender Trinity MCP Tools - Droplinked Developers

Three agent-callable MCP tools wrap the LenderRegistry trinity public surface, letting consumer agents resolve credit-risk attestations to their issuer + recommend lenders/service providers for a given merchant — without operator handholding.

`verify_lender`

Resolves a lenderId (referenced in a Schema B attestation) to the lender’s public profile + signing wallet.

// Agent call
const profile = await mcp.callTool('verify_lender', { lenderId: 'crediblex-uae' });

{
  "found": true,
  "lenderId": "crediblex-uae",
  "displayName": "CredibleX (UAE)",
  "archetype": "fsra-licensed",
  "jurisdiction": "AE",
  "status": "ACTIVE",
  "signingWallet": "0x...",
  "regulatorReference": "FSRA-12345",
  "issuedAttestationCount": 42,
  "lastAttestationAt": "2026-06-11T22:00:00Z"
}

Use case: A consumer agent has parsed a Schema B attestation and needs to display the issuing lender’s human-readable name + regulator reference. Forensic cross-check between signingWallet and the on-chain issuerWallet detects schema impersonation. Wraps: GET /v2/lenders/:lenderId.

`get_lender_history`

Trace a lender’s full lifecycle — REGISTERED, STATUS_CHANGED, metadata edits. Verifiers use this to determine whether a lender was ACTIVE at the time a Schema B credit-risk attestation was minted, and to surface any SUSPENDED / ARCHIVED transitions.

const history = await mcp.callTool('get_lender_history', { lenderId: 'crediblex-uae' });

{
  "lenderId": "crediblex-uae",
  "count": 3,
  "events": [
    {
      "occurredAt": "2026-05-01T09:15:00Z",
      "eventType": "LENDER_REGISTERED",
      "previousStatus": null,
      "newStatus": "PENDING_KYB"
    },
    {
      "occurredAt": "2026-05-03T14:22:00Z",
      "eventType": "LENDER_STATUS_CHANGED",
      "previousStatus": "PENDING_KYB",
      "newStatus": "ACTIVE"
    },
    {
      "occurredAt": "2026-05-20T11:00:00Z",
      "eventType": "LENDER_DISPLAY_NAME_CHANGED",
      "previousStatus": null,
      "newStatus": null
    }
  ]
}

Event types: LENDER_REGISTERED / LENDER_STATUS_CHANGED / LENDER_DISPLAY_NAME_CHANGED / LENDER_JURISDICTION_CHANGED / LENDER_SIGNING_WALLET_CHANGED / LENDER_REGULATOR_REFERENCE_CHANGED / LENDER_CONTACT_NOTES_CHANGED. previousStatus / newStatus are non-null only for LENDER_REGISTERED + LENDER_STATUS_CHANGED events; both are null for metadata-change events. Use case: An agent presenting a Schema B credit-risk attestation needs to confirm the issuing lender was in good standing at attestation time — walk the timeline, find the LENDER_STATUS_CHANGED events bracketing the attestation’s occurredAt, and assert the lender was ACTIVE in that window (and not subsequently SUSPENDED / ARCHIVED). Wraps: GET /v2/lenders/:lenderId/timeline.

`recommend_lender`

“Which lenders should this merchant approach?” — given a jurisdiction (+ optional archetype filter), returns the ordered list of ACTIVE lenders by exact-match-first, GLOBAL-fallback-second, track-record sort within group.

const recs = await mcp.callTool('recommend_lender', {
  jurisdiction: 'AE',
  archetype: 'fsra-licensed',
  limit: 5,
});

{
  "jurisdiction": "AE",
  "count": 2,
  "recommendations": [
    { "lenderId": "crediblex-uae", "matchKind": "exact-jurisdiction", "rank": 1 },
    { "lenderId": "valinor-vault", "matchKind": "global-fallback", "rank": 2 }
  ]
}

Use case: Merchant onboarding flow asking “which lenders should I apply to?” — agent surfaces exact-jurisdiction matches first (e.g. CredibleX for UAE merchants) with GLOBAL DeFi-vault fallback (e.g. Valinor) ranked second. Wraps: GET /v2/lender-routing/recommend.

`recommend_service_provider`

“Which WMS partner should this merchant route to?” — same pattern as recommend_lender but for InventoryOS partners (WMS/3PL).

const recs = await mcp.callTool('recommend_service_provider', {
  archetype: 'stord',
  limit: 5,
});

{
  "archetype": "stord",
  "count": 1,
  "recommendations": [
    {
      "providerId": "stord-us-east-1",
      "displayName": "Stor'd US-East",
      "successfulIngestionCount": 47,
      "rank": 1
    }
  ]
}

Use case: Merchant fulfillment onboarding asking “which 3PL should I integrate with” — agent ranks by track record (successful ingestion count + recency). Wraps: GET /v2/service-provider-routing/recommend.

`get_methodology_versions`

Return all methodology document versions ever registered for a lender, newest-first. Verifiers use this to trace a lender’s full methodology lineage when an on-chain Schema B attestation cites a specific hash.

const versions = await mcp.callTool('get_methodology_versions', { lenderId: 'crediblex-uae' });

{
  "lenderId": "crediblex-uae",
  "count": 3,
  "versions": [
    {
      "version": 3,
      "methodologyHash": "0xabc123...",
      "documentUrl": "https://crediblex.ae/methodology/v3.pdf",
      "displayName": "CredibleX Credit-Risk Methodology v3",
      "status": "ACTIVE",
      "effectiveAt": "2026-06-01T00:00:00Z",
      "supersededAt": null
    },
    {
      "version": 2,
      "methodologyHash": "0xdef456...",
      "documentUrl": "https://crediblex.ae/methodology/v2.pdf",
      "displayName": "CredibleX Credit-Risk Methodology v2",
      "status": "SUPERSEDED",
      "effectiveAt": "2026-04-15T00:00:00Z",
      "supersededAt": "2026-06-01T00:00:00Z"
    },
    {
      "version": 1,
      "methodologyHash": "0x789abc...",
      "documentUrl": "https://crediblex.ae/methodology/v1.pdf",
      "displayName": "CredibleX Credit-Risk Methodology v1",
      "status": "SUPERSEDED",
      "effectiveAt": "2026-03-01T00:00:00Z",
      "supersededAt": "2026-04-15T00:00:00Z"
    }
  ]
}

Status enum: ACTIVE / SUPERSEDED / REVOKED. Privacy + bounds: no notes field is exposed (operator-only); response is hard-capped at 100 versions per lender. Use case: An agent presented with a Schema B attestation needs to walk the lender’s methodology history to see whether the cited methodologyHash is the most recent version or has been superseded — flag stale citations to the consuming application. Wraps: GET /v2/methodologies/:lenderId/versions.

`request_brand_attestation`

Queue a Schema A brand-attestation request on behalf of a merchant. The request walks PENDING → APPROVED → MINTED (or → REJECTED); the on-chain mint is gated behind operator review — calling this tool does not directly mint.

const result = await mcp.callTool('request_brand_attestation', {
  shopSlug: 'unstoppable',
  notes: "Filed on behalf of merchant during agentic onboarding",
});

{
  "requestId": "65f8a1b2c3d4e5f6a7b8c9aa",
  "status": "PENDING",
  "message": "Your request is in the operator review queue"
}

Idempotent on (shopSlug, status: PENDING) — re-calling while a PENDING row exists returns the same requestId instead of creating a duplicate. The agent never has to handle a “duplicate” 4xx. Use case: an agent orchestrating a merchant’s full onboarding flow — application form, lender match, brand-attestation request — needs to queue the brand-attestation request without the merchant clicking the shop-builder CTA. Pair with get_brand_attestation_status (next) to detect terminal state before handing back to the merchant. Wraps: POST /v2/attestations/brand/:shopSlug/request. Full walkthrough at Brand attestation: request → mint → verify.

`get_brand_attestation_status`

Poll the brand-attestation request lifecycle. The status discriminator is one of NONE (no request exists), PENDING, APPROVED, MINTED, or REJECTED. The endpoint always returns 200; missing rows are reported as the synthetic NONE state so the agent never has to handle a 404.

const status = await mcp.callTool('get_brand_attestation_status', {
  shopSlug: 'unstoppable',
});

{
  "status": "MINTED",
  "request": {
    "requestId": "65f8a1b2c3d4e5f6a7b8c9aa",
    "shopSlug": "unstoppable",
    "status": "MINTED",
    "attestationUid": "0x9c4f7a3e8b1d2c6f5a0b8e9d1c2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f",
    "mintedAt": "2026-06-13T07:42:11Z",
    "createdAt": "2026-06-12T18:00:00Z"
  }
}

Privacy: operator-private fields (decidedBy, decisionReason, mintError, mintAttempts, merchantId, free-text notes) are scrubbed from this response. They only surface on the SUPER_ADMIN admin route. Use case: an agent loop walking a brand-attestation request from PENDING → MINTED. Recommended cadence: 30s → 60s → 120s exponential backoff for up to ~5 minutes, then hand the lifecycle back to the merchant. On MINTED, call verify_brand_attestation to confirm the on-chain envelope decodes cleanly and surface the easscan link to the merchant. Wraps: GET /v2/attestations/brand/:shopSlug/request-status.

`get_trust_fabric_stats`

“What’s the platform’s overall trust-fabric scale?” — returns aggregate-only counts across lenders, service providers, methodology versions, and attestations by schema. No PII, no per-row data, no auth required. Use this to gauge platform scale before issuing per-merchant queries or to power a partner-facing dashboard.

const stats = await mcp.callTool('get_trust_fabric_stats', {});

{
  "asOf": "2026-06-13T02:00:00Z",
  "lenders": { "total": 2, "active": 2, "pendingKyb": 0, "suspended": 0, "archived": 0 },
  "serviceProviders": { "total": 5, "active": 4, "pendingKyb": 1, "suspended": 0, "archived": 0 },
  "methodologies": { "totalLenders": 2, "activeVersions": 1, "supersededVersions": 3, "revokedVersions": 0 },
  "attestations": { "schemaA": 12, "schemaB": 8, "schemaC": 4, "schemaD": 2 }
}

Use case: partner dashboards showing droplinked trust-fabric scale; agent platform-scale signaling; freshness/health probes. Wraps: GET /v2/trust-fabric/stats.

Brand attestation: request → mint → verify — end-to-end Schema A lifecycle walkthrough
Trust Fabric overview — full architecture
MCP Server — connection + auth

​verify_lender

​get_lender_history

​recommend_lender

​recommend_service_provider

​get_methodology_versions

​request_brand_attestation

​get_brand_attestation_status

​get_trust_fabric_stats

​Related