Flutter Package MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 2.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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 trending packages, implying a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication needs, pagination details (beyond the 'page' parameter in the schema), or what 'trending' means (e.g., based on downloads, time frame). This is a significant gap 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: 'Trend olan Flutter paketlerini listeler.' It's front-loaded and wastes no words, clearly stating the tool's purpose. However, it could be slightly improved by adding context or usage hints without losing conciseness, so it doesn't reach a perfect score of 5.
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 (listing trending packages), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'trending' entails, how results are sorted, or what the output format is (e.g., list of package names with details). This leaves gaps for the agent to understand the tool's behavior fully, especially without annotations to compensate.
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 'page' parameter documented as 'Sayfa numarası (varsayılan: 1)' (Page number, default: 1). The description doesn't add any meaning beyond this, such as explaining pagination behavior or range limits. With high schema coverage, the baseline score is 3, as the schema adequately handles parameter documentation.
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: 'Trend olan Flutter paketlerini listeler' (Lists trending Flutter packages). It specifies the verb 'listeler' (lists) and the resource 'Flutter paketlerini' (Flutter packages), making the action and target clear. However, it doesn't explicitly differentiate from sibling tools like 'search_packages' or 'get_package_info', which could have overlapping functionality, so it doesn't reach 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 doesn't mention any context, prerequisites, or exclusions, and doesn't reference sibling tools like 'search_packages' for broader searches or 'get_package_info' for detailed information. This lack of usage instructions leaves the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![flutter-package-mcp-server MCP server](https://glama.ai/mcp/servers/OrtakProje-1/flutter-package-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/OrtakProje-1/flutter-package-mcp-server)

Score Badge

Copy to your README.md:

[![flutter-package-mcp-server MCP server](https://glama.ai/mcp/servers/OrtakProje-1/flutter-package-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/OrtakProje-1/flutter-package-mcp-server)

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

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