How do I use QoutaMCP?

1. Click on "Install 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., "@QoutaMCP analyze the project structure in /home/user/myapp" 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.

QoutaMCP

by QoutaID

Overview Schema Related Servers Score Discussions

JavaScript

Local

Detects Actix framework usage in Rust projects through project structure inspection and dependency analysis.

Detects Composer package manager usage in PHP projects by analyzing composer.json files and dependencies.

Detects Django framework usage in Python projects through project structure inspection and dependency analysis.

Identifies .env configuration files in projects for environment variable management.

Detects Express framework usage in Node.js projects through project structure inspection and dependency analysis.

Detects FastAPI framework usage in Python projects through project structure inspection and dependency analysis.

Detects Flask framework usage in Python projects through project structure inspection and dependency analysis.

Detects Gin framework usage in Go projects through project structure inspection and dependency analysis.

Detects Gradle build tool usage in Java projects by analyzing build.gradle files.

Detects Laravel framework usage in PHP projects through project structure inspection and dependency analysis.

Detects NestJS framework usage in Node.js/TypeScript projects through project structure inspection and dependency analysis.

Detects Next.js framework usage in Node.js/TypeScript projects through project structure inspection and dependency analysis.

Detects Node.js runtime and analyzes package.json files for project configuration and dependencies.

Detects PHP language usage and analyzes composer.json files for project configuration.

Detects PostgreSQL database hints and usage in project configurations and dependencies.

Detects Pytest testing framework usage in Python projects through dependency analysis.

Detects Python language usage and analyzes requirements.txt and pyproject.toml files for project configuration and dependencies.

Detects React framework usage in Node.js/TypeScript projects through project structure inspection and dependency analysis.

Detects Rocket framework usage in Rust projects through project structure inspection and dependency analysis.

Detects Rust language usage and analyzes Cargo.toml files for project configuration and dependencies.

Detects Spring Boot framework usage in Java projects through project structure inspection and dependency analysis.

Detects Streamlit framework usage in Python projects through project structure inspection and dependency analysis.

Detects Symfony framework usage in PHP projects through project structure inspection and dependency analysis.

Analyzes TOML configuration files including pyproject.toml and Cargo.toml in projects.

Detects Vite build tool usage in Node.js/TypeScript projects through project structure inspection and dependency analysis.

QoutaMCP

MCP server for inspecting and analyzing project structures. Detects languages, frameworks, entry points, and dependencies.

🌐 Live API: https://mcp.qouta.id

Installation

Via NPX (Recommended)

npx qoutamcp

Via NPM

npm install -g qoutamcp
qoutamcp

Manual

git clone https://github.com/QoutaID/qoutaMcp.git
cd qoutaMcp
npm install
npm start

Related MCP server: Smart Code Reviewer

MCP Client Configuration

Method 1: Local (via NPX) - Full Filesystem Access

{
  "mcpServers": {
    "qoutaMcp": {
      "command": "npx",
      "args": ["-y", "qoutamcp"]
    }
  }
}

Method 2: Local (Manual Install)

{
  "mcpServers": {
    "qoutaMcp": {
      "command": "node",
      "args": ["C:/path/to/qoutaMcp/index.js"]
    }
  }
}

Method 3: Remote (via SSE) - Cloud Hosted

{
  "mcpServers": {
    "qoutaMcp": {
      "type": "sse",
      "url": "https://mcp.qouta.id/sse"
    }
  }
}

⚠️ Note: Remote mode has limited filesystem access (serverless). For full project inspection, use local mode.

Remote API Usage

Health Check

curl https://mcp.qouta.id/

Call Tools via REST API

# Detect Stack
curl -X POST https://mcp.qouta.id/ \
  -H "Content-Type: application/json" \
  -d '{"tool": "detect_stack", "params": {"path": "/tmp/myproject"}}'

# Inspect Project
curl -X POST https://mcp.qouta.id/ \
  -H "Content-Type: application/json" \
  -d '{"tool": "inspect_project", "params": {"path": "/tmp/myproject", "maxDepth": 3}}'

# List Key Files
curl -X POST https://mcp.qouta.id/ \
  -H "Content-Type: application/json" \
  -d '{"tool": "list_key_files", "params": {"path": "/tmp/myproject"}}'

Available Tools

1. `inspect_project`

Complete project snapshot - the primary tool for understanding a project.

Input:

{
  "path": "/path/to/project",
  "maxDepth": 3,
  "includeHidden": false
}

Output:

{
  "project": {
    "language": ["Node.js", "Python"],
    "type": "Web API",
    "confidence": 0.92
  },
  "frameworks": [
    { "name": "FastAPI", "confidence": 0.95 }
  ],
  "entryPoints": ["main.py"],
  "structureSummary": {
    "app": ["routes", "models"],
    "config": ["settings.py"]
  },
  "dependencies": {
    "primary": ["fastapi", "uvicorn"],
    "dev": ["pytest"]
  },
  "configFiles": [".env.example", "pyproject.toml"]
}

2. `detect_stack`

Lightweight and fast stack detection.

Input:

{
  "path": "/path/to/project"
}

Output:

{
  "runtime": ["Python"],
  "framework": ["FastAPI"],
  "databaseHints": ["PostgreSQL"],
  "frontend": null
}

3. `list_key_files`

List key files categorized by purpose.

Input:

{
  "path": "/path/to/project"
}

Output:

{
  "entry": ["main.py"],
  "config": ["pyproject.toml", ".env.example"],
  "docs": ["README.md"]
}

Supported Languages

Language	Signature Files	Frameworks Detected
Node.js/TS	`package.json`, `tsconfig.json`	React, Next.js, Express, Vite, NestJS
Python	`requirements.txt`, `pyproject.toml`	Flask, FastAPI, Django, Streamlit
PHP	`composer.json`	Laravel, Symfony
Go	`go.mod`	Gin, Fiber, Echo
Java	`pom.xml`, `build.gradle`	Spring Boot
Rust	`Cargo.toml`	Actix, Rocket, Axum

Error Handling

All errors are returned as JSON:

{
  "error": {
    "code": "PATH_NOT_FOUND",
    "message": "Specified path does not exist"
  }
}

Self-Hosting

Run as HTTP/SSE Server

# Local development
npm run server

# With custom port
PORT=8080 node server.js

Deploy to Railway

Push to GitHub
Connect Railway to your repo
Set start command: node server.js
Deploy!

Deploy to Render

Create new Web Service
Connect to GitHub repo
Build command: npm install
Start command: node server.js

Deploy to Vercel (Serverless)

Already configured! Just connect your GitHub repo to Vercel.

License

ISC

Available Tools

3 tools

detect_stackDetect StackA

Quickly detect the technology stack of a project. Faster and lighter than inspect_project, returns runtime, framework, database hints, and frontend info.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the project directory

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 for behavioral disclosure. It mentions performance characteristics ('faster and lighter') and output scope ('returns runtime, framework, database hints, and frontend info'), which adds useful context. However, it doesn't describe error handling, permission requirements, or what happens with invalid paths, leaving some behavioral aspects unclear.

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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides comparative context and output details. No wasted words, front-loaded with the main action.

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's moderate complexity (single parameter, no output schema, no annotations), the description provides good contextual coverage. It explains what the tool does, how it compares to alternatives, and what information it returns. The main gap is lack of output format details, but for a detection tool with no output schema, this is a minor limitation.

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 description coverage is 100% with one parameter clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (path to project directory). The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 specific action ('detect the technology stack'), resource ('project'), and scope ('runtime, framework, database hints, and frontend info'). It explicitly distinguishes from sibling 'inspect_project' by noting it's 'faster and lighter', providing clear differentiation.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool versus alternatives: 'Faster and lighter than inspect_project' directly compares it to a sibling tool. This gives clear context for choosing between detection methods based on speed vs. thoroughness.

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

inspect_projectInspect ProjectA

Analyze a project directory and return a complete snapshot including detected languages, frameworks, entry points, structure summary, and dependencies. This is the primary tool for understanding a project.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path to the project directory to inspect
`maxDepth`	No	Maximum depth to scan (default: 3)
`includeHidden`	No	Include hidden files and directories

TDQS

A3.9/5.0

Behavior3/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 mentions the tool returns a 'complete snapshot' but lacks details on performance (e.g., speed, resource usage), error handling, or output format. It adds some context about the analysis scope but is incomplete for a tool with no annotations.

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 front-loaded with the core purpose and output, using two concise sentences with zero waste. Every word earns its place, making it easy for an AI agent to quickly grasp the tool's role.

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 complexity of analyzing a project directory with no annotations and no output schema, the description is adequate but has clear gaps. It outlines what the tool does but lacks details on behavioral traits, output structure, or limitations, making it minimally viable for agent 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 description coverage is 100%, so the schema fully documents all three parameters. The description does not add any meaning beyond the schema, such as explaining how 'maxDepth' affects the analysis or what 'includeHidden' might reveal. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific action ('Analyze a project directory') and the comprehensive output ('complete snapshot including detected languages, frameworks, entry points, structure summary, and dependencies'), distinguishing it from sibling tools like 'detect_stack' and 'list_key_files' by emphasizing breadth of analysis.

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 provides clear context as 'the primary tool for understanding a project,' implying it should be used for initial comprehensive analysis. However, it does not explicitly state when to use alternatives like 'detect_stack' or 'list_key_files,' nor does it mention exclusions or prerequisites.

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

list_key_filesList Key FilesC

List key files in a project, categorized by purpose: entry points, config files, and documentation.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the project directory

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 carries the full burden of behavioral disclosure. It mentions categorization by purpose, which adds some context, but fails to describe critical behaviors such as output format, error handling, permissions needed, or rate limits. For a tool with no annotations, this is a significant 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, efficient sentence that front-loads the purpose and categorization without any wasted words. It is appropriately sized for the tool's complexity and structure.

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?

Given the lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., list format, categories), error conditions, or behavioral traits, leaving gaps for the agent to infer. This is inadequate for a tool with no structured support.

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 has 100% description coverage, with the 'path' parameter documented as 'Path to the project directory.' The description does not add any meaning beyond this, such as format examples or constraints, so it meets the baseline of 3 where the 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 tool's purpose: 'List key files in a project, categorized by purpose: entry points, config files, and documentation.' It specifies the verb ('List'), resource ('key files'), and scope ('in a project'), but does not explicitly differentiate from sibling tools like 'detect_stack' or 'inspect_project', which prevents a score of 5.

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. It lacks context about prerequisites, exclusions, or comparisons to sibling tools like 'detect_stack' and 'inspect_project', leaving the agent without clear usage direction.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation4/5

The tools have mostly distinct purposes: detect_stack is for quick tech stack detection, inspect_project provides a comprehensive analysis, and list_key_files focuses on categorizing key files. However, there is some overlap between detect_stack and inspect_project, as both involve analyzing project components, which could cause mild confusion about when to use each.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (detect_stack, inspect_project, list_key_files), using snake_case throughout. The verbs (detect, inspect, list) are clear and descriptive, making the naming predictable and easy to understand.

Tool Count4/5

With 3 tools, the count is reasonable for a project analysis server, covering key aspects like tech detection, detailed inspection, and file listing. It is slightly lean but well-scoped, as each tool serves a distinct function without unnecessary bloat, though a few more tools might enhance coverage.

Completeness3/5

The toolset covers analysis and listing functions well, but there are notable gaps for a project management domain. For example, it lacks tools for modifying or updating projects (e.g., add_dependency, update_config), which could limit agent workflows. The surface is functional for inspection but incomplete for broader project operations.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

SBOMApp - SBOM Generator & Vulnerability Scanner
io.github.mcpsbom
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Developer Tools Security Testing & QA Tools
2
GitLumen MCP A
io.github.gitlumen-team
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Version Control Code Analysis
52
coderegistry A
io.github.hellosg
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
Code Analysis Developer Tools Security
2321
ArchGraph
dev.archgraph
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code Analysis Software Architecture Developer Tools
2

Related MCP Servers

DependencyMCP Server
Code Analysis Developer Tools Code Execution
mkearl
A
license
A
quality
D
maintenance
Analyzes codebases to generate dependency graphs and architectural insights across multiple programming languages, helping developers understand code structure and validate against architectural rules.
Updated 2 years ago (2024-12-14 09:42 UTC)
6
60
20
MIT
Smart Code Reviewer
Code Analysis Developer Tools
renjismzy
A
license
A
quality
D
maintenance
Enables comprehensive code analysis including quality assessment, security vulnerability detection, refactoring suggestions, complexity calculations, and automatic documentation generation for multiple programming languages.
Updated a year ago (2025-08-14 02:42 UTC)
5
10
MIT
Code Expert MCP Server
Code Analysis Version Control Developer Tools
lfnovo
A
license
A
quality
D
maintenance
Analyzes codebases from local directories, GitHub, and Azure DevOps, providing intelligent context to AI coding assistants through repository structure, critical files, and semantic maps.
Updated a year ago (2025-10-13 14:45 UTC)
14
4
MIT
mcp-zen-of-languages
Code Analysis Developer Tools
Anselmoo
A
license
A
quality
A
maintenance
Enables AI assistants and developers to analyze code for language-specific best practices and idiomatic patterns across programming languages, CI automation, and configuration formats.
Updated 9 hours ago (2026-09-02 21:28 UTC)
16
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/QoutaID/qoutaMcp'

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

QoutaMCP

Installation

Via NPX (Recommended)

Via NPM

Manual

MCP Client Configuration

Method 1: Local (via NPX) - Full Filesystem Access

Method 2: Local (Manual Install)

Method 3: Remote (via SSE) - Cloud Hosted

Remote API Usage

Health Check

Call Tools via REST API

Available Tools

1. inspect_project

2. detect_stack

3. list_key_files

Supported Languages

Error Handling

Self-Hosting

Run as HTTP/SSE Server

Deploy to Railway

Deploy to Render

Deploy to Vercel (Serverless)

Links

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `inspect_project`

2. `detect_stack`

3. `list_key_files`