Skip to main content
Glama
OrtakProje-1

Flutter Package MCP Server

by OrtakProje-1
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Flutter Package MCP Server

🚀 Flutter paketleri için Model Context Protocol (MCP) server - Claude ve diğer AI asistanları ile Flutter paket ekosistemini entegre kullanın!

Pub.dev API'si ile entegre çalışarak Flutter paketlerinin güncel bilgilerini, versiyonlarını ve dokümantasyonlarını AI asistanınızın kullanımına sunar.

✨ Özellikler

  • 📦 Paket Bilgileri: Güncel versiyon, açıklama, bağımlılıklar ve kurulum talimatları

  • 🔍 Akıllı Arama: Anahtar kelime ile Flutter paket arama

  • 📊 Versiyon Yönetimi: Tüm paket versiyonlarını listeleme ve karşılaştırma

  • 📖 Kapsamlı Dokümantasyon: README, API dokümantasyonu ve özel dokümantasyon

  • ⭐ Paket Değerlendirmesi: Popülerlik, kalite skorları ve topluluk beğenileri

  • 🔥 Trend Analizi: En popüler ve trend olan paketleri keşfetme

  • 🇹🇷 Türkçe Destek: Tamamen Türkçe arayüz ve açıklamalar

Related MCP server: Flutter MCP Service

🛠️ Kurulum

Ön Koşullar

  • Node.js v18 veya üzeri (İndir)

  • npm veya yarn paket yöneticisi

  • Claude Desktop veya MCP destekli bir AI client

1. Projeyi Klonlayın

git clone https://github.com/OrtakProje-1/flutter-package-mcp-server.git
cd flutter-package-mcp-server

2. Bağımlılıkları Yükleyin

npm install

3. Projeyi Build Edin

npm run build

4. Test Edin

npm run dev

Server başarıyla çalışırsa terminalden çıkmak için Ctrl+C kullanın.

🔧 MCP Client Kurulumu

Claude Desktop ile Kullanım

  1. Claude Desktop Config Dosyasını Bulun:

    macOS:

    ~/Library/Application Support/Claude/claude_desktop_config.json

    Windows:

    %APPDATA%\Claude\claude_desktop_config.json

    Linux:

    ~/.config/Claude/claude_desktop_config.json

  2. Config dosyasını düzenleyin:

    {
  "mcpServers": {
    "flutter-packages": {
      "command": "node",
      "args": ["/FULL/PATH/TO/flutter-package-mcp-server/dist/index.js"],
      "env": {}
    }
  }
}

    ⚠️ Önemli: /FULL/PATH/TO/flutter-package-mcp-server kısmını projenin gerçek tam yolu ile değiştirin.

  3. Claude Desktop'ı yeniden başlatın

Cursor IDE ile Kullanım

  1. Cursor ayarlarını açın (Cmd/Ctrl + ,)

  2. MCP ayarlarına şu konfigürasyonu ekleyin:

    {
  "mcp": {
    "servers": {
      "flutter-packages": {
        "command": "node",
        "args": ["/FULL/PATH/TO/flutter-package-mcp-server/dist/index.js"]
      }
    }
  }
}

  3. Cursor'u yeniden başlatın

Diğer MCP Clientlar

Bu server, MCP standardını destekleyen herhangi bir client ile kullanılabilir. Server stdio üzerinden iletişim kurar.

🎯 Kullanım Örnekleri

Paket Bilgisi Alma

"http paketinin güncel bilgilerini ve kurulum talimatlarını getir"

Paket Arama

"state management için en iyi Flutter paketlerini ara"

Versiyon Karşılaştırması

"provider paketinin tüm versiyonlarını listele"

Dokümantasyon

"bloc paketinin detaylı dokümantasyonunu ve kullanım örneklerini getir"

Trend Analizi

"Bu ay trend olan Flutter paketlerini göster"

Paket Değerlendirmesi

"riverpod ve provider paketlerini karşılaştır, hangisi daha popüler?"

🛠️ Geliştirme

Geliştirme Ortamını Hazırlama

# Repository'yi fork edin ve klonlayın
git clone https://github.com/OrtakProje-1/flutter-package-mcp-server.git
cd flutter-package-mcp-server

# Bağımlılıkları yükleyin
npm install

# Geliştirme modunda çalıştırın
npm run dev

Mevcut Scriptler

# TypeScript'i build et
npm run build

# Geliştirme modunda çalıştır (hot reload)
npm run dev

# Production modunda çalıştır
npm start

# Tip kontrolü
npm run type-check

Proje Yapısı

flutter-package-mcp-server/
├── src/
│   └── index.ts          # Ana server kodu
├── dist/                 # Build edilmiş dosyalar
├── package.json
├── tsconfig.json
└── README.md

Yeni Özellik Ekleme

  1. src/index.ts dosyasında FlutterPackageMCPServer sınıfına yeni method ekleyin

  2. setupToolHandlers() metodunda yeni tool'u tanımlayın

  3. CallToolRequestSchema handler'ında yeni case ekleyin

  4. Build edin ve test edin

📊 Mevcut API Araçları

Araç Adı

Açıklama

Parametreler

get_package_info

Paket detaylarını getirir

package_name: string

search_packages

Paket arama yapar

query: string, page?: number

get_package_versions

Tüm versiyonları listeler

package_name: string

get_package_documentation

Dokümantasyon getirir

package_name: string, version?: string

get_package_score

Paket skorlarını getirir

package_name: string

get_trending_packages

Trend paketleri listeler

page?: number

⚡ Performans ve Limitler

Pub.dev API Limitleri

  • Rate Limiting: Saniyede 10 istek, dakikada 600 istek

  • Günlük Limit: 36,000 istek/saat

  • Timeout: 30 saniye

Optimizasyon İpuçları

  • Sık kullanılan paketler için cache kullanımı planlanıyor

  • Batch istekler gelecek versiyonda eklenecek

🐛 Sorun Giderme

Server Çalışmıyor

# Node.js versiyonunu kontrol edin
node --version  # v18+ olmalı

# Bağımlılıkları yeniden yükleyin
rm -rf node_modules package-lock.json
npm install

# Build işlemini tekrarlayın
npm run build

Claude Desktop Bağlantı Sorunu

  1. Config dosyası konumunu doublcheck edin

  2. JSON syntax'ının doğru olduğundan emin olun

  3. Dosya yolunun mutlak path olduğunu kontrol edin

  4. Claude Desktop'ı tamamen kapatıp açın

API Hataları

# İnternet bağlantısını test edin
curl https://pub.dev/api/packages/http

# DNS sorunları için
nslookup pub.dev

# Proxy ayarlarınızı kontrol edin
echo $HTTP_PROXY
echo $HTTPS_PROXY

Debug Modu

# Detaylı loglar için
DEBUG=* npm run dev

# Sadece MCP logları için
DEBUG=mcp:* npm run dev

🤝 Katkıda Bulunma

Katkılarınızı memnuniyetle karşılıyoruz!

Katkı Süreci

  1. Fork edin

  2. Feature branch oluşturun (git checkout -b feature/amazing-feature)

  3. Değişikliklerinizi commit edin (git commit -m 'Add amazing feature')

  4. Branch'inizi push edin (git push origin feature/amazing-feature)

  5. Pull Request oluşturun

Geliştirme Kuralları

  • TypeScript strict mode kullanın

  • Her yeni özellik için test yazın

  • Commit mesajlarında conventional commit formatını kullanın

  • README'yi güncel tutun

İstenen Özellikler

  • Package caching sistemi

  • Offline mod desteği

  • Batch API istekleri

  • Package dependency tree görselleştirmesi

  • Vulnerability checking

  • License compatibility kontrolü

📄 Lisans

Bu proje MIT lisansı altında lisanslanmıştır. Detaylar için LICENSE dosyasına bakın.

🙏 Teşekkürler

📞 Destek

Sorularınız veya sorunlarınız için:

⭐ Bu proje faydalı olduysa star vermeyi unutmayın!

Made with ❤️ for Flutter Community

Available Tools

6 tools
get_package_documentationC

Paketin README ve dokümantasyon bilgilerini getirir

ParametersJSON Schema
NameRequiredDescriptionDefault
package_nameYesFlutter paket adı
versionNoPaket versiyonu (varsayılan: latest)

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 retrieving documentation but doesn't specify aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what format the documentation is returned in (e.g., raw text, structured data). This leaves significant gaps for a tool with no annotation coverage.

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, efficient sentence in Turkish that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more structured (e.g., by front-loading key details more explicitly).

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 doesn't explain what the tool returns (e.g., the format of documentation information), behavioral traits, or usage context relative to siblings. For a tool with no structured data beyond the input schema, this leaves the agent with insufficient information to use it effectively.

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 clear descriptions for both parameters ('package_name' and 'version'), so the schema does the heavy lifting. The description doesn't add any additional semantic context beyond what's in the schema, such as examples or constraints, but this is acceptable given the high coverage, resulting in a baseline score.

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 ('getirir' - fetches/retrieves) and the resource ('README ve dokümantasyon bilgilerini' - README and documentation information), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_package_info', which might also retrieve documentation-related information, so it doesn't reach the highest score.

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 'get_package_info' or 'search_packages'. It lacks context about specific scenarios or prerequisites, leaving the agent to infer usage based on the tool name alone.

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

get_package_infoC

Flutter paketinin güncel bilgilerini getirir (versiyon, açıklama, bağımlılıklar)

ParametersJSON Schema
NameRequiredDescriptionDefault
package_nameYesFlutter paket adı (örn: http, provider, bloc)

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. It states the tool retrieves current package information but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, returns structured data, handles errors, or if it's a read-only operation. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

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 in Turkish that directly states the tool's purpose and what information it retrieves. It's front-loaded with the main action and includes specific details (version, description, dependencies) without unnecessary words. Every part of the sentence contributes to understanding the tool's function.

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 complexity of retrieving package information, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., JSON structure), error handling, or any behavioral context. For a tool that likely interacts with an external package registry, more details on response structure and limitations would be necessary for effective use by an AI 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 has 100% coverage with a clear description for the single parameter 'package_name'. The description adds minimal value beyond the schema by implying the parameter is for a Flutter package and providing examples (http, provider, bloc), but doesn't elaborate on format constraints or additional semantics. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.

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 ('getirir' - retrieves) and resource ('Flutter paketinin güncel bilgilerini' - current information of a Flutter package), specifying what information is retrieved (version, description, dependencies). It distinguishes from siblings by focusing on current package information rather than documentation, scores, versions, trending, or search. However, it doesn't explicitly differentiate from 'get_package_versions' which might overlap in providing version information.

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 'get_package_versions' (which might provide version history) or 'get_package_documentation' (which might provide documentation). There's no mention of prerequisites, context for use, or exclusions. The agent must infer usage from the tool name and description alone.

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

get_package_scoreC

Paketin pub.dev puanlarını ve popülerlik skorunu getirir

ParametersJSON Schema
NameRequiredDescriptionDefault
package_nameYesFlutter paket adı

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 states the tool fetches scores but doesn't describe what happens if the package doesn't exist, rate limits, authentication needs, or the format of returned data (e.g., numeric scores, timestamps). For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.

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 in Turkish that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding the 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?

Given the complexity (a read operation with no output schema and no annotations), the description is incomplete. It doesn't explain what 'puanlar' (scores) or 'popülerlik skorunu' (popularity score) entail, how they're formatted, or potential error cases. For a tool that fetches data, more context on the return values and behavior is needed to be fully helpful.

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 the single parameter 'package_name' documented as 'Flutter paket adı' (Flutter package name) in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples or constraints, so it meets the baseline for high schema coverage.

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: 'getirir' (gets/fetches) 'pub.dev puanlarını ve popülerlik skorunu' (pub.dev scores and popularity score) for a package. It specifies the action (fetching) and resource (package scores), though it doesn't explicitly differentiate from siblings like 'get_package_info' or 'get_package_documentation' beyond mentioning scores specifically.

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 doesn't mention sibling tools like 'get_package_info' (which might provide broader information) or 'search_packages' (for finding packages), leaving the agent to infer usage based on tool names alone.

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

get_package_versionsC

Paketin tüm sürümlerini listeler

ParametersJSON Schema
NameRequiredDescriptionDefault
package_nameYesFlutter paket adı

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 states the tool lists versions but doesn't describe return format (e.g., list structure, pagination), error handling, rate limits, or authentication needs. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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: 'Paketin tüm sürümlerini listeler.' It's front-loaded with the core action and resource, with zero wasted words. This is appropriately sized for a simple tool.

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 doesn't explain what the tool returns (e.g., version list format, metadata), behavioral traits like error cases, or how it differs from siblings. For a tool with no structured output documentation, more context is needed to be fully helpful.

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 description doesn't add meaning beyond the input schema, which has 100% coverage for the single parameter 'package_name' (described as 'Flutter paket adı'). Since schema coverage is high, the baseline is 3. The description doesn't elaborate on parameter usage or constraints, so it meets but doesn't exceed the minimum.

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: 'Paketin tüm sürümlerini listeler' (Lists all versions of a package). It specifies the verb 'listeler' (lists) and resource 'paketin tüm sürümlerini' (all versions of a package), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_package_info' or 'get_package_documentation', which might also provide version-related information.

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 doesn't mention sibling tools like 'get_package_info' (which might include version data) or 'search_packages' (for broader queries), nor does it specify prerequisites or exclusions. Usage is implied by the action but lacks explicit context.

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

search_packagesC

Flutter paketlerini anahtar kelimeye göre arar

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesArama terimi
pageNoSayfa numarası (varsayılan: 1)

TDQS

C2.9/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 only states the basic search function without mentioning pagination behavior (implied by the 'page' parameter), rate limits, authentication needs, or what the search results include (e.g., package names, descriptions). This is inadequate for a tool with parameters and no output schema.

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 in Turkish that directly states the tool's function. It's front-loaded with the core purpose and contains no redundant information, making it optimally concise while remaining clear.

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 tool's complexity (search with pagination), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the search returns (e.g., list of packages with basic info), how results are ordered, or error conditions. For a search tool without structured output documentation, more context is needed.

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 both parameters ('query' and 'page') clearly documented in the schema. The description adds no additional parameter semantics beyond implying keyword-based search through 'anahtar kelimeye göre' (by keyword). This meets the baseline for high schema coverage but doesn't enhance understanding.

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: searching Flutter packages by keyword. It specifies the verb ('arar' - searches) and resource ('Flutter paketlerini' - Flutter packages), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'get_trending_packages' or 'get_package_info', which prevents a perfect score.

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 doesn't mention sibling tools like 'get_trending_packages' (for popular packages) or 'get_package_info' (for specific package details), nor does it specify use cases like initial discovery versus detailed lookup. This leaves the agent without context for tool selection.

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. 6 tool updates
    • First observedget_package_documentation
    • First observedget_package_info
    • First observedget_package_score
    • First observedget_package_versions
    • First observedget_trending_packages
    • First observedsearch_packages
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose targeting different aspects of Flutter packages. For example, get_package_documentation retrieves documentation, get_package_info provides metadata, and get_package_score focuses on ratings, with no overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case, such as get_package_documentation and search_packages. This uniformity makes the tool set predictable and easy to understand for agents.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose of Flutter package management. Each tool serves a specific, non-redundant function, covering key operations like searching, retrieving info, and trending analysis without being overwhelming.

Completeness4/5

The tool set provides comprehensive coverage for querying and retrieving Flutter package data, including search, info, documentation, versions, scores, and trends. A minor gap exists in update or management operations, but this is reasonable for a read-only package information server.

Maintenance

ActivityInactive
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

  • Flutter MCP

    adamsmaka
    A
    license
    A
    quality
    F
    maintenance
    A real-time server that provides Flutter/Dart documentation and pub.dev package information to AI assistants, ensuring they generate accurate and up-to-date Flutter code.
    8
    73
    MIT

  • Pub.dev MCP Server

    devqxi
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to search, analyze, and retrieve detailed information about Dart and Flutter packages from pub.dev. Supports package discovery, version management, dependency analysis, and documentation access.
    6
    22
    5
    MIT

  • package-registry-mcp

    mikeysrecipes
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to search and retrieve detailed package information from multiple package registries (NPM, crates.io, NuGet, PyPI, Go).
    751
    MIT

Appeared in Searches

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/OrtakProje-1/flutter-package-mcp-server'

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