Skip to main content
Glama

search_flet_ecosystem

Search the open-source Flet ecosystem for third-party packages that add features not available in the core library.

Instructions

Search the open-source community for third-party Flet packages and components. Use this when the user wants to add a feature (e.g., 'calendar', 'table', 'auth') that might not be in the core Flet library.

Args: query: The keyword to search for (e.g., 'calendar').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Core implementation in FletPackageFetcher class: searches GitHub repositories matching 'flet {query} language:python', fetches up to 15 results sorted by stars, verifies each is a real PyPI package depending on 'flet' via _is_true_flet_package, and returns name/description/stars/url/verified status.
    async def search_flet_ecosystem(self, query: str) -> list[dict]:
        """Searches GitHub for third-party Flet packages and verifies them."""
        search_query = f"flet {query} language:python"
        url = f"https://api.github.com/search/repositories?q={search_query}&sort=stars&order=desc&per_page=15"
        
        data = await self._fetch_json(url, headers=self.github_headers)
        if not data or "items" not in data:
            return []
    
        results = []
        for item in data["items"]:
            # Check if this GitHub repo is actually a published PyPI package depending on flet
            repo_name = item["name"]
            is_verified = await self._is_true_flet_package(repo_name)
            
            results.append({
                "name": repo_name,
                "full_name": item["full_name"],
                "description": item["description"],
                "stars": item["stargazers_count"],
                "url": item["html_url"],
                "is_verified_flet_package": is_verified
            })
        return results
  • MCP tool registration via @mcp.tool() decorator. The server delegates to pkg_fetcher.search_flet_ecosystem().
    @mcp.tool()
    async def search_flet_ecosystem(query: str) -> list[dict]:
        """
        Search the open-source community for third-party Flet packages and components.
        Use this when the user wants to add a feature (e.g., 'calendar', 'table', 'auth') 
        that might not be in the core Flet library.
        
        Args:
            query: The keyword to search for (e.g., 'calendar').
        """
        return await pkg_fetcher.search_flet_ecosystem(query)
  • Helper used by search: queries PyPI JSON API to check if a package's requires_dist includes 'flet' as a dependency, filtering out non-Flet repositories.
    async def _is_true_flet_package(self, package_name: str) -> bool:
        """Verifies PyPI metadata to ensure the package actually depends on flet."""
        url = f"https://pypi.org/pypi/{package_name}/json"
        data = await self._fetch_json(url)
        
        if not data or "info" not in data:
            return False
            
        requires_dist = data["info"].get("requires_dist")
        if not requires_dist:
            # Some packages might be Flet related but not strictly depend on 'flet' in metadata
            # but for a 'strict' check we require it.
            return False
            
        for req in requires_dist:
            # Clean up requirement string (e.g. 'flet (>=0.1.1) ; extra == "all"')
            dep_name = req.split(";")[0].split(" ")[0].split(">")[0].split("=")[0].split("<")[0]
            base_name = dep_name.split("[")[0].strip().lower()
            if base_name == "flet":
                return True
        return False
  • Low-level HTTP helper with diskcache support (24h TTL), used by search_flet_ecosystem to fetch GitHub search results.
    async def _fetch_json(self, url: str, headers: dict | None = None) -> dict | None:
        if url in cache:
            return cache[url]
        try:
            response = await self.client.get(url, headers=headers)
            if response.status_code == 200:
                data = response.json()
                cache.set(url, data, expire=86400)
                return data
        except Exception:
            pass
        return None
Behavior2/5

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

No annotations are provided, so the description must convey all behavioral traits. It only says 'search' but does not describe what is returned (e.g., list of packages, relevance ordering, limits) or any side effects. The presence of an output schema is noted but not mentioned in the description.

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 extremely concise at three sentences. The first sentence states the purpose, the second gives usage context, and the third describes the parameter. No unnecessary words, and key information is front-loaded.

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 simplicity (one parameter, no annotations), the description covers the essential: purpose, when to use, and parameter meaning. The output schema exists but the description does not explain return values, which is acceptable per the instructions. Overall, it feels nearly complete for a straightforward search tool.

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?

There is one parameter 'query', and the description adds an example ('calendar') but does not elaborate on format or constraints. Schema description coverage is 0%, so the description partially compensates but could provide more detail like case sensitivity or wildcard usage.

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 searches for third-party Flet packages and components. It distinguishes from siblings like search_flet_docs by targeting the community ecosystem, and provides an example use case ('calendar', 'table', 'auth').

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 explicitly tells when to use this tool: when the user wants a feature not in the core Flet library. It implies alternatives (core library tools) but does not list them directly. The context from sibling tools helps, but the description could be more explicit about when not to use it.

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

Install Server

Other Tools

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/Nwokike/flet-mcp-server'

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