Forem: Jesse Neumann

How We're Building a Decentralized App Store for AI Agents on Web3

Jesse Neumann — Wed, 13 Aug 2025 17:07:47 +0000

A couple of weeks ago, we dropped an OAuth 2.1 auth server for the Internet Computer. That was just the first brick. We've been heads-down since then, and it's time to show you the building it's part of.

We're building a trustless, on-chain app store for AI agents.

The Problem: Agents Need Tools, Not Walled Gardens

AI agents are getting powerful, but they're often limited to the tools their creators give them. To be truly autonomous, they need a way to discover and securely use a universe of external tools and data sources.

This is where the Model-Context-Protocol (MCP), an open standard from Anthropic, comes in. Think of it as the LSP for AI—a common language that lets any agent talk to any tool.

Our vision is to create the registry for these tools on the IC. No central party controls it. The community verifies the code, and developers publish their work in a transparent, auditable way.

This project is our entry for the ICP hackathon, and we were honored to take first place in the initial round. Here's a look at our progress and the stack.

The Tools: SDKs and a CLI

You can't have an app store without tools to build the apps. So we built them. We're also thrilled to be working alongside others in the community, like @baolongt, who has built a fantastic Rust SDK.

Motoko SDK: We've released the mcp-motoko-sdk to let you build MCP servers in Motoko.
```
mops add mcp-motoko-sdk
```
Repo: github.com/prometheus-protocol/motoko-sdk
Rust SDK (by @baolongt): For the Rustaceans out there.
Repo: github.com/ByteSmithLabs/ic-rmcp
The Publisher CLI: To make publishing easy, we're building npx @prometheus-protocol/cli publish. It's a simple CLI that manages the entire lifecycle. The developer workflow is declarative:
1. npx @prometheus-protocol/cli init: Creates a prometheus.yml manifest.
2. The developer fills in the repo URL and WASM path.
3. npx @prometheus-protocol/cli submit: Reads the manifest, hashes the WASM, and submits it to the registry for verification.

The "Secret Sauce": Composing Open Standards

The only reason we can move this fast is because we're standing on the shoulders of giants. Our entire system is just a composition of incredible, community-driven ICRC standards. No black boxes.

Here's the stack:

ICRC-118 & ICRC-120: These standards, pioneered by @skilesare, give us a robust app store engine for managing versions and a secure upgrade path for canisters.
ICRC-126: The immutable verification logbook. Our submit command calls this to create a public record that a new WASM version is ready for auditing.
ICRC-127 & ICRC-2: The economic engine. This allows anyone to fund bounties on a verification request. When an auditor submits a valid attestation, the bounty is paid out automatically.

We didn't have to invent any of this. We just had to wire it together.

What's Next? Join Us.

The foundation is laid. The SDKs are live. The core logic is being built. Now, we need more builders.

Build an MCP Server: Grab an SDK and build the first on-chain tool for an AI agent.
Talk to Us: We've created the IC MCP Discord with @baolongt to coordinate this effort. If you're building, have ideas, or want to help, this is the place to be. Join the Discord: https://discord.gg/SNqu76Ayzk
Check the Code: The main repo for the registry and orchestrator is here: github.com/prometheus-protocol/prometheus-protocol

Let's build the open infrastructure for the next generation of autonomous systems.

Portal One Just Got a Major Upgrade for AI Agent Developers! (GPT-4.1 Default, Persistent Memory & More)

Jesse Neumann — Mon, 23 Jun 2025 13:23:23 +0000

Hey Devs!

I'm excited to roll out some powerful new features in Portal One, our platform for building and managing AI agents. We've been listening to your feedback and focused on making development faster, agents smarter, and integrations seamless.

Here's the lowdown:

Get Building Instantly (No More API Key Hunt!)

Default GPT-4.1: New projects now use OpenAI's gpt-4.1 by default. Create and test agents right away!
Starter Kit: Default workspace + 3 pre-configured agents to explore from login.
Simplified Creation: Often, a title + description is all you need.

Agents That Remember: Introducing Persistent Memory

Our agents now feature a memory system (powered by Mem0 & Qdrant vector store).
Benefits: Reduced redundancy, personalized responses, agents that learn over time.
Options: 'All' (global memory), 'Chat' (scoped to conversation), 'None'.

Discover & Connect Tools Effortlessly with MCP Server Discovery

New discovery pane shows available remote MCP servers.

Powered by remote-mcp-servers.com – our new open-source public server registry! (Yes, you can contribute!)
Agents can even browse the registry for other servers (direct connection by agents coming soon!).

Enhanced Tool Integration & Context Management

Sync and view resources from MCP servers directly in Portal One.
Attach resources to messages or 'Pin' them for automatic context injection.

Smoother Developer Experience (UX Wins)

Quick add workspace, agent cards view, instant chat buttons, improved conversation management.
We believe these updates will significantly boost your productivity and the capabilities of the AI agents you build.

Read the full announcement: https://portal.one/blog/supercharged-agents-seamless-onboarding-more/

Try Portal One: https://ai.portal.one
Learn more: https://portal.one

What do you think? We're keen to hear your feedback!

My AI Agents Kept Getting Lost, So I Tried Giving Them Blinders (And It Worked!)

Jesse Neumann — Tue, 03 Jun 2025 17:44:38 +0000

Hey Devs!

Jesse here, solo-building Portal One – an AI Agent Command Center to help you build, manage, and actually rely on your AI agents.

One of the biggest challenges I've hit? Getting AI agents to reliably navigate multi-step tasks. You know the feeling: you design this brilliant workflow, and the agent wanders off, picks the wrong tool, or just plain freezes, overwhelmed by choices. It’s like giving a toddler the keys to a spaceship.

My "aha!" moment came when I realized: maybe I'm giving them too much freedom, too many tools, all at once.

So, I dove into making our Model Context Protocol (MCP) server smarter – making it dynamic. Instead of just serving up a static list of all possible tools, it now adapts what the agent can see and do based on the actual state of the task. Think of it as giving the agent blinders, so it can only focus on what's relevant right now.

Here are a few key realizations from that journey:

1. The "Kid in a Candy Store" Problem: Too Many Tools Spoil the Agent

Initially, my MCP server was like an eager waiter listing every single item on a 50-page menu. For an AI agent, this is overwhelming. When an agent sees a giant list of tools, especially if their names are similar or their purposes overlap, it increases the chance of it picking the wrong one or getting stuck in a loop trying to decide.

The Realization:
Agents perform way better with a curated, context-specific list of capabilities. If the task is "start the game," the agent shouldn't even see the "make a guess" tool yet.

How Dynamic MCP Helps:
The server now only exposes tools relevant to the agent's current state. This drastically reduces the "action space" the agent has to consider, making its decisions simpler and more accurate. It's a core idea in the Model Context Protocol – the server can control what list_tools returns based on context.

2. Let the Server Be the "Task Chaperone," Not Just a Vending Machine

My early agents felt like they were just blindly hitting an API. They'd call a tool, get a response, and then it was entirely up to their (sometimes flawed) logic to figure out what to do next. This often led to them trying things out of order or missing crucial steps.

The Realization:
The server can, and should, play an active role in guiding the agent through a task by managing the state and updating the agent's context.

Our Solution: The Number Guessing Game Demo
To really nail this down, I built a simple Number Guessing Game where the AI is the player.

Lobby State: The agent only sees a start_game tool.
Agent calls start_game: The server's internal state changes to "Playing."
Playing State: Now, the start_game tool is gone. Instead, it sees make_guess and give_up_game.
Dynamic Tool Schema: Even better, after a guess, the schema for make_guess can change! If the agent guessed too low, the tool's description might update to "Guess a number between 51 and 100."

This way, the server isn't just passively responding; it's actively shaping the agent's understanding of what's possible and sensible at each step. You can see the code for this demo server on GitHub. It really shows how the MCP TypeScript SDK can be used to build these stateful interactions.

3. "Show, Don't Just Tell" Still Wins for Complex Ideas

Explaining "dynamic, state-aware, context-adaptive capability provisioning for AI agents" is a mouthful and usually gets blank stares.

The Realization:
A simple, interactive demo makes abstract concepts click. The Number Guessing Game, as basic as it is, perfectly illustrates the power of a dynamic MCP. People get it when they see the tool list change or the tool's instructions adapt in real-time.

Want the Full Scoop?

This is just a peek at how we're thinking about making AI agents more dependable. The shift to a dynamic MCP server has been a game-changer for us.

I wrote up a more detailed explanation of the architecture, the "why" behind it, and how it all fits together on the Portal One blog.
And definitely check out the Number Guessing Game demo server on GitHub to see it in action!

Why We Ditched Python for TypeScript (and Survived OAuth) in Our AI Agent MCP Server

Jesse Neumann — Thu, 22 May 2025 15:51:53 +0000

Hey Devs!

I’m Jesse, solo-building Portal One: an AI Agent Command Center to help you orchestrate, automate, and securely manage your AI agents.

One of the biggest undertakings so far? Building a production-ready Model Context Protocol (MCP) server—the backbone that connects user agents to a growing ecosystem of tools and services.

Let’s just say there were some “battle scars” along the way. Here are three of the most valuable (and painful) lessons that shaped our architecture:

1. OAuth 2.0: No Shortcuts in Security

Early on, I was tempted to use simple API keys or JWTs for agent authorization—until I realized the complexity of permissions, multi-tenancy, and external integrations. Security had to be non-negotiable.

Why OAuth 2.0?

Industry standard, widely supported
Granular scopes for fine-grained permissions
Auditable and future-proof

Oh yeah, and it's also part of the MCP Specification.

Key lesson:

Implementing OAuth correctly is hard. Expect lots of trial and error with flows, token introspection, and permission logic.

2. The Big Pivot: Python → TypeScript

I started with Python for the prototype—it’s fast for AI, but when it came to production, I hit walls:

Type safety issues slowed refactoring
Async/concurrency model didn’t fit my needs
Wanted a unified language for backend and integrations

Switching to TypeScript/Node.js instantly paid off:

Strong typing = fewer runtime bugs
First-class async/await model
Huge ecosystem

More importantly though, the official MCP TypeScript SDK had just added support for the two things I needed: authInfo available in the tool context (use the OAuth token to enable authorization), and the Proxy for using the OAuth authorization server (instead of combining the authorization server with the MCP resource server).

Painful truth:

Rewrites are tough, but sometimes necessary for long-term velocity. However, the second time creating something usually results in a better and more thought out implementation.

3. Zod: Data Validation That Won’t Let You Down

With so many tools and unpredictable agent payloads, validating data was a nightmare—until I discovered Zod.

Declarative, typesafe schemas
Automatic TypeScript type inference
Detailed, developer-friendly error messages
Baked into MCP TypeScript SDK

Example:

import { z } from 'zod';

const AgentEvent = z.object({
  agentId: z.string().uuid(),
  tool: z.string(),
  payload: z.record(z.unknown()),
  timestamp: z.coerce.date(),
});

type AgentEvent = z.infer<typeof AgentEvent>;

// Usage:
const parsed = AgentEvent.parse(incomingEvent);

Tip:

Use Zod schemas everywhere: API endpoints, tool integrations, LLM outputs. It's baked into the MCP TypeScript SDK already so you will be using it whether you like it or not.

The following code snippet is the function we use to authorize the token to allow access to resources in the users workspaces.

// Access to the `authInfo` property injected into the request
// by the MCP SDK middleware enables multi-tenancy and authorization.
export function withWorkspaceAccess<T extends z.ZodTypeAny>(
  db: Firestore,
  inputSchema: T,
  handler: (
    args: z.infer<T>,
    req: RequestHandlerExtra<ServerRequest, ServerNotification>,
    userId: string,
  ) => Promise<CallToolResult>,
) {
  return async (
    args: z.infer<T>,
    req: RequestHandlerExtra<ServerRequest, ServerNotification>,
  ) => {
    const userId = req.authInfo?.extra?.user_id as string;
    if (!userId) throw new Error('No user ID found in token.');
    const hasAccess = await checkWorkspaceAccess(db, userId, args.workspace_id);
    if (!hasAccess)
      throw new Error('You do not have access to this workspace.');
    return handler(args, req, userId);
  };
}

This short snippet is great at demonstrating each of the "Battle Scars" outlined above. You can check out the GitHub repo as well to see the full example code.

Want More “Battle Scars”?

This is just a taste!

I wrote up a full deep dive—architecture, more code, and the gnarly bits—on the Portal One blog. Check it out!

What’s the hardest lesson you’ve learned building agent backends, APIs, or scalable integrations?

Drop your “battle scars” in the comments—let’s trade notes and help each other out!