DEV Community: Ekim Cem Ülger

Anyone tried it ?

Ekim Cem Ülger — Thu, 16 Oct 2025 08:26:55 +0000

Ekim Cem Ülger

Oct 15 '25

Building a ChatGPT App with VoltAgent and the Apps SDK

#agents #mcp #chatgpt #voltagent

Comments

5 min read

Building a ChatGPT App with VoltAgent and the Apps SDK

Ekim Cem Ülger — Wed, 15 Oct 2025 22:39:20 +0000

This guide shows how to use VoltAgent — a TypeScript framework for creating agents, MCP servers, and workflows — to deploy an MCP (Model Context Protocol) server and connect it to ChatGPT Apps using the Apps SDK. It demonstrates how to go from setup to a working ChatGPT-connected app step by step.

What Are ChatGPT Apps?

OpenAI recently introduced ChatGPT Apps — a new framework that allows developers to build and publish their own tools and services directly inside ChatGPT. Using the Apps SDK, you can connect APIs, workflows, and MCP servers to ChatGPT, turning them into interactive applications that users can access directly from the chat interface.

ChatGPT Apps are the next evolution of the MCP (Model Context Protocol) ecosystem. They allow developers to define capabilities through tools, resources, and prompts, and make them discoverable within ChatGPT itself.

💡 This is my personal perspective: In the future, OpenAI is expected to expand this system into a marketplace — a kind of “App Store for ChatGPT” — where developers can publish and share their MCP-powered apps with millions of users.

This tutorial focuses on building and deploying one of these ChatGPT Apps using VoltAgent.

1. Create the App

Start by creating a new VoltAgent app:

pnpm create voltagent-app my-agent-app

When prompted, select your provider — for now, choose OpenAI.

Then install the MCP server package:

pnpm add @voltagent/mcp-server

2. Basic MCP Server Setup

In your mcp/server.ts file, import and initialize the MCP server:

import { MCPServer } from "@voltagent/mcp-server";

export const mcpServer = new MCPServer({
  name: "voltagent-example",
  version: "0.1.0",
  description: "VoltAgent MCP example",
});

You can keep the configuration simple for now — we’ll update it later.

3. Integrate with VoltAgent

When VoltAgent initializes, it automatically sets up your agent, workflows, and server. To include the MCP server, simply add it to the configuration.

import "dotenv/config";
import { VoltAgent, VoltOpsClient, Agent, Memory } from "@voltagent/core";
import { LibSQLMemoryAdapter } from "@voltagent/libsql";
import { createPinoLogger } from "@voltagent/logger";
import { openai } from "@ai-sdk/openai";
import { honoServer } from "@voltagent/server-hono";
import { expenseApprovalWorkflow } from "./workflows";
import { weatherTool } from "./tools";
import { mcpServer } from "./mcp/server";

// Create a logger instance
const logger = createPinoLogger({
  name: "my-voltagent-app",
  level: "info",
});

// Configure persistent memory (LibSQL / SQLite)
const memory = new Memory({
  storage: new LibSQLMemoryAdapter({
    url: "file:./.voltagent/memory.db",
    logger: logger.child({ component: "libsql" }),
  }),
});

const agent = new Agent({
  name: "my-voltagent-app",
  instructions: "A helpful assistant that can check weather and help with various tasks",
  model: openai("gpt-4o-mini"),
  tools: [weatherTool],
  memory,
});

new VoltAgent({
  agents: {
    agent,
  },
  workflows: {
    expenseApprovalWorkflow,
  },
  mcpServers: {
    mcpServer,
  },
  server: honoServer(),
  logger,
  voltOpsClient: new VoltOpsClient({
    publicKey: process.env.VOLTAGENT_PUBLIC_KEY || "",
    secretKey: process.env.VOLTAGENT_SECRET_KEY || "",
  }),
});

This is the automatically generated initialization code, with the addition of the mcpServers key.

4. Create a Mock MCP Tool

Let’s create a mock weather tool to test the MCP connection.

import { createTool } from "@voltagent/core";
import { MCPServer } from "@voltagent/mcp-server";
import { z } from "zod";

export const getWeatherTool = createTool({
  name: "get_weather",
  description: "Return mock weather data for a given location",
  parameters: z.object({
    location: z.string().describe("Location to fetch weather for"),
  }),
  execute: async (params: any) => {
    const { location } = params;
    return {
      success: true,
      location,
      forecast: "☀️ Sunny, 24°C (mock data)",
      timestamp: new Date().toISOString(),
    };
  },
});

export const mcpServer = new MCPServer({
  id: "voltagent-example",
  name: "voltagent-example",
  version: "0.1.0",
  description: "VoltAgent MCP example with a mock Get Weather tool",
  tools: {
    getWeather: getWeatherTool,
  },
});

Then start the development server:

pnpm run dev

If successful, your terminal should display:

══════════════════════════════════════════════════
  VOLTAGENT SERVER STARTED SUCCESSFULLY
══════════════════════════════════════════════════
  ✓ HTTP Server:  http://localhost:3141
  ✓ Swagger UI:   http://localhost:3141/ui

  ✓ Registered Endpoints: 10 total

    MCP Endpoints
      GET    /mcp/servers
      GET    /mcp/servers/{serverId}
      GET    /mcp/servers/{serverId}/tools
      GET    /mcp/servers/{serverId}/prompts
      GET    /mcp/servers/{serverId}/prompts/{promptName}
      GET    /mcp/servers/{serverId}/resources
      GET    /mcp/servers/{serverId}/resources/contents
      GET    /mcp/servers/{serverId}/resource-templates
      POST   /mcp/servers/{serverId}/tools/{toolName}
      POST   /mcp/servers/{serverId}/logging/level

  Test your agents with VoltOps Console: https://console.voltagent.dev
══════════════════════════════════════════════════

5. Testing Locally with VoltOps Console

Visit https://console.voltagent.dev/mcp.

Enter your local HTTP server URL:

http://localhost:3141

You should see your get-weather tool listed. Try clicking it and typing a random location — you’ll get a mock weather response.

💡 Don’t forget to adjust the MCP server description to match your tool’s purpose (e.g., mention weather forecasting).

6. Exposing a Public Endpoint

ChatGPT requires an HTTPS endpoint. During development, you can use ngrok to expose your local server.

Install ngrok (see ngrok.com) and then, in a separate terminal window, run:

ngrok http 3141
# Forwarding: https://<subdomain>.ngrok.app -> http://127.0.0.1:3141

Your VoltAgent Hono service runs on port 3141 by default.

7. Connect Your MCP Server to ChatGPT

Open ChatGPT Settings → Click your avatar (bottom-left) → Settings → Go to Apps.

Enable Developer Mode

Request access from your OpenAI partner contact or workspace admin.
Then toggle: Settings → Connectors → Advanced → Developer Mode.
Once enabled, you’ll see a Create button under Settings → Connectors.

Create a Connector

Ensure your MCP server is reachable over HTTPS (via ngrok).
In ChatGPT: go to Settings → Connectors → Create.
Fill in:
- Connector Name: VoltAgent Example Server
- Description: Provides example tools via VoltAgent MCP server.
- Connector URL: https://<subdomain>.ngrok.app/mcp/voltagent-example/mcp
Click Create.

Disable Authentication (for testing)

Disable auth during local testing; re-enable for production.

Verify the Integration

If successful, you’ll see your get-weather tool listed in ChatGPT.
You can now call your MCP tool directly from within ChatGPT — your VoltAgent app is live!

Discussion

Now that OpenAI is opening the door to custom ChatGPT Apps built with the Apps SDK, we’re at the start of a new developer ecosystem around MCP. Using VoltAgent makes it easier to structure these apps with agents, workflows, and tools.

👉 What do you think? Which types of apps do you believe will perform best in a future ChatGPT marketplace — productivity tools, automations, educational helpers, or something else? And what are your own plans for building and sharing MCP-based apps?

If you run into any issues while following this guide or during development, feel free to share your questions or problems here — happy to help troubleshoot and improve together! 🚀

Bring your Next.JS API Experience

Ekim Cem Ülger — Mon, 01 May 2023 09:10:48 +0000

Hello fellow developers,

I've been noticing a lot of discussion around Next.js APIs lately. It seems that serverless functions can become expensive as user traffic grows, especially when compared to other providers besides Vercel. I'm curious to hear your thoughts on when and why you prefer to use Next.js APIs. Let's have a discussion about it in the comments below.

By the way, if you're interested in learning about some of the challenges that Josh faced while using Next.js APIs, you may find this video helpful: https://www.youtube.com/watch?v=6xvLUWpCSFM.

NextAuth.js / Auth.js credential authentication with methods you need !

Ekim Cem Ülger — Wed, 18 Jan 2023 20:49:24 +0000

Hey Devs !

As a front-end developer my nightmare was to handle the user authentication.

With NextAuth.js (I will call it auth.js since they are changing their name) the user authentication handling is much easier. Let's take a look at how we handle it with Next.js

Here are the steps that you need to follow;

Create a next app.
yarn create next-app

Go inside your project and add auth.js
yarn add next-auth

To implement the auth.js, we need to create an api folder in our pages directory and create the [...nextauth].js

/pages
        /api
          /auth
            [...nextauth].js

In your pages/api/auth/[...nextauth].js create the default function and credential provider.

Since you can configure your NextAuth, we will create an authOptions object to store the configurations that we want aplly.

import NextAuth from "next-auth"
import CredentialsProvider from "next-auth/providers/credentials";

export const authOptions = {}

export default NextAuth(authOptions);

Now let's start to adding options

Since we are using custom backend, we are going to use CredentialsProvider and we will pass this to providers key. This key stores all of providers that you want to use in your application with their configurations.

providers: [
    CredentialsProvider({
      type: "credentials",

 credentials: {
        email: {
          label: "Email",
          type: "email",
        },
        password: { label: "Password", type: "password" },
      },
  ],


...rest

If you want to use your own Sign In page, you do not need to pass email and password keys to credentials object. Anyway, we are going to use Auth.js's sign in page in this.

In this case we need the email address and password of user to authenticate so we pass email and password fields.

Now we all set in [...nextAuth].js file with its credentials object.

to fetch login data to your custom backend now we need to pass authorize function with your custom sign in api;

 async authorize(credentials) {
        const credentialDetails = {
          email: credentials.email,
          password: credentials.password,
        };

        const resp = await fetch(backendURL + "/auth/login", {
          method: "POST",
          headers: {
            Accept: "application/json",
            "Content-Type": "application/json",
          },
          body: JSON.stringify(credentialDetails),
        });
        const user = await resp.json();
        if (user.is_success) {
          return user;
        } else {
          console.log("check your credentials");
          return null;
        }
      },

In this case, backendURL is a constant of your server's ip and host, and the auth/login is the endpoint of your backend.

If your credentials are correct, the backend should response you a success message and you need to check it if its success or not.

For now the [...nextAuth].js is something like this:

import NextAuth from "next-auth/next";
import CredentialsProvider from "next-auth/providers/credentials";

const backendURL = process.env.NEXT_PUBLIC_BACKEND_URL;
export const authOptions = {
  providers: [
    CredentialsProvider({
      type: "credentials",
      credentials: {
        email: {
          label: "Email",
          type: "email",
        },
        password: { label: "Password", type: "password" },
      },
      async authorize(credentials) {
        const credentialDetails = {
          email: credentials.email,
          password: credentials.password,
        };

        const resp = await fetch(backendURL + "/auth/login", {
          method: "POST",
          headers: {
            Accept: "application/json",
            "Content-Type": "application/json",
          },
          body: JSON.stringify(credentialDetails),
        });
        const user = await resp.json();
        if (user.is_success) {
          console.log("nextauth daki user: " + user.is_success);

          return user;
        } else {
          console.log("check your credentials");
          return null;
        }
      },
    }),
  ],
};

export default NextAuth(authOptions);

since we are using JWT , you need to pass session object with strategy key as:

session: {
    strategy: "jwt",
    maxAge: 30 * 24 * 60 * 60, // 30 days
  },

you can pass a maxAge to store your user in the web browser as authenticated as you want, here it stores for 30 days.

Do not forget that JWT maxAge can be also defined in the backend so you should consider the backend JWT maxAge when
setting this value.

Implementing the callbacks to use session in client-side

Now you can fetch user in backend and your response should have some information that will be used in the client side while fetching some APIs.

With the help of callbacks, we will persist the backend access token to token provided by auth.js right after signin.

For this, we need to pass callbacks object to [...nextauth].js file as:

callbacks: {
    jwt: async ({ token, user }) => {
      if (user) {
        token.email = user.data.auth.email;
        token.username = user.data.auth.userName;
        token.userType = user.data.auth.userType;
        token.accessToken = user.data.auth.token;
      }

      return token;
    },
}

In this case, from the response provided by backend, user object has various values like email,userName,userType and token.

In jwt object we are calling the async function that stores our response in token.

After that, from frontend, we need to add the token to cookies in user session, like this :

callbacks: {
    jwt: async ({ token, user }) => {
      if (user) {
        token.email = user.data.auth.email;
        token.username = user.data.auth.userName;
        token.user_type = user.data.auth.userType;
        token.accessToken = user.data.auth.token;
      }

      return token;
    },
    session: ({ session, token, user }) => {
      if (token) {
        session.user.email = token.email;
        session.user.username = token.userName;
        session.user.accessToken = token.accessToken;
      }
      return session;
    },
  },

with the help of session callback, now we can use the useSession hook provided by auth.js in the client-side to get information that we pass to session object.

Before going into the client side, lets check your [...nextAuth].js:

import NextAuth from "next-auth/next";
import CredentialsProvider from "next-auth/providers/credentials";

const backendURL = process.env.NEXT_PUBLIC_BACKEND_URL;
export const authOptions = {
session: {
    strategy: "jwt",
    maxAge: 30 * 24 * 60 * 60, // 30 days
  },
  providers: [
    CredentialsProvider({
      type: "credentials",
      credentials: {
        email: {
          label: "Email",
          type: "email",
        },
        password: { label: "Password", type: "password" },
      },
      async authorize(credentials) {
        const credentialDetails = {
          email: credentials.email,
          password: credentials.password,
        };

        const resp = await fetch(backendURL + "/auth/login", {
          method: "POST",
          headers: {
            Accept: "application/json",
            "Content-Type": "application/json",
          },
          body: JSON.stringify(credentialDetails),
        });
        const user = await resp.json();
        if (user.is_success) {
          console.log("nextauth daki user: " + user.is_success);

          return user;
        } else {
          console.log("check your credentials");
          return null;
        }
      },
    }),
  ],
callbacks: {
    jwt: async ({ token, user }) => {
      if (user) {
        token.email = user.data.auth.email;
        token.username = user.data.auth.userName;
        token.user_type = user.data.auth.userType;
        token.accessToken = user.data.auth.token;
      }

      return token;
    },
    session: ({ session, token, user }) => {
      if (token) {
        session.user.email = token.email;
        session.user.username = token.userName;
        session.user.accessToken = token.accessToken;
      }
      return session;
    },
  },
};

export default NextAuth(authOptions);

Use the session in client side !

Lets start wrapping our application with SessionProvider;

Move to your _app.js file in the route;

/pages
       _app.js

and import SessionProvider from next-auth

import { SessionProvider } from "next-auth/react";

As well as you import the session provider, do not forget to pass session in to the page props and wrap your application with SessionProvider like this in your _app.js file;

import { SessionProvider } from "next-auth/react";

function MyApp({ Component, pageProps: { session, ...pageProps } }) {
  return (
    <SessionProvider session={session}>
          <Component {...pageProps} />
    </SessionProvider>
  );
}

export default MyApp;

After that everything is simple, just import useSession()hook from next-auth and handle any session information that you passed in the session callback function in [...nextauth].js file.


import { useSession} from "next-auth/react";
const { data, status } = useSession();

Now you can use any data that you passed in session callback function by using data object from useSession().

In this example we can access the user access token which we got from server as : session.user.accessToken

Also, you can check if the user is authenticated in the serverside, so you may want to protect your pages.

In your component, you may use session in getServerSideProps function as:

import getSession to use session in serverside from :

import {getSession } from "next-auth/react";

export async function getServerSideProps(context) {

  const session = await getSession(context);
  if (!session) {
    //if not exists, return a temporary 302 and replace the url with the given in Location.
    context.res.writeHead(302, { Location: "/signin" });
    context.res.end();

    //do not return any session.
    return { props: {} };
  }
}

And this is a simple use of credentials provider from Auth.js

Do let me know if you have any suggestions or questions in the commends !

When do you use which one?

Ekim Cem Ülger — Sat, 17 Sep 2022 03:16:50 +0000

Hey Front-end web developers, I have a question for you !

Nowadays there are multiple choices between CSS frameworks and Component libraries.

The question is simple, how you decide which technologies you are selecting. ( Bootstrap, TailwindCSS, MaterialUI, ChakraUI, Storybook etc...)

Let's discuss it on comments. The points you should mention:

Size of project
Technology requirements for project
Time-efficiency curve
Knowledge
Your rating
Number of people involved

Maybe we can generate a equation to select the most-suitable technology for our future projects

Desktop first vs Mobile First Design - How to decide ?

Ekim Cem Ülger — Mon, 23 May 2022 19:21:40 +0000

Since I do not want a fight over this question, I wanted to state from the beginning, I think we all agree that it should be decided according to different product requirements.(?)

However, in such discussions, we need to consider those who use the product rather than the developers. I always take a look at the data outputs while making such decisions.

Regarding to perficient.com, at 2020, based on 30.02 trillion visits, 68% of users were browsing from their mobile phones but less than half the average time they spend per visit, according to desktop users.

This may because of several reasons, one is most of desktop users are more likely to spend time on their computers of course. On the other hand, we should also consider that most of websites are not REALLY optimized for mobile users so, this may cause users not to prefer to browse the site anymore.

It is always necessary to speed up and optimize any user experience;

In 1979, Walter J. Doherty (IBM Researcher) mentioned that

user experience turns from painful to addictive after the system feedback time drops below 400ms.”
and they call it Doherty Threshold.

We are not here to understand whether its true or not, the thing is response time has a large amount of importance while we use “computer”.

My personal idea is to start with mobile design, and be minimalist.

I did not arrive at this conclusion solely for the reasons I have stated here. I always take note of the applications whose UI designs I like on websites, mobile applications and desktop applications. What they all have in common is that they are extremely simple and useful.

First of all, we shouldn't consider the question of usability about which design we should base on because you can create a lousy user experience no matter which one you start with.

But minimal animation also brings maximum response time, and if you start with mobile design, you inadvertently fit those requirements just a little bit more.

In addition, you can present the contents that you fit on small screens (if you can) to the user in a more comfortable way as the screen expands.

I'm not a UI designer, but I see a lot of designers give priority to mobile design these days.

In fact, you can come across this while browsing websites where you can buy many templates, most of them put mobile application images at the beginning.

It is of course debatable whether this decision is due to the fact that the demand is mostly in mobile designs or that the designers can express themselves better in mobile design.

Which one you go first?

How to hide something on different screen sizes with Bootstrap?

Ekim Cem Ülger — Tue, 02 Nov 2021 17:15:37 +0000

Let's look at the display features with bootstrap, which is the most popular one of the frameworks when the subject is responsive web design.

In order to understand the architecture of the display options of bootstrap, let’s check breakpoints.

Breakpoints are the exact width pixel values that decide the screen size of the browser.

Table 1: Dimensions regarding the screen size.
Bootstrap Source Link

You can check the breakpoints in the table above. Those dimensions mean that if you are under 576px it means that your screen size is x-small, if your width pixel is higher than 576px it means that your screen size is small (until you reach 769 px), and it continues like this.

Since Bootstrap developers used min-width property of CSS while adding those breakpoints, if you only apply a display property to a small screen, it works on both small and larger screens rather than working only on small screens.
Bootstrap min-width

This means that; if you add d-lg-flex to a class, flexbox property will be applied to lg, xl, and xxl screen sizes.

In Bootstrap there is a display property called none.
If you add a class named d-none to your element it will not show it.

So if you want to hide something only on small devices, we need to assign two display classes to the HTML element.

For example, you want to use a flex display property on the container:

<div class= container d-flex> … </div>

This d-flex property will affect the all kind of screen sizes since it has no screen class infix (check Table-1). It means that you are applying that property to x-small and larger screens.

What if we want to hide something in x-small and small screens?

So now, we want to “hide” the container unless it is a medium or larger screen.

<div class= container d-none d-md-flex> … <div>

In this case, d-md-flex property will override the d-none property after screen size reaches 769px ( which is breakpoint of medium screen)

What if we want to display something on small screens but not on large screens?

In this situation, unless it is a medium screen, we want to show it as flex. If it is a medium or larger screen, we want it to be hidden.

<div class= container d-flex d-md-none> … <div>

In the code above, you may see that d-flex property will be applied to whole screen types unless it reaches the medium screen. Since d-md-none affect medium or larger screens, you will be able to hide container for those screens.

If you want to apply different display properties for every different screen sizes, it means that you need to add display properties individually with all breakpoint class infixes.

Ekim