Bringing MCP Tools Into a Trust Fabric

MCP is great at letting an agent call a tool. It says nothing about whether that tool should be trusted, who vouches for it, or whether it's been revoked. ASPL ingests MCP tools and wraps them in exactly those guarantees.

Two ways in

You can hand ASPL raw MCP tool definitions, or point it at a live MCP server and let it fetch them over JSON-RPC:

# from raw definitions
POST /v1/ingest/mcp
{ "server_url": "https://tools.example",
  "tools": [ ...MCP tool defs... ] }

# or from a live server (tools/list over JSON-RPC)
POST /v1/ingest/mcp/url
{ "server_url": "https://my-mcp-server/rpc" }

What ingestion adds

Each MCP tool becomes an ASPL capability, which means it now has:

• a content hash and a node co-signature;
• a trust score that grows as distinct agents use it successfully;
• semantic discoverability by intent, alongside your other capabilities;
• a revocation path and a transparency-log entry.

Scanned on the way in

Ingested content runs through the same security scanner as anything published directly. A tool whose definition contains prompt-injection or exfiltration patterns is flagged — rejected outright for executable types, quarantined as RED for inert data — so importing a server's catalogue doesn't import its risks blindly.

The point isn't to compete with MCP — it's to give MCP tools provenance and a reputation they don't carry on their own.