Wisnu MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: calculate_trip_cost handles cost estimation, get_travel_tips provides destination advice, search_destinations recommends places based on preferences, search_flights finds flights, and search_hotels finds accommodations. The descriptions reinforce these unique functions, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case: calculate_trip_cost, get_travel_tips, search_destinations, search_flights, and search_hotels. This uniformity makes the set predictable and easy to understand, with no deviations in style or convention.
Tool Count5/5
With 5 tools, this server is well-scoped for travel planning, covering key aspects like cost calculation, destination recommendations, tips, flights, and hotels. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness4/5
The tool set covers core travel planning workflows: search (destinations, flights, hotels), cost estimation, and tips. Minor gaps exist, such as no booking or reservation tools, but agents can work around this by using search results for manual follow-up, and the surface supports most agent-driven planning tasks effectively.
Average 3.1/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type ('Dictionary with travel tips') but fails to describe key traits like whether it's a read-only operation, potential rate limits, data sources, or error handling. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded, starting with the core purpose followed by structured sections for arguments and returns. Each sentence serves a clear function, with no redundant information. However, the 'Args' and 'Returns' sections could be integrated more smoothly into the flow, slightly affecting readability.
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 moderate complexity (2 parameters, no annotations, but has an output schema), the description is partially complete. It covers the basic purpose and parameters but lacks usage guidelines and detailed behavioral context. The presence of an output schema reduces the need to explain return values, but overall, it's adequate with clear gaps for a tool in this context.
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 0%, so the description must compensate. It lists the parameters ('destination' and 'trip_type') and provides basic semantics ('Destination city or country' and 'Type of trip'), which adds value beyond the bare schema. However, it doesn't explain the enum values for 'trip_type' or provide examples, leaving some ambiguity. Given the low coverage, this is a minimal but adequate effort.
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 with a specific verb ('Get') and resource ('travel tips and recommendations for a destination'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_destinations', which might also provide destination-related information, leaving room for ambiguity in tool selection.
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 'search_destinations' or other siblings. It lacks context about prerequisites, such as whether it's for planning or post-booking, and offers no exclusions or comparisons, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool calculates 'estimated' costs, implying approximation rather than exact figures, but doesn't disclose important behavioral traits like whether calculations are real-time, if currency conversion is handled, what assumptions are made, or whether results are cached. For a financial calculation tool 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and appropriately sized. The opening statement is front-loaded with the core purpose. Each sentence earns its place by providing essential information. Minor room for improvement in eliminating the redundant 'Args:' and 'Returns:' labels since the structure already implies these sections.
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 moderate complexity (5 parameters, financial calculations), no annotations, but with an output schema present, the description is minimally adequate. It explains parameters well and notes the return format, but lacks context about calculation methodology, currency handling, rounding behavior, or error conditions. The presence of an output schema means the description doesn't need to detail return values, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate - and it does so effectively by explaining all 5 parameters in the Args section. Each parameter gets a clear semantic explanation beyond just naming them: 'Cost of flights per person', 'Hotel cost per night', 'Number of nights', 'Estimated daily expenses per person (default: $100)', and 'Number of travelers (default: 1)'. This provides meaningful context that the bare schema lacks.
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 'Calculate total estimated trip cost' with a specific verb ('calculate') and resource ('trip cost'). It distinguishes itself from sibling tools like get_travel_tips or search_flights by focusing on cost calculation rather than information retrieval or search. However, it doesn't explicitly contrast with potential overlapping tools like budget planners.
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. While sibling tools like search_flights and search_hotels are clearly for finding options rather than calculating costs, there's no explicit mention of when this tool is appropriate versus when to use other cost estimation methods or tools. No prerequisites, limitations, or comparison context is provided.
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 what the tool returns ('Dictionary with destination recommendations'), it doesn't describe important behavioral aspects like whether this is a read-only operation, what format the recommendations take, whether there are rate limits, authentication requirements, or how comprehensive the recommendations are. The description is minimal and leaves many behavioral questions unanswered.
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 well-structured with clear sections (purpose, Args, Returns) and uses minimal words to convey essential information. The purpose statement is front-loaded, and each section serves a clear purpose without redundancy. The only minor improvement would be integrating the parameter explanations more naturally rather than as a separate 'Args' section.
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 that there's an output schema (though not shown in the context), the description doesn't need to fully explain return values. However, for a tool with 3 parameters and no annotations, the description provides basic parameter semantics but lacks important context about when to use it versus siblings, behavioral constraints, and operational details. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for the lack of parameter documentation in the schema. It provides meaningful context for all three parameters: 'interests' gets examples like 'beach, culture, adventure, food', 'budget_range' is explained as 'Budget category', and 'season' as 'Preferred travel season'. This adds substantial value beyond what the bare schema provides, though it doesn't fully explain the enum values or default behaviors.
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 with 'Get destination recommendations based on interests and preferences' - a specific verb ('Get') and resource ('destination recommendations'). It doesn't explicitly differentiate from sibling tools like 'search_flights' or 'search_hotels', but the focus on recommendations rather than specific bookings or costs provides some implicit distinction.
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. With sibling tools like 'calculate_trip_cost', 'get_travel_tips', 'search_flights', and 'search_hotels', there's no indication of when this recommendation tool should be selected over those more specific tools or how they might complement each other.
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 mentions that the tool 'Search for available flights' but lacks details on permissions, rate limits, data freshness, or error handling. For a search tool with no annotation coverage, this is a significant gap in transparency, though it doesn't contradict any annotations.
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 appropriately sized and front-loaded with the core purpose, followed by structured Args and Returns sections. Every sentence adds value, such as examples for parameters and return format. It could be slightly more concise by integrating the return info into the main flow, but overall it's efficient and well-organized.
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 complexity (6 parameters, no annotations, but with an output schema), the description is moderately complete. It explains parameters well and notes the return format, but lacks behavioral context like search limitations or integration details. The output schema exists, so it doesn't need to detail return values, but overall completeness is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining each parameter (e.g., 'Origin airport code (e.g., "JFK", "LAX")' and 'Optional return date in YYYY-MM-DD format for round trips'), which clarifies usage beyond the bare schema. However, it doesn't fully cover all nuances, such as format constraints for dates or cabin class implications, keeping it from a perfect 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 tool's purpose as 'Search for available flights between two locations,' which is a specific verb+resource combination. It distinguishes itself from sibling tools like search_hotels and search_destinations by focusing on flights. However, it doesn't explicitly differentiate from calculate_trip_cost, which might overlap in functionality, preventing 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 when to choose search_flights over calculate_trip_cost or get_travel_tips, nor does it specify prerequisites or exclusions. The usage context is implied but not explicit, leaving gaps for an AI agent to infer correctly.
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 states it's a search operation, implying read-only behavior, but doesn't cover important aspects like rate limits, authentication needs, error handling, or pagination. The description adds minimal behavioral context beyond the basic function.
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 well-structured and appropriately sized. It starts with a clear purpose statement, then provides organized parameter documentation, and ends with return information. Every sentence earns its place, with no wasted words or redundancy.
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 complexity of a 6-parameter search tool with no annotations, the description does well by documenting all parameters thoroughly and mentioning the return format. However, it lacks behavioral context like rate limits or error handling. The presence of an output schema (indicated in context signals) means the description doesn't need to detail return values, but could still benefit from more operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics with the 'Args' section that explains each parameter's purpose, format, and defaults. With 0% schema description coverage and 6 parameters, this fully compensates for the schema's lack of descriptions. Examples like 'Paris' for location and format specifications for dates are particularly helpful.
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: 'Search for available hotels in a location.' It specifies the verb ('search') and resource ('hotels'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'search_destinations' or 'search_flights', 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 'search_destinations' or 'search_flights' to help the agent choose appropriately. The only implied usage is for hotel searches, but no context or exclusions are provided.
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:

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

Score Badge

Copy to your README.md:

[![wisnu-mcp MCP server](https://glama.ai/mcp/servers/adrianpdm/wisnu-mcp/badges/score.svg)](https://glama.ai/mcp/servers/adrianpdm/wisnu-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/adrianpdm/wisnu-mcp'

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