Freepik FastMCP Toolkit

Official

by freepik-company

Overview Schema Related Servers Score Discussions

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as detect_ai_image for AI detection and text_to_image_mystic_sync for AI image generation. However, there is some overlap between download_resource_by_id and get_resource_download_formats, as both handle downloading resources by ID with format specifications, which could cause confusion. The descriptions help differentiate them, but the similarity in function is notable.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a verb_noun structure, such as detect_ai_image, download_icon_by_id, and search_resources. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions across the nine tools.
Tool Count4/5
With 9 tools, the count is well within the typical 3-15 range for a well-scoped server, covering icon and resource management, AI detection, and image generation. It feels slightly heavy due to some redundancy in download functions, but overall, each tool serves a purpose in the Freepik domain, making it reasonable for the toolkit's scope.
Completeness4/5
The tool set provides strong coverage for searching, retrieving details, and downloading icons and resources, along with AI-related functions like detection and generation. Minor gaps exist, such as the lack of update or delete operations for resources, which are less critical in this context, and no tool for managing user accounts or licenses. However, core workflows for content discovery and access are well-supported.
Average 2.8/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
This repository includes a glama.json configuration file.
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?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions authentication requirements (401 response) and error conditions, but lacks details on rate limits, processing time, model accuracy, or what constitutes a valid image. The HTTP response documentation adds some value but doesn't fully compensate for missing annotations.
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 description is poorly structured with excessive HTTP response documentation that belongs in an output schema. The core purpose is buried under verbose response examples, making it inefficient for quick understanding. The response section adds unnecessary bulk without corresponding value.
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?
For a tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks crucial details about parameter constraints, performance characteristics, accuracy limitations, and practical usage considerations needed for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single parameter 'image' beyond what's in the schema. It doesn't explain acceptable image formats, size limits, or quality requirements, leaving significant gaps in parameter understanding.
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 purpose with specific verb ('analyzes') and resource ('image file'), explaining it determines AI generation probability with a confidence score. It distinguishes itself from sibling tools like text_to_image_mystic_sync by focusing on detection rather than generation.
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 explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, limitations, or comparison with other tools, leaving the agent without context for appropriate tool selection.
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 mentions HTTP response codes (200, 400, 401, 404, 500) and includes an example response, but lacks critical details like authentication needs, rate limits, whether it's a read-only operation, or any side effects. The example response is overly verbose and repetitive, adding noise rather than clarity.
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 description is poorly structured and excessively long due to the inclusion of a massive, repetitive JSON example that duplicates data unnecessarily. The core information is buried under verbose examples, making it difficult to parse quickly. A more concise approach would focus on key details without redundant examples.
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 (retrieving detailed icon data) and the absence of annotations and output schema, the description is incomplete. It lacks information on authentication, rate limits, error handling specifics beyond HTTP codes, and how to interpret the response structure efficiently. The verbose example doesn't compensate for these gaps.
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 already fully documents both parameters ('id' and 'Accept-Language'). The description adds a brief mention of the 'id' parameter in the 'Path Parameters' section but doesn't provide additional semantic context beyond what's in the schema. This 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 as 'Get detailed information about a specific icon identified by its unique ID,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_resource_detail_by_id' or 'search_icons,' which appear to serve related but distinct purposes.
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_resource_detail_by_id' for non-icon resources or 'search_icons' for browsing, nor does it specify prerequisites such as authentication requirements or rate limits.
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. While it mentions the tool retrieves/downloads resources and includes HTTP response codes (e.g., 200, 400, 429), it lacks critical behavioral details: it doesn't specify authentication requirements, rate limits beyond the 429 error mention, whether it's read-only or mutative, what happens on success (e.g., returns signed URLs), or any side effects. The description is insufficient 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured and verbose. It starts with a clear purpose statement but then includes extensive, redundant HTTP response documentation (e.g., multiple error codes with examples) that belongs in an output schema or annotations, not in the description. This bloats the text without adding helpful guidance for tool selection, making it inefficient and not front-loaded.
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 no annotations and no output schema, the description is incomplete for a tool with 2 parameters. It lacks essential context: no explanation of return values (though the 200 response example shows data with URLs, this isn't clarified in the description text), no behavioral traits like auth needs or rate limits, and no differentiation from siblings. The HTTP error details don't compensate for these gaps, making it inadequate for informed tool 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 both parameters ('resource-id' and 'resource-format') with descriptions and enum values. The description adds minimal value beyond the schema, only restating that parameters are required for precise downloading. No additional syntax, format details, or examples are provided in the description text itself.
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: 'Retrieve a resource by specifying both the resource ID and the format' and 'allows for precise downloading of resources in the desired format.' It specifies the verb (retrieve/download) and resource (resource by ID and format). However, it doesn't explicitly differentiate from sibling tools like 'download_resource_by_id' or 'get_resource_detail_by_id', which appear to serve similar purposes with different approaches.
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 'download_resource_by_id' or 'get_resource_detail_by_id', nor does it specify prerequisites, constraints, or typical use cases. The only implied usage is for downloading resources with specific formats, but no comparative context is given.
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 full burden for behavioral disclosure. It mentions the tool 'supports multiple resource types' and includes HTTP response codes with examples, which adds some context. However, it doesn't disclose critical behavioral traits like authentication requirements, rate limits, whether it's idempotent, or error handling specifics beyond status codes. For a read operation with no 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and poorly structured for an AI agent. It front-loads the purpose but then includes massive JSON response examples (over 200 lines) that belong in an output schema, not a description. The 'Path Parameters' section duplicates schema information. While comprehensive, it violates conciseness principles by including implementation details that don't help an agent select or invoke the tool correctly.
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 no annotations and no output schema, the description attempts to compensate with extensive response examples and error codes. However, this creates information overload rather than targeted completeness. It covers response formats but misses behavioral context like authentication needs. For a read operation with 2 parameters, it's partially complete but inefficiently organized, mixing tool selection guidance with implementation details.
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 already documents both parameters thoroughly. The description adds minimal parameter semantics beyond the schema: it repeats the resource-id requirement in a 'Path Parameters' section but doesn't provide additional context about ID formats or examples. The Accept-Language parameter isn't mentioned in the description at all. With high schema coverage, baseline 3 is appropriate as the description adds little value over the structured schema.
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: 'Retrieve the detailed information of a specific resource by its ID' with specific resource types listed (PSD, vector, photo, AI-generated content). It distinguishes from siblings like search_resources (which searches) and download_resource_by_id (which downloads), but doesn't explicitly contrast them. The verb 'retrieve' and resource specificity are clear, though sibling differentiation is implicit rather than explicit.
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 explicit guidance on when to use this tool versus alternatives. While it mentions resource types, it doesn't indicate when to choose this over get_icon_detail_by_id for icons, or when detailed info is needed versus download_resource_by_id for downloading. No prerequisites, exclusions, or alternative scenarios are mentioned, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses the resource types supported (vectors, PSDs, photos, AI-generated content) and includes HTTP response codes with examples, which adds behavioral context like authentication needs (401), rate limits (429), and error handling. However, it lacks details on permissions, side effects, or performance characteristics, leaving gaps for a mutation-like download operation.
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 description is overly verbose and poorly structured. It includes extensive HTTP response details that belong in an output schema or annotations, not in the description. The first two sentences are front-loaded, but the bulk is redundant parameter info and response examples, making it inefficient and cluttered.
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 no annotations and no output schema, the description compensates by including response codes and examples, which helps understand behavior. However, for a download tool with 3 parameters and mutation-like effects, it should better explain side effects, return values, and usage context. It's minimally adequate but has clear gaps in completeness.
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 already documents all parameters thoroughly. The description repeats parameter details in the 'Path Parameters' and 'Query Parameters' sections, adding no new semantic meaning beyond what's in the schema. This meets the baseline of 3, as the schema does the heavy lifting without extra value from the description.
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: 'Download a specific resource by providing the resource ID' with a verb ('download') and resource ('resource'). It distinguishes from siblings like 'get_resource_detail_by_id' (which retrieves metadata) and 'download_icon_by_id' (which is icon-specific). However, it doesn't explicitly contrast with all siblings, keeping it at 4 rather than 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 siblings like 'get_resource_download_formats' (which might list formats before download) or 'download_icon_by_id' (for icons specifically). There's no context about prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adds some context: it describes pagination behavior (via 'page' and 'per_page'), default values (e.g., 'thumbnail_size' defaults to 128), and search logic (e.g., term/slug interactions). However, it lacks details on rate limits, authentication needs, or error handling beyond HTTP codes, leaving gaps for a tool with 9 parameters.
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 description is overly verbose and poorly structured. It front-loads the purpose but then duplicates schema details and includes extensive, repetitive JSON examples for responses. The 'Query Parameters' and 'Responses' sections add bulk without significant new information, making it inefficient and hard to scan.
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 complexity (9 parameters, nested objects) and lack of annotations or output schema, the description is moderately complete. It covers basic functionality, parameters, and response formats with examples, but it misses behavioral aspects like authentication requirements or rate limits. The inclusion of HTTP response details helps, but it's not fully compensatory for the missing structured data.
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 already documents all parameters thoroughly. The description repeats parameter information in the 'Query Parameters' section, adding minimal value beyond the schema. It does clarify interactions (e.g., term/slug search logic) and defaults, but this is largely redundant with the schema descriptions.
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: 'Get a list of icons based on the provided parameters and ordering criteria.' It specifies the verb ('Get') and resource ('icons'), and distinguishes it from siblings like 'download_icon_by_id' or 'get_icon_detail_by_id' by focusing on search/list functionality. However, it doesn't explicitly differentiate from 'search_resources' (a sibling tool), which might cause ambiguity.
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 'search_resources' (which might overlap) or 'get_icon_detail_by_id' (for single icons), nor does it specify prerequisites or exclusions. Usage is implied through the description of parameters 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.
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 does mention pagination behavior (page/limit parameters) and includes extensive HTTP response documentation with status codes and examples. However, it doesn't cover important aspects like rate limits, authentication requirements, or whether this is a read-only operation (though 'retrieve' implies read-only).
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 description is excessively long and poorly structured. It includes massive JSON response examples (over 500 lines) that belong in an output schema, not a tool description. The core purpose statement is buried under parameter details and response documentation. While the initial sentence is concise, the overall structure is bloated with redundant information.
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?
For a complex search tool with 6 parameters, nested objects, and no output schema, the description is incomplete. While it documents HTTP responses extensively, it lacks crucial context about authentication, rate limits, error handling beyond HTTP codes, and how to interpret the complex response structure. The massive example doesn't compensate for missing behavioral guidance.
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%, so the schema already documents all parameters thoroughly. The description repeats some parameter information (page, limit, order, term, filters) but doesn't add significant semantic value beyond what's in the schema. The baseline of 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.
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: 'Retrieve a list of resources based on various filter criteria.' It specifies the verb ('retrieve'), resource ('resources'), and scope ('based on various filter criteria'). However, it doesn't explicitly differentiate from sibling tools like 'search_icons' or 'get_resource_detail_by_id', which would be needed for 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 'search_icons' for icon-specific searches or 'get_resource_detail_by_id' for single resource details. There's no context about prerequisites, authentication requirements, or typical use cases.
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 mentions the tool is an 'endpoint' and includes HTTP response codes (200, 400, etc.), implying it's a web API call, but lacks critical behavioral details such as authentication requirements, rate limits, asynchronous processing (implied by 'task_id' but not explained), or potential side effects like resource consumption.
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 description is poorly structured and not front-loaded. It starts with a concise purpose statement but devotes most of its length to verbose HTTP response examples and formatting, which are redundant for an AI agent and clutter the core information. This wastes space and reduces clarity.
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 (15 parameters, no annotations, no output schema), the description is incomplete. It lacks essential context such as authentication needs, rate limits, asynchronous behavior explanation, error handling beyond HTTP codes, and guidance on parameter combinations. The heavy reliance on the schema is insufficient for a tool of this sophistication.
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 high at 93%, so the baseline is 3. The description adds minimal value beyond the schema, stating only 'This endpoint accepts a variety of parameters to customize the generated images,' which is generic and doesn't elaborate on parameter interactions or usage scenarios. It doesn't compensate for the 7% coverage gap.
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 purpose: 'Convert descriptive text input into images using AI.' It specifies the verb ('convert'), resource ('descriptive text input'), and output ('images'), and distinguishes it from sibling tools like detect_ai_image or search_icons by focusing on generation rather than detection, download, or search.
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 mentions 'This endpoint accepts a variety of parameters to customize the generated images,' but offers no explicit context, prerequisites, or comparisons to sibling tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adds some context beyond basic purpose, such as format restrictions for certain icon types and size applicability for PNG, but lacks details on authentication needs, rate limits, or what the download entails (e.g., file retrieval vs. metadata). No contradiction with annotations exists.
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 description is overly verbose and poorly structured, including extensive HTTP response details that are not needed for an AI agent. It mixes tool description with API documentation, making it front-loaded with useful info but cluttered with redundant sections like full error examples, which reduces clarity and efficiency.
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 no annotations and no output schema, the description partially compensates by including format/size constraints and response examples, but it's incomplete for a download tool. It misses key behavioral aspects like authentication requirements or download mechanics, and the verbose structure detracts from providing a clear, complete overview.
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 already documents all parameters thoroughly. The description adds minimal value beyond the schema, such as repeating format and size notes, but doesn't provide additional semantic context like usage examples or edge cases. Baseline 3 is appropriate given high schema coverage.
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 purpose with specific verb ('Download') and resource ('icon by its unique ID'), and distinguishes it from siblings like 'get_icon_detail_by_id' (which retrieves metadata) and 'download_resource_by_id' (which downloads resources, not specifically icons). The mention of 'requested format and size' further specifies the action.
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 explicit guidance on when to use this tool versus alternatives is provided. While the purpose implies it's for downloading icons, it doesn't differentiate from 'download_resource_by_id' or explain when to choose one over the other. The description lacks context about prerequisites or typical use cases.
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:

[![freepik-mcp MCP server](https://glama.ai/mcp/servers/freepik-company/freepik-mcp/badges/card.svg)](https://glama.ai/mcp/servers/freepik-company/freepik-mcp)

Score Badge

Copy to your README.md:

[![freepik-mcp MCP server](https://glama.ai/mcp/servers/freepik-company/freepik-mcp/badges/score.svg)](https://glama.ai/mcp/servers/freepik-company/freepik-mcp)

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/freepik-company/freepik-mcp'

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