Skip to main content
Glama
AyushSrivastava0609

DokaAI MCP Service POC

by AyushSrivastava0609
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

DokaAI MCP Service POC

Unified TypeScript service with:

  • local stdio MCP server for Codex / Claude Desktop

  • Vercel-ready HTTP MCP endpoint

  • REST APIs backed by the same in-memory business data

  • Phase 1 production structure for auth, routes, logging, errors, computed metrics, and evals

Setup

npm install
npm run build

Related MCP server: flipkart-seller-mcp

Local MCP

Run the stdio MCP server:

npm start

Codex / Claude Desktop can still use:

{
  "command": "node",
  "args": ["/Users/ayushsrivastava0609/Doka-AI/mcp-server-poc/dist/index.js"]
}

Vercel Deployment

Deploy this folder as the Vercel project root:

/Users/ayushsrivastava0609/Doka-AI/mcp-server-poc

Hosted endpoints:

  • GET /health

  • GET /api/users

  • GET /api/orders

  • GET /api/users/:userId/orders

  • GET /api/users/:userId/business-profile

  • GET /api/business/summary

  • POST /mcp

  • GET /mcp

  • DELETE /mcp

Authentication

For hosted connector authentication, the service exposes a POC OAuth flow:

  • /.well-known/oauth-protected-resource/mcp

  • /.well-known/oauth-authorization-server

  • /oauth/register

  • /oauth/authorize

  • /oauth/token

When ChatGPT or Claude connects to /mcp without a token, the server returns 401 with a WWW-Authenticate header pointing to the OAuth protected-resource metadata. The connector client can then start the OAuth flow.

Set this environment variable in Vercel:

OAUTH_SIGNING_SECRET=your-long-random-signing-secret

During OAuth authorization, the demo page asks for:

DokaAI Username
DokaAI Password

Default mock login:

username: dokaai_demo_user
password: dokaai_demo_password

Override it in Vercel with:

MOCK_DOKAAI_USERNAME=your-demo-username
MOCK_DOKAAI_PASSWORD=your-demo-password

For this POC, a successful login creates a short-lived signed OAuth token. For production, replace this with a real user/session system.

You can also set this legacy static token for private API testing:

MCP_AUTH_TOKEN=your-long-random-token

/health, /api/health, OAuth metadata, and OAuth endpoints stay public. Everything else requires either an OAuth bearer token or:

Authorization: Bearer your-long-random-token

or:

x-api-key: your-long-random-token

Example:

curl https://your-app.vercel.app/api/users \
  -H "Authorization: Bearer your-long-random-token"

MCP Tools

  • get_indian_users: Fetch all Indian test users from the backend API.

  • get_orders: Fetch all business orders.

  • get_user_orders: Fetch orders for one user, such as usr_001.

  • get_user_business_profile: Fetch one user with subscription, orders, invoices, payments, refunds, computed metrics, risk signals, data limitations, and evidence guidance.

  • get_business_summary: Fetch aggregate business metrics, risk counts, summary signals, data limitations, and evidence guidance.

The AI client can handle filtering, lookup, grouping, summaries, and cross-dataset reasoning from the returned data.

For better answer accuracy, important calculations are returned by the backend instead of being left to the model:

daysSinceLastLogin
daysSinceLastOrder
daysUntilRenewal
failedPaymentCount
overdueInvoiceCount
riskOrderCount
financialRisk
engagementRisk
renewalRisk
overallCustomerHealth

Every major MCP response also includes:

evidenceGuide
dataLimitations

Phase 1 Structure

The code is split by responsibility:

src/auth      OAuth-shaped auth and token helpers
src/config    runtime constants
src/http      request/response utilities
src/logging   structured JSON logger
src/mcp       MCP tools, prompts, evidence, server setup
src/routes    hosted MCP and REST route handlers
src/services  mock data, business metrics, data limitations
src/vercel.ts thin deployment entrypoint

See:

docs/phase-1-production.md
docs/evals.md
docs/usability.md

MCP Prompts

Prompts are reusable workflows the client can run.

  • business_summary_report: Guides the AI to produce a simple business report with overview, revenue snapshot, risk signals, patterns, recommended actions, and evidence used.

  • customer_segmentation_report: Guides the AI to analyze users by location, plan, profession, support, and billing signals.

  • orders_analysis_report: Guides the AI to analyze revenue, product categories, payments, fulfillment, sales channel, and order risks.

  • user_orders_report: Guides the AI to analyze orders for one user. Requires userId.

  • customer_health_report: Guides the AI to analyze one customer using profile, subscription, orders, invoices, payments, refunds, and metrics. Requires userId.

Available Tools

5 tools
get_business_summaryGet Business SummaryA

Fetch aggregate business metrics across users, orders, invoices, payments, refunds, and subscriptions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits such as read-only nature or potential performance impact. It only states what data is aggregated, without detailing side effects or access requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence front-loads the verb and resource, with no extra words. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no parameters, the description should elaborate on the shape of the return value (e.g., counts, totals) or pagination. The current description is adequate but lacks sufficient detail for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100% trivial. The description adds value by listing the included entities (users, orders, etc.), which helps the agent understand the scope of the aggregate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Fetch' and a specific resource 'aggregate business metrics' across multiple entities, clearly distinguishing it from sibling tools that target individual entities like users or orders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for high-level overviews but does not specify when to choose this over sibling tools like get_orders or get_user_business_profile, nor does it mention any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_indian_usersGet Indian UsersA

Fetch all Indian test users. Use this for customer segmentation, location analysis, plan analysis, and profile lookup.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It only says 'Fetch' but does not disclose any behavioral aspects like authentication needs, rate limits, or whether it returns a complete list or paginated results. For a simple read-only tool, this is minimally adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence, front-loading the core action and resource, then adding use-case examples. Every word is meaningful with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and no output schema, the description sufficiently covers its purpose and usage context. It could be improved by noting the output format or any limitations, but it is complete enough for a simple list-fetch operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description adds value by specifying 'all Indian test users', confirming the lack of filtering. This aligns with the empty schema and provides clarity beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch') and the specific resource ('all Indian test users'), which immediately distinguishes it from sibling tools like get_orders (orders) or get_user_business_profile (single user profile).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists use cases (customer segmentation, location analysis, plan analysis, profile lookup), providing clear context for when to use this tool. However, it does not explicitly state when not to use it or contrast with alternatives like get_user_orders.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ordersGet OrdersA

Fetch all business orders. Use this for revenue, product category, delivery, payment, and risk analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only states 'Fetch all business orders' without disclosing potential performance impacts, pagination, or data freshness. Lacks behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no redundant words. Front-loaded with action and resource, followed by usage guidance. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple fetch-all tool with no parameters or output schema, but lacks behavioral details (e.g., ordering, limits) that would improve completeness given no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so schema coverage is 100% trivially. Description adds no parameter-specific info but highlights purpose, meeting baseline for no-param tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Fetch' and resource 'all business orders', distinguishing from sibling tools like get_user_orders by scope and use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Lists specific analyses (revenue, product category, etc.) for which this tool is suitable, but does not explicitly state when not to use it or mention alternatives like get_user_orders.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_business_profileGet User Business ProfileA

Fetch one user with their subscription, orders, invoices, payments, refunds, and business metrics.

ParametersJSON Schema
NameRequiredDescriptionDefault
userIdYesUser ID, such as usr_001.

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It uses 'Fetch' suggesting a read-only operation but does not confirm non-destructiveness, error behavior (e.g., if user not found), authentication requirements, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that includes the verb, resource, and a list of included data. Every word earns its place, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description fairly comprehensively lists the data returned (subscription, orders, invoices, etc.). However, it lacks details on pagination, nesting, or whether all data is always present. Still, for a single-user fetch, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'userId' has a description in the schema ('User ID, such as usr_001.'), giving 100% schema coverage. The tool description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetch' and the resource 'one user', listing the included data: subscription, orders, invoices, payments, refunds, and business metrics. It distinguishes from sibling tools like 'get_indian_users' (geographically filtered) and 'get_orders' (orders only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching a full business profile but does not explicitly state when to use it versus siblings (e.g., 'get_business_summary' for a summary). No when-not-to-use or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_ordersGet User OrdersC

Fetch all orders for a single user, such as usr_001.

ParametersJSON Schema
NameRequiredDescriptionDefault
userIdYesUser ID, such as usr_001.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, yet the description only states it fetches orders. It omits behavioral traits such as pagination, ordering, read-only nature, or authentication requirements. This leaves significant gaps for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is efficiently front-loaded, but could include more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one parameter and no output schema, the description is minimally complete. However, missing details like response format or pagination limit its utility. Could be improved with brief behavioral info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (parameter 'userId' described as 'User ID, such as usr_001'). The description adds no extra semantic meaning beyond the schema example. Baseline 3 applies as schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch all orders') and the specific resource ('for a single user'). It distinguishes from sibling tools like 'get_orders' by limiting scope to one user. However, it does not explicitly frame this in contrast to alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when or when not to use this tool. It does not mention alternatives or exclude cases like needing orders for multiple users. The implication is weak and relies on sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv1.0.0
    • First observedget_business_summary
    • First observedget_indian_users
    • First observedget_orders
    • First observedget_user_business_profile
    • First observedget_user_orders
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation4/5

Tools are mostly distinct: one for Indian users, one for all orders, one for user-specific orders, one for full user profile, and one for aggregate summary. Some overlap exists between get_orders and get_user_orders, but names clarify scope. get_user_business_profile includes user info, overlapping with get_indian_users but with different granularity.

Naming Consistency5/5

All tools follow a consistent 'get_<noun>' pattern using snake_case. The nouns are descriptive and the pattern is uniform, making it easy to predict tool behavior from names.

Tool Count5/5

With 5 tools, the server is well-scoped for a proof-of-concept. It covers key data access patterns without unnecessary bloat, balancing coverage and simplicity.

Completeness3/5

The tool set is read-only, missing create/update/delete operations. It lacks a tool to fetch a single order by ID or a simple user lookup without full profile. For a POC, these gaps may be acceptable, but the surface feels incomplete for production use.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • blinkit-mcp

    yniks
    A
    license
    A
    quality
    C
    maintenance
    An API-only MCP server for Blinkit that enables automated shopping on the Indian quick-commerce platform, supporting login, search, cart, checkout, and payment via UPI.
    25
    1
    MIT

  • flipkart-seller-mcp

    ron2111
    A
    license
    A
    quality
    A
    maintenance
    A token-optimized MCP server that enables AI agents to manage Flipkart Seller operations including order fulfillment, inventory, returns, ad campaigns, and financial settlements via the Flipkart v3 API.
    5
    12
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AyushSrivastava0609/dokaai-mcp-server-poc'

If you have feedback or need assistance with the MCP directory API, please join our Discord server