Portal as the Publishing Layer for the Agentic Web

[gosunuts]

Goal

Broaden Portal's AI strategy beyond agent-specific integrations by making Portal the easiest way to publish locally running agents, MCP servers, APIs, and tools.

Core positioning:

Publish your local agent to the web.

Portal should remain a protocol-agnostic networking layer rather than becoming an MCP, A2A, or agent runtime.

Why

AI tools are making it increasingly easy to build agents and MCP servers locally.

The remaining problem is distribution:

Build locally
    ↓
Make it publicly reachable
    ↓
Let other agents discover and call it
    ↓
Optionally monetize access

Portal already provides most of this infrastructure:

• public HTTPS reachability
• persistent identity
• end-to-end TLS / ECH
• relay discovery and failover
• multi-hop routing
• x402 payments

Primary use case: Remote MCP

Remote MCP should be the first distribution wedge.

localhost:3000/mcp
        ↓
      Portal
        ↓
https://public.example/mcp
        ↓
MCP clients / Registry

Suggested message:

Your MCP server works on localhost. Now make it remote.

Actions:

• Add a short Remote MCP publishing guide and demo.
• Document localhost → Portal → MCP Registry.
• Let the existing Agent Skill detect and verify MCP endpoints where useful.
• Do not implement MCP semantics inside Portal core.

A2A can be supported similarly through public HTTPS and Agent Card verification, with implementation priority driven by ecosystem adoption and user demand.

Distribution strategy

Portal already supports several major coding-agent environments, and additional integrations can continue to be added where they are useful.

At the same time, support alone does not guarantee discovery. We should also invest in distribution surfaces where agent and MCP developers already publish their work.

Potential channels include:

• MCP projects and templates
• MCP Registry workflows
• agent/plugin marketplaces
• third-party agent READMEs
• tutorials for publishing local agents
• additional coding-agent integrations as new ecosystems emerge

The goal is to make Portal available across agent environments while also making it easier for developers to discover Portal when they need to publish something publicly.

The desired viral loop is:

build agent
   ↓
publish with Portal
   ↓
share public endpoint
   ↓
another developer discovers Portal
   ↓
publishes their own agent

A useful success metric is the number of third-party agent and MCP projects that mention, integrate, or recommend Portal as a publishing option.

Technical discoverability

Discoverability should not be limited to documentation, tutorials, or marketplace listings.

Portal should also explore making publication and discovery part of the product workflow itself.

For MCP, a possible flow is:

local MCP server
      ↓
Portal creates a stable public endpoint
      ↓
generate / validate server.json
      ↓
publish to the MCP Registry
      ↓
verify registry presence
      ↓
downstream registries and marketplaces discover the update

Potential capabilities include:

• Detect a remotely publishable MCP endpoint and generate the corresponding server.json metadata.
• Integrate with the official mcp-publisher workflow for validation and publication.
• Allow an Agent Skill or future CLI workflow to publish to the MCP Registry when explicitly requested.
• Verify that the published server appears in the official Registry API.
• Re-check that the registered Portal endpoint remains publicly reachable.
• Detect registry metadata or endpoint drift after publication.
• Check whether major downstream registries or marketplaces have indexed the server where APIs or other integration points are available.
• Prefer stable Portal identities and persistent endpoints for publicly registered services instead of temporary tunnel URLs.

Registry publication should remain an explicit action. Creating a tunnel should not automatically publish its metadata to an external registry.

After publication, however, verification and health checks can be automated:

registered endpoint
      ↓
endpoint health check
      ↓
registry presence check
      ↓
metadata/version drift check
      ↓
downstream indexing check

Portal should prefer existing standard registries as the source of truth instead of creating a competing Portal-specific registry.

Marketplace-specific integrations can be implemented as optional adapters where useful:

                 Official MCP Registry
                        ↑
                   publish once
                        │
Portal ────────────────┘
  │
  ├─ verify official registry
  ├─ check GitHub MCP index
  ├─ check other marketplaces
  └─ report propagation status

The broader direction is:

Distribution should gradually become a product capability, not only a marketing activity.

Portal should not only make an agent reachable. Where standards allow it, Portal should help make that public endpoint discoverable, verifiable, and maintainable across the agent ecosystem.

Direction

Portal should evolve beyond a localhost tunnel toward:

The publishing layer for the agentic web.

Portal should provide reachability, identity, trust, routing, discoverability, and payments while carrying MCP, A2A, HTTP, and future protocols without depending on any one of them.