Bilingual (VN/EN) jokes, quotes, fun facts and short videos from ifun.genai.io.vn.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 5 of 5 tools scored.
Most tools have distinct purposes: get_post by id, joke_of_the_day for today's joke, random_joke for any joke, random_video for videos, and search for keyword queries. The only slight overlap is between joke_of_the_day and random_joke, but their descriptions clearly differentiate them.
Naming patterns are mixed: 'get_post' uses verb_noun, 'joke_of_the_day' uses a noun phrase, 'random_joke' and 'random_video' use adjective_noun, and 'search' is a bare verb. This inconsistency makes the API feel less predictable.
Five tools is well-scoped for a humor/content retrieval service. Each tool serves a clear purpose without unnecessary bloat, and the count feels appropriate for the domain.
The set covers core content retrieval: specific posts, daily/random jokes, random videos, and keyword search. Missing dedicated getters for quotes or fun facts, but the search tool can find those, so the gap is minor and workable.
get_postGet post by idAGet a specific iFun post by its numeric id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The post id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds only the resource type ('iFun post') but no further behavioral context (e.g., return format, errors, pagination). This meets the minimal bar but adds little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no waste. It is front-loaded with the action and resource, making it ideal for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, strong annotations, and no output schema, the description is complete enough for an agent to select and invoke it correctly. It covers what, how, and the specific identifier needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter 'id' with a description, and the description's 'numeric id' restates the schema's integer type. No additional parameter meaning is added, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb ('Get'), the resource ('iFun post'), and the scope ('by its numeric id'), clearly distinguishing it from siblings like random_joke or search. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific post id, which provides clear context. However, it does not explicitly state when not to use it or mention alternative tools for other use cases, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
joke_of_the_dayJoke of the dayAGet iFun's most recent joke — today's joke.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language — vi (default) or en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a minor nuance ('most recent', 'today's') but no extra behavioral details like rate limits, authentication, or fallback behavior. It is consistent with annotations and sufficient for such a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and result. No wasted words, ideal for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and clear read-only annotations, the description provides enough context about what it returns (a joke). It doesn't describe output format, but the tool's purpose is obvious. A score of 4 reflects that it is nearly complete for its simplicity, though a bit more detail on the return could be added.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full documentation for the single 'lang' parameter, including enum values and default (vi). The description adds no additional parameter meaning, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets iFun's most recent joke, with a specific verb ('Get') and resource ('iFun's most recent joke'). It distinguishes itself from the sibling tool 'random_joke' by emphasizing 'most recent' and 'today's', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you want today's joke rather than a random one. It gives clear context about recency but does not explicitly name alternatives or exclusions, though sibling tools like 'random_joke' suggest the contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
random_jokeRandom jokeBGet a random joke from iFun.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language — vi (default) or en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe read operation. The description adds minimal context by naming the source 'iFun' but does not disclose behavior like response format or randomness guarantees. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Get a random joke from iFun.' It is front-loaded with the action and resource, and every word earns its place. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is complete enough. It states the primary action and source. It could clarify return format, but that's largely self-evident for a joke. The presence of annotations and schema coverage compensates for any gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the single parameter 'lang' with enum values and a clear description. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a random joke from iFun.' It uses a specific verb and resource, and the word 'random' helps differentiate from sibling tools like 'joke_of_the_day.' However, it does not explicitly name alternative tools, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like joke_of_the_day or random_video. It does not mention exclusions or alternatives. The use case is implied by the name and description, but there is no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
random_videoRandom videoAGet a random short video from iFun (returns its page URL and the video file URL).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language — vi (default) or en. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the random selection behavior and discloses the output structure (page URL and video file URL), providing useful context beyond the annotations. It could mention more about rate limits or language behavior, but it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the operation and clearly states the returned data. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter tool with good annotations, the description adequately covers the operation and return value. It does not mention the language parameter or alternative tools, but the schema and sibling context fill those gaps. Overall, it is sufficiently complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter 'lang' with a description, enum, and default value (vi), making schema coverage 100%. The description adds no additional meaning about this parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('random short video'), identifies the source ('from iFun'), and states the exact return values ('page URL and the video file URL'). This clearly distinguishes it from sibling tools like random_joke or get_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as random_joke or search. The intended use is implied by the name and description, but there is no mention of alternatives, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch iFunASearch iFun for jokes, quotes, fun facts and short videos by keyword. Returns up to 10 matches.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language — vi (default) or en. | |
| query | Yes | Keyword or phrase to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds a useful behavioral constraint (returns a maximum of 10 matches) and clarifies it searches across multiple content types. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action ('Search iFun') and complete with a key functional detail (result limit). Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (one required, one optional with defaults), the description sufficiently covers search scope and the result count. Since there is no output schema, specifying the exact structure of returned matches would be beneficial, but the tools' simplicity and the sibling context make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'query' and 'lang' are already described in the schema. The description's mention of 'by keyword' aligns with the query parameter but adds no new semantics beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and identifies the resource 'iFun' and the content types (jokes, quotes, fun facts, short videos), making its purpose unmistakable. This clearly distinguishes it from the sibling tools that return random content (e.g., random_joke, random_video).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('by keyword') and caps results at 10, but it does not explicitly mention alternatives or contrast with the random tools. The guidance is reasonably implied but not stated directly, so it falls short of a clear exclusion or explicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!