Which integrations are available for this server?

Fetches and analyzes Swiggy order history, providing tools to retrieve orders, restaurants, and comprehensive analytics on spending and food habits.

How do I use Swiggy AI Insights MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Swiggy AI Insights MCP Server Analyze my food ordering patterns and suggest optimizations" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Swiggy AI Insights MCP Server

by imachiever

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

🚀 Swiggy AI Insights - Your Personal Food Intelligence Engine

Transform your Swiggy order history into powerful AI-driven insights!

Turn years of food ordering data into intelligent recommendations, spending insights, and habit analysis using Claude AI. This blazing-fast MCP server gives your AI assistant superpowers to understand your food preferences like never before.

Node.js License Version AI-Powered

🎯 Why This Project Will Change How You Think About Food

💡 Imagine Asking Your AI:

"I want to eat healthy this week - what should I avoid based on my past orders?"
"When do I spend the most on food and how can I optimize my budget?"
"What's my food personality? Am I a weekend splurger or a consistent orderer?"
"Which restaurants give me the best value for money?"
"Show me my food habits during stressful work periods"
"Plan my next month's food budget based on my historical data"

🎪 Real-World Magic in Action:

You: "Analyze my food ordering patterns and suggest optimizations"

Claude: "I'll help you analyze your Swiggy data! I need your session cookies 
        to fetch your order history. Can you provide them?"

You: [Provides cookies - they're used once and never stored]

Claude: "Based on your 247 orders over 18 months, I notice:
🍕 You spend 40% more on weekends (₹890 vs ₹635)
⏰ Your highest-value orders happen at 9 PM (stress eating?)
🥗 You haven't ordered healthy food in 3 weeks
💰 Switching from Pizza Hut to local pizzerias could save ₹2,400/year
📈 Your spending increased 23% during work deadlines

Recommendations:
- Set weekend spending alerts
- Try meal prep Sundays 
- Bookmark 3 healthy options for late-night cravings"

🔒 Your cookies were used once and discarded - maximum security!

Related MCP server: strava-mcp

🌟 What Makes This Special

🧠 AI-Native Intelligence

🤖 Claude Integration: Native MCP protocol for seamless AI conversations
💬 Natural Language: Ask complex questions in plain English
🔮 Predictive Insights: AI-powered recommendations and trend analysis
📊 Smart Visualizations: Auto-generated insights that tell a story

⚡ Blazing Performance

🚀 60% Faster: Optimized JSON storage beats traditional databases
📈 Memory Indexing: Instant queries on years of order history
🔄 Smart Caching: Millisecond response times for complex analytics
📊 Real-time Processing: Live insights as you ask questions

🎯 Unique Analytics (What others don't offer)

🧬 Food DNA Analysis: Deep personality profiling from order patterns
💸 Hidden Money Insights: Discover spending leaks and optimization opportunities
😴 Habit Psychology: Understand emotional triggers behind food choices
⚖️ Health Intelligence: Identify nutrition gaps and wellness patterns
🎭 Social Patterns: Weekend vs weekday personality shifts

🔧 Developer Experience

⚡ 5-Minute Setup: One command gets you running
🧩 Modular Design: Clean, extensible architecture
🔒 Privacy-First: Your data never leaves your machine
📱 Multi-Platform: Works everywhere Node.js runs

🎯 Game-Changing Use Cases

🏠 For Personal Wellness

💰 Budget Optimizer: "I spent ₹8,400 on food delivery last month - show me where I can cut costs without sacrificing happiness"
🏃‍♂️ Health Coach: "My fitness trainer says I need more protein - what are my healthiest past orders I can reorder?"
😰 Stress Pattern Detector: "Do I stress-eat? Show me correlation between my work calendar and high-calorie orders"

💼 For Productivity Hackers

⏰ Time Optimizer: "Which restaurants deliver fastest during my focus hours?"
🧠 Performance Tracking: "Do I perform better at work after certain types of meals?"
📅 Meal Planning: "Plan my next month's meals based on what I actually enjoyed, not what I think I like"

👨‍👩‍👧‍👦 For Families & Students

👶 Parent Mode: "Kid-friendly restaurants that also have healthy options for adults"
💸 Student Budget: "Stretch my ₹3000 food budget for maximum satisfaction based on past data"
🎉 Social Planning: "Which restaurants work best when I'm ordering for groups?"

📊 For Data Nerds

📈 Trend Analysis: "Visualize my evolving food preferences over the past 2 years"
🔍 Deep Dives: "What external factors influence my ordering? Weather? Mood? Events?"
💡 Insight Mining: "Find patterns I never noticed in my food behavior"

📦 Quick Start

Prerequisites

# Ensure you have Node.js 18+ installed
node --version  # Should be 18.0.0 or higher

Installation

Option 1: Global Installation (Recommended)

# Install globally with npm
npm install -g swiggy-ai-insights

# Run from anywhere
swiggy-mcp

# Or clone and install globally from source
git clone https://github.com/YOUR_USERNAME/swiggy-ai-insights.git
cd swiggy-ai-insights
npm install -g .

Option 2: Local Installation

# Clone the repository
git clone https://github.com/YOUR_USERNAME/swiggy-ai-insights.git
cd swiggy-ai-insights

# Run the automated setup
npm run setup

# Start the server (no config needed!)
npm start

🔒 Security Note: Unlike other tools, this project never stores your cookies. You provide them securely at runtime when needed.

Quick Usage

# With global installation - super simple!
swiggy-mcp

# The server starts immediately and provides 5 MCP tools:
# 1. sync_orders - Fetch orders from Swiggy API
# 2. get_orders - Retrieve orders with filtering
# 3. get_restaurants - List restaurants with stats
# 4. get_analytics - Comprehensive analytics
# 5. search_orders - Search across orders

MCP Integration with Cursor AI

With Global Installation

# Start the MCP server (from anywhere)
swiggy-mcp

# Add to your Cursor AI MCP settings:
{
  "mcpServers": {
    "swiggy-ai-insights": {
      "command": "swiggy-mcp",
      "env": { "NODE_ENV": "production" }
    }
  }
}

With Local Installation

# Start the MCP server
npm run mcp

# Add to your Cursor AI MCP settings:
{
  "mcpServers": {
    "swiggy-ai-insights": {
      "command": "node",
      "args": ["/path/to/swiggy-ai-insights/simple-index.js"],
      "env": { "NODE_ENV": "production" }
    }
  }
}

🏗️ Project Structure

swiggy-ai-insights/
├── simple-index.js               # Main entry point for simplified MCP server
├── src/                          # Core source code
│   ├── simple-mcp.js             # Main MCP server implementation
│   ├── simple-data-manager.js    # Simplified data management
│   ├── persistent-manager.js     # Intelligent data storage
│   ├── swiggy-fetcher.js         # Swiggy API client with smart caching
│   └── config.js                 # Configuration management
├── config/                       # Configuration files
│   ├── default.json              # Default configuration
│   └── cursor-mcp.json          # MCP integration template
├── test/                         # Tests and examples
│   ├── performance.js           # Performance testing suite
│   └── client-example.js        # Usage examples & analysis
├── scripts/                      # Utility scripts
│   ├── setup.sh                # Automated setup
│   └── start.sh                 # Server startup
├── data/                        # Data storage directory
├── docs/                        # Documentation
├── package.json                 # Dependencies and scripts
├── index.js                     # Main entry point
└── README.md                    # This file

🔒 How It Works (Security-First Approach)

No Configuration Required!

Unlike other tools that store sensitive cookies in config files, this project follows a security-first approach:

✅ No cookies stored: Your session cookies are never saved to disk
✅ Runtime-only: Provide cookies securely when Claude needs them
✅ Zero risk: No accidental commits of sensitive data

Getting Your Swiggy Session Cookies (when Claude asks)

Login to Swiggy in your browser
Navigate to orders: https://www.swiggy.com/my-account/orders
Open Developer Tools (F12 → Network tab)
Refresh the page and find any request to swiggy.com
Copy the Cookie header value
Paste when Claude prompts you - that's it!

Server Configuration

{
  "server": {
    "host": "0.0.0.0",
    "port": 8001,
    "cors_enabled": true
  },
  "storage": {
    "data_file": "data/swiggy_orders_optimized.json"
  }
}

📡 API Reference

REST API Endpoints

`POST /fetch_orders`

Fetch and analyze orders with intelligent caching.

// Request
{
  "cookies": "your_session_cookies",
  "days_back": 30,              // Optional: number of days
  "start_date": "2025-01-01",   // Optional: specific start date
  "end_date": "2025-01-31",     // Optional: specific end date
  "force_refresh": false        // Optional: bypass cache
}

// Response
{
  "success": true,
  "total_orders": 45,
  "performance_ms": 12.3,
  "source": "persistent_file",
  "data": {
    "orders": [...],
    "summary": {
      "total_spent": 2450.75,
      "average_order_value": 54.46,
      "top_restaurants": [["Pizza Hut", 8]],
      "top_cuisines": [["Italian", 12]]
    }
  }
}

`GET /health`

Server health check with detailed metrics.

`GET /stats`

Storage statistics and server information.

`GET /export`

Export all stored data.

MCP Tools

`fetch_swiggy_orders`

Fetch and analyze Swiggy orders with intelligent caching
Parameters: cookies (required), days_back, start_date, end_date, force_refresh

`analyze_food_habits`

Comprehensive food habit analysis with insights
Parameters: cookies (required), days_back, force_refresh

`get_swiggy_stats`

Get storage statistics and server information
Parameters: none

`export_swiggy_data`

Export all stored order data
Parameters: include_orders (optional)

🚀 Usage Examples

Basic REST API Usage

import axios from 'axios';

// Fetch last 30 days of orders
const response = await axios.post('http://localhost:8001/fetch_orders', {
  cookies: 'your_cookies_here',
  days_back: 30
});

console.log(`Found ${response.data.total_orders} orders`);
console.log(`Total spent: ₹${response.data.data.summary.total_spent}`);

Comprehensive Analysis

# Run detailed food habits analysis
npm run client

# Run performance tests
npm run test

# Analyze specific time period
node test/client-example.js 90 --refresh

🤖 AI Conversations That Will Blow Your Mind

Once installed, have natural conversations with Claude:

Financial Intelligence:

"I want to save ₹2000 on food this month without feeling deprived" → Claude: "I'll need your Swiggy cookies to analyze your orders first..."
"Show me my most expensive food mistakes and how to avoid them"

Health & Wellness:

"Rate my food choices this week and suggest healthier alternatives I'd actually enjoy"
"I'm trying to lose weight - what ordering patterns should I change?"

Behavioral Insights:

"Do I order differently when I'm stressed vs happy?"
"What does my food data say about my lifestyle and personality?"

Smart Planning:

"Plan a week of meals that match my taste preferences and budget"
"Which restaurants should I try next based on my flavor profile?"

🔒 Security in Action: Claude will prompt you for cookies when needed - no setup required!

🏆 Why Choose This Over Alternatives?

🆚 vs. Manual Order History Checking

Feature	Manual Way	Swiggy AI Insights
Time to Insights	Hours	Seconds
Pattern Discovery	What you remember	AI finds hidden patterns
Budget Analysis	Basic math	Deep financial intelligence
Recommendations	Guesswork	Data-driven suggestions
Trend Analysis	Impossible	Automatic with visualizations

🆚 vs. Other Food Analytics Tools

🧠 AI-Native: Built specifically for conversational AI, not dashboards
🔒 Security-First: Never stores cookies (others require config files with credentials)
🛡️ Zero-Config Privacy: No sensitive data in files to accidentally leak
⚡ Performance: 60% faster than database-driven solutions
🎯 Swiggy-Optimized: Deep understanding of Indian food delivery patterns
🆓 Open Source: Transparent, customizable, community-driven

🎯 Unique Value Propositions:

🔒 Revolutionary Security: Never stores cookies (runtime-only approach others can't match)
🧬 Food Personality Profiling: No other tool analyzes your food psychology
💸 Hidden Money Patterns: Discover spending leaks others miss
🤖 Conversational Intelligence: Ask questions like talking to a food expert
📊 Predictive Analytics: Anticipate your needs before you know them
🌟 Actionable Insights: Not just data - specific steps to improve

🧪 Testing

Performance Testing

npm run test
# Tests: health, stats, fetch orders, concurrent requests
# Reports: response times, performance metrics, recommendations

Manual Testing

# Health check
curl http://localhost:8001/health

# Get statistics
curl http://localhost:8001/stats

# Test order fetching (replace with your cookies)
curl -X POST http://localhost:8001/fetch_orders \
  -H "Content-Type: application/json" \
  -d '{"cookies":"your_cookies", "days_back":7}'

📊 Performance

Typical Response Times

Health check: 5-10ms
Stats endpoint: 10-20ms
Small dataset (< 100 orders): 15-30ms
Medium dataset (100-500 orders): 25-50ms
Large dataset (500+ orders): 40-100ms

Optimization Features

In-memory indexing for instant date lookups
Smart file monitoring to avoid unnecessary I/O
Efficient JSON structure with pre-built date indexes
Request throttling to respect Swiggy API limits
Concurrent request handling with Express.js

🛠️ Development

Available Scripts

npm start          # Start REST API server
npm run mcp        # Start MCP server for Cursor AI
npm run dev        # Development mode with auto-restart
npm run test       # Run performance tests
npm run client     # Run food habits analysis
npm run setup      # Automated setup and configuration
npm run clean      # Clean data and log files

Development Mode

# Start with auto-restart on file changes
npm run dev

# Enable debug logging
NODE_ENV=development npm start

Project Scripts

# Setup new environment
./scripts/setup.sh

# Start server with options
./scripts/start.sh 8001 server  # REST API on port 8001
./scripts/start.sh 8001 mcp     # MCP mode
./scripts/start.sh 8001 dev     # Development mode

🔒 Security & Privacy

🔒 Superior Security Design

Never stores cookies: Unlike other tools, cookies are provided at runtime only
Zero configuration risk: No sensitive data in config files to accidentally commit
Your data stays local: All order data is stored locally on your machine
Git-safe by design: Impossible to leak credentials through version control
No data sharing: This tool never sends your data anywhere except to fetch from Swiggy

Runtime-only: Provide fresh cookies when Claude asks (most secure approach)
No persistence: Cookies are never written to disk or config files
Rotate freely: Get fresh cookies anytime by re-logging into Swiggy
Zero accident risk: No config files with sensitive data to accidentally share

Production Deployment

# Set production environment
export NODE_ENV=production

# Use PM2 for process management
npm install -g pm2
pm2 start index.js --name swiggy-mcp-server

# Setup reverse proxy with nginx
# Configure SSL/HTTPS for external access

🚨 Troubleshooting

Common Issues

Server Won't Start

# Check Node.js version
node --version  # Should be 18+

# Install dependencies
npm install

# Check port availability
lsof -ti:8001 | xargs kill

Authentication Errors

Update cookies in config/default.json
Re-login to Swiggy and get fresh cookies
Verify cookie format is correct (long string with multiple key=value pairs)

Performance Issues

# Check data file size
ls -lh data/*.json

# Monitor memory usage
node --max-old-space-size=4096 index.js

# Enable debug mode
NODE_ENV=development npm start

MCP Connection Issues

Verify server is running: curl http://localhost:8001/health
Check MCP config path is absolute
Restart Cursor AI after config changes

Debug Mode

# Enable detailed logging
NODE_ENV=development npm start

# Run specific tests
node test/performance.js
node test/client-example.js 30 --refresh

🤝 Contributing

Development Setup

# Fork and clone the repository
git clone https://github.com/YOUR_USERNAME/swiggy-ai-insights.git
cd swiggy-ai-insights

# Install dependencies
npm install

# Make your changes
# Add tests if applicable

# Test your changes
npm run test
npm run client

# Submit a pull request

Code Style

Use ES6+ features and async/await
Follow modular architecture patterns
Add JSDoc comments for functions
Write descriptive commit messages

📈 Roadmap

Upcoming Features

Real-time Notifications: WebSocket support for live order updates
Advanced ML Analytics: Predictive ordering patterns
Multi-user Support: Separate data storage per user
Mobile App Integration: React Native companion app
Data Visualization: Chart generation endpoints
Export Formats: CSV, Excel, PDF export options

Performance Improvements

Data Compression: Gzip compression for large datasets
Database Integration: Optional MongoDB/PostgreSQL support
Caching Layer: Redis integration for high-traffic scenarios
Rate Limiting: Advanced API rate limiting

📝 Changelog

v2.0.0 (Current)

✨ Complete rewrite in Node.js with modular architecture
⚡ Significant performance improvements (~60% faster)
🧩 Separated concerns into modular components
🔗 Enhanced MCP protocol compliance
📊 Advanced analytics and insights
🧪 Comprehensive testing suite
📚 Improved documentation

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Swiggy for providing the order data API
Model Context Protocol team for the excellent MCP SDK
Node.js Community for the amazing ecosystem
Contributors who help improve this project

📞 Support

Issues: GitHub Issues
Documentation: This README and inline code comments
Community: Feel free to fork and contribute!

🎉 Happy Food Data Analysis!

Built with ❤️ using Node.js and the power of food analytics

Built for the food lovers and data enthusiasts 🍕📊

Available Tools

5 tools

get_analyticsC

Get comprehensive analytics from persistent storage

ParametersJSON Schema

Name	Required	Description	Default
`end_date`	No	End date YYYY-MM-DD (optional)
`start_date`	No	Start date YYYY-MM-DD (optional)
`analysis_type`	No	Analysis type: summary, spending, timing, restaurants, cuisines	summary

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read, but does not mention potential side effects, performance implications, required permissions, or what 'persistent storage' implies. The description adds no meaningful behavioral context.

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

Conciseness2/5

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

The one-sentence description is short but contains filler phrases like 'comprehensive' and 'from persistent storage' that add no value. It lacks structured, front-loaded information that would help an agent quickly grasp key details.

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

Completeness2/5

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

The tool has no annotations or output schema, and the description is minimal. It fails to explain how date ranges work, what the returned analytics represent, or how analysis_type changes the result. This simple tool still requires more context for safe and effective use.

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%, so the baseline is 3. All three parameters (start_date, end_date, analysis_type) are described in the schema, including defaults. The description adds no parameter-specific meaning beyond what the schema already provides.

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

Purpose3/5

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

The description clearly uses the verb 'Get' and identifies 'analytics' as the resource, but 'comprehensive' is vague and does not specify what metrics or analysis types are included. It also does not differentiate the tool from siblings like get_orders or get_restaurants, which also fetch data.

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 provided on when to choose this tool over alternatives. There is no mention of prerequisites, alternative tools, or exclusions. The agent must infer that this tool is meant for aggregated analytics rather than raw data.

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

get_ordersC

Get orders from persistent storage with optional filtering

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max orders to return (default: 50)
`end_date`	No	End date YYYY-MM-DD (optional)
`start_date`	No	Start date YYYY-MM-DD (optional)
`restaurant_name`	No	Filter by restaurant name (optional)

TDQS

C2.9/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 burden of behavioral disclosure. It only says 'Get orders', implying a read operation, but does not disclose whether it is read-only, how results are ordered, whether pagination applies, or any other behavioral traits. This is minimal beyond the tool name.

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 sentence that is concise and front-loaded with the action 'Get' and the resource 'orders'. It contains no redundancy or filler words, making it highly efficient while still conveying the core purpose.

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

Completeness2/5

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

This is a relatively simple list tool but the description is insufficient for full contextual completeness. There is no output schema, and the description does not mention return format, ordering, pagination, or the impact of date filters. It lacks the behavioral context that would help an agent understand the full scope of the operation.

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 schema description coverage is 100%, with all 4 parameters (limit, end_date, start_date, restaurant_name) individually documented. The description's mention of 'optional filtering' adds only a generic context and no specific parameter semantics, so the baseline score of 3 is appropriate given the schema already covers parameter meaning.

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 verb 'Get' and resource 'orders', and adds context with 'from persistent storage' and 'optional filtering'. However, it does not distinguish this tool from the sibling 'search_orders', which may also retrieve orders, so it lacks sibling differentiation.

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?

The description provides no guidance on when to use this tool versus alternatives like 'search_orders' or 'sync_orders'. There is no mention of prerequisites, common use cases, or exclusions, leaving the agent without direction for selecting this tool.

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

get_restaurantsB

Get all restaurants with order counts and spending stats

ParametersJSON Schema

Name	Required	Description
`end_date`	No	End date YYYY-MM-DD (optional)
`min_orders`	No	Min orders to include restaurant (default: 1)
`start_date`	No	Start date YYYY-MM-DD (optional)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does but gives no details about pagination, ordering, rate limits, authentication, or side effects. This is a significant gap for a data retrieval tool.

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 front-loads the main action and resource. Every word earns its place, with no filler or redundancy.

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 the tool has three optional parameters and no output schema, the description provides a basic sense of what it returns ('order counts and spending stats') but lacks details on return structure, filtering behavior, or how the parameters affect results. It is adequate but not comprehensive.

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 input schema already provides clear descriptions for all three parameters (start_date, end_date, min_orders) with 100% coverage, so the baseline is 3. The tool description does not add any additional semantic meaning beyond what the schema already states.

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 uses a specific verb ('Get') and resource ('restaurants') and states the data returned ('order counts and spending stats'). This clearly identifies the tool's purpose, but it does not explicitly distinguish it from sibling tools like get_orders or get_analytics beyond the resource name.

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 the tool is for retrieving restaurant-level aggregate data, but it does not explicitly state when to use this tool versus alternatives, nor any exclusions or prerequisites. Usage context is inferred from the resource and data mentioned.

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

search_ordersA

Search orders by restaurant name, cuisine, or location

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (default: 20)
`query`	Yes	Search query (restaurant/cuisine/location)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the search action and criteria but does not mention whether the operation is read-only, if there are any side effects, how results are sorted, or whether pagination is applied. This lack of behavioral context is a significant gap for a tool with no annotation support.

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 sentence that front-loads the verb and resource, and clearly communicates the searchable fields. There is no waste or redundancy—every word 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 the tool's simplicity and the schema's thorough parameter documentation, the description provides an adequate high-level overview. However, there is no output schema, so the description should explain what the search returns (e.g., a list of orders) and any limitations (e.g., default max results). It mentions neither, leaving some ambiguity for the agent.

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 input schema already has 100% coverage, describing both the 'query' parameter (with the same restaurant/cuisine/location hint) and 'limit'. The description adds little beyond restating the schema's own description, so it does not elevate the baseline of 3.

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 tool's action ('Search orders') and defines the scope by specifying search criteria: restaurant name, cuisine, or location. This differentiates it from sibling tools like get_orders (likely fetching by ID) and sync_orders (synchronization).

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: it is a search tool with specific filters, but it does not explicitly state when to prefer it over alternatives or provide exclusions (e.g., 'use get_orders for exact ID lookups'). The context is clear enough for an agent to infer its purpose, but no direct guidance is given.

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

sync_ordersB

Sync orders from Swiggy API to persistent storage

ParametersJSON Schema

Name	Required	Description	Default
`cookies`	Yes	Swiggy session cookies (required)
`max_orders`	No	Maximum orders to fetch (default: 1000)

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention side effects such as whether existing data is overwritten, whether the sync is incremental or full, where the persistent storage is located, or any authentication/rate-limit considerations. For a mutating operation, this is a notable gap.

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, front-loaded sentence with no filler. It effectively communicates the core purpose and leaves space for schema to handle parameter details.

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

Completeness2/5

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

The tool is a side-effecting sync operation with no output schema, and the description provides no context on sync semantics, storage destination, or idempotency. Given the lack of annotations, the description is too shallow to fully prepare an agent for invocation.

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 input schema already provides complete descriptions for both parameters (cookies required, max_orders with default). The description adds no additional parameter semantics beyond the schema, so the baseline of 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 action ('Sync orders'), the resource ('orders'), the source ('Swiggy API'), and the destination ('persistent storage'). It distinguishes itself from sibling tools like get_orders and search_orders, which are read-only operations.

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 via the word 'sync' – indicating persistence – and contrasts with read-only siblings, but does not explicitly state when to choose this tool over get_orders or search_orders. It lacks clear when-to-use / when-not-to-use guidance.

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.

5 tool updatesv2.0.0Aug 13, 2026
- First observedget_analytics
- First observedget_orders
- First observedget_restaurants
- First observedsearch_orders
- First observedsync_orders

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored 2026-08-13 22:35 across 5 tools

Disambiguation4/5

Each tool has a distinct role: ingest, query, restaurant stats, analytics, and text search. The only potential confusion is between get_orders and search_orders, but the descriptions clarify that one is for structured filtering and the other for text-based search.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (sync_orders, get_orders, get_restaurants, get_analytics, search_orders). The verbs are clear and the pattern is predictable.

Tool Count5/5

With 5 tools, the set is well-scoped for the server's purpose of syncing Swiggy data and providing insights. Each tool earns its place without redundancy or unnecessary bloat.

Completeness4/5

The core workflow of syncing orders, querying orders, viewing restaurant stats, and getting analytics is covered. Minor gaps exist such as no explicit restaurant sync or order update/delete, but these are likely intentional for an analytics-focused server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

iFood A
io.github.mcp-dir
Insights for your iFood store right in your AI assistant's chat. Generate charts of sales and payout
E-commerce & Retail Finance Data Visualization
1321
MCP Hub — your personal data for AIOAuth
church.ai.mcp
Your personal data for AI — Telegram, bank, courses, Zoom & more, scoped to you.
Communication Text Summarization App Automation
2
prep-itOAuth
com.recipe-clipper
Search, save, organize, cook, and share recipes with any AI assistant.
Note Taking Search
2
Era ContextOAuth
app.era
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Finance Knowledge & Memory
1

Related MCP Servers

blinkit-mcp
E-commerce & Retail Browser Automation
hereisSwapnil
A
license
A
quality
C
maintenance
Enables Claude to automate grocery shopping on Blinkit, including product search, cart management, location setup, and payment via UPI.
Updated 6 months ago (2026-03-10 17:23 UTC)
14
46
MIT
strava-mcp
Fitness Tracking Health & Wellness
nicolefreeman
A
license
Not graded
quality
D
maintenance
Exposes your Strava data to Claude, enabling training load analysis, activity comparison, and lap splits via conversation.
Updated 6 months ago (2026-03-22 22:45 UTC)
10 npm
MIT
MealOS
E-commerce & Retail App Automation
naga-pavan12
F
license
Not graded
quality
C
maintenance
Enables users to plan meals and place orders across Swiggy Food, Instamart, and Dineout directly from Claude Desktop conversations.
Updated 3 months ago (2026-06-28 16:30 UTC)
-
MacroFactor MCP
Health & Wellness Fitness Tracking
chaotix345
A
license
Not graded
quality
C
maintenance
Enables Claude.ai to read your MacroFactor nutrition data and log food back into MacroFactor.
Updated 2 months ago (2026-07-11 07:19 UTC)
MIT

🚀 Swiggy AI Insights - Your Personal Food Intelligence Engine

🎯 Why This Project Will Change How You Think About Food

💡 Imagine Asking Your AI:

🎪 Real-World Magic in Action:

🌟 What Makes This Special

🧠 AI-Native Intelligence

⚡ Blazing Performance

🎯 Unique Analytics (What others don't offer)

🔧 Developer Experience

🎯 Game-Changing Use Cases

🏠 For Personal Wellness

💼 For Productivity Hackers

👨‍👩‍👧‍👦 For Families & Students

📊 For Data Nerds

📦 Quick Start

Prerequisites

Installation

Option 1: Global Installation (Recommended)

Option 2: Local Installation

Quick Usage

MCP Integration with Cursor AI

With Global Installation

With Local Installation

🏗️ Project Structure

🔒 How It Works (Security-First Approach)

No Configuration Required!

Getting Your Swiggy Session Cookies (when Claude asks)

Server Configuration

📡 API Reference

REST API Endpoints

POST /fetch_orders

GET /health

GET /stats

GET /export

MCP Tools

fetch_swiggy_orders

analyze_food_habits

get_swiggy_stats

export_swiggy_data

🚀 Usage Examples

Basic REST API Usage

Comprehensive Analysis

🤖 AI Conversations That Will Blow Your Mind

🏆 Why Choose This Over Alternatives?

🆚 vs. Manual Order History Checking

🆚 vs. Other Food Analytics Tools

🎯 Unique Value Propositions:

🧪 Testing

Performance Testing

Manual Testing

📊 Performance

Typical Response Times

Optimization Features

🛠️ Development

Available Scripts

Development Mode

Project Scripts

🔒 Security & Privacy

🔒 Superior Security Design

🛡️ Cookie Security

Production Deployment

🚨 Troubleshooting

Common Issues

Server Won't Start

Authentication Errors

Performance Issues

MCP Connection Issues

Debug Mode

🤝 Contributing

Development Setup

Code Style

📈 Roadmap

Upcoming Features

Performance Improvements

📝 Changelog

v2.0.0 (Current)

📄 License

🙏 Acknowledgments

📞 Support

Available Tools

`POST /fetch_orders`

`GET /health`

`GET /stats`

`GET /export`

`fetch_swiggy_orders`

`analyze_food_habits`

`get_swiggy_stats`

`export_swiggy_data`