maitabi-mcp-server

Server Quality Checklist

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

Latest release: v0.1.10
Disambiguation5/5
Each tool targets a distinct resource: district groups, bus tour search, general tour search, general tour detail, tour calendar, filters, and bus tour detail. Even though some tools return counts or filter data, their primary purposes are clearly separated by domain and function.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, with verbs limited to list, search, and get. The style is uniform and predictable, with no camelCase or mixed conventions.
Tool Count5/5
With 7 tools, the server is well-scoped for a tour search and information service. It covers two subdomains (bus tours and general tours) without excessive fragmentation or unnecessary duplication.
Completeness4/5
The tool set provides search and detail for both tour types, plus filtering and calendar functionality. A minor gap is the lack of a dedicated filter-listing tool for general tours, but the search tool likely accepts filter criteria, so the core workflow is covered.
Average 3.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 32 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions that the tool returns a JSON string with tours, total count, pagination, sorting, and categories, which is useful. However, it does not explicitly state that the operation is read-only, nor does it disclose any side effects, rate limits, or dependency on the external site's state. For a search tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The purpose is front-loaded, and the return format is stated succinctly. Every word earns its place, and it is appropriately sized for a search tool with a rich schema.
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 14 parameters, a rich schema, and an output schema, the description is minimal but covers the core purpose and return. However, it fails to clarify the distinction from the sibling 'search_tours', leaving an agent potentially selecting the wrong tool. It also does not mention that the search is likely read-only, though that is less critical. The omission of alternative routing makes it incomplete for safe tool selection.
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 provides descriptions for all 14 parameters with 100% coverage, so the baseline is 3. The tool description adds no additional meaning beyond what the schema already documents. It does not clarify parameter interactions, typical usage patterns, or any domain-specific conventions, so it does not elevate above the baseline.
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 verb 'Search' and the resource 'general travel tours and mountain climbing packages on www.maitabi.jp', and it specifies the return format. However, it does not differentiate itself from the sibling tool 'search_tours', which likely covers a different scope (e.g., general tours vs. specific categories). Since an agent could confuse the two, it lacks explicit sibling differentiation.
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_tours' or 'get_tour_detail'. It does not mention selection criteria, exclusions, or typical scenarios. The agent is left to infer usage from the name alone, which is insufficient given the overlapping sibling set.
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 full responsibility for behavioral disclosure. It states that the tool returns a JSON string with specific content, which is a useful behavioral detail, but it does not mention any side effects (though 'fetch' implies read-only), error handling, rate limits, or potential size implications of batch fetching. The description is accurate but incomplete in disclosing behavioral nuances beyond the basic read operation, earning a middling score.
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 exceptionally concise—two sentences with no unnecessary words. It front-loads the core purpose and then enumerates the return contents in a structured manner. Every sentence earns its place, and the structure is clear and scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one well-documented parameter and an output schema is present (indicating the return structure is formally defined), the description covers the essential context: what the tool fetches and what it returns. It does not mention authentication requirements or behavior for invalid course numbers, but these are likely implicit or covered by the output schema. For a simple read tool, this is nearly complete, though a minor addition about error handling would make it fully complete.
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 provides 100% coverage for the single parameter, course_no, including its type, range, and the ability to pass a single integer or list. The description adds no additional semantic information about the parameter itself; it focuses on the output. Since schema coverage is high, the baseline is 3, and the description does not elevate it beyond that.
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 ('Fetch') and the resource ('complete details, itinerary, pricing, and booking information for a general tour'), including the website domain. It differentiates from siblings by specifying 'general tour', which hints at a distinction from get_tour_detail, though it doesn't explicitly name the alternative. The purpose is unambiguous and specific enough for an agent to understand what the tool does.
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 its siblings, such as get_tour_detail or search_general_tours. It does not mention any conditions, exclusions, or alternatives. While the name and 'general tour' phrasing imply it is for general tour details, the lack of explicit direction leaves the agent to infer usage, which is insufficient given the sibling set includes a similarly named tool.
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?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It mentions the return format ('returns a JSON string containing...') which gives insight into the output, but it does not explicitly state that this is a read-only operation, mention auth requirements, rate limits, or side effects. The verb 'Fetch' implies a read operation, but a mutation-minded agent might not be fully assured. This is a moderate disclosure.
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 two sentences with zero fluff. It front-loads the primary action and results, then quickly notes the return type. Every sentence serves a purpose, and the structure is easy to scan.
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?
The tool has one well-documented parameter and an output schema (indicated in signals), so the description need not detail return values exhaustively. It covers the key elements: what the tour detail includes (itinerary, stops, pricing, lodging) and the parameter type. A minor gap is that it does not explicitly mention that batch fetching is supported (though the schema does), but overall it is complete for a simple fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – the 'course_no' parameter is already described in the schema with examples and batch support. The description adds no extra meaning beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
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 verb 'Fetch' and the resource 'detailed information, schedule, pricing, and bus stops for a specific Maitabi mountain bus tour by course_no.' It explicitly identifies the target domain ('Maitabi mountain bus tour') which distinguishes it from 'get_general_tour_detail' and other siblings. The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a course_no, but it does not explicitly state when to choose this over sibling tools like get_general_tour_detail or get_tour_calendar. No alternatives or exclusions are mentioned, so the agent must infer from the 'Maitabi mountain bus' context. This is acceptable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 adds the key behavioral trait that district groups and counts update dynamically based on other selected filters, which is not evident from the schema. This goes beyond a simple fetch description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero fluff. The first sentence immediately states the core purpose, and the second adds the cascading behavior. Information is front-loaded and every word earns its place.
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 existence of an output schema, return format is covered. The description states the purpose and a key behavioral nuance. However, it does not address how this tool relates to search_tours or list_filters, which could leave an agent uncertain about when to call it; still, the name and purpose are clear enough for a fetch-style tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions for all 12 optional parameters. The description adds no additional parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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?
States a specific verb (Fetch) and resource (mountain area/district groups and tour counts) with clear domain context (Maitabi mountain bus tours). However, it does not explicitly differentiate from sibling tools like list_filters or search_tours, relying on the resource name to imply distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions cascading filtering, which implies use in an interactive filtering context, but does not explicitly state when to use this tool versus alternatives or provide exclusions. The 'when to use' is inferred rather than stated.
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?
No annotations are provided, so the description carries full responsibility. It discloses that the tool is a fetch (read-oriented) and that options/counts update dynamically with cascading filters. However, it does not explicitly state that it performs no state changes, nor does it mention any edge cases or side effects. Basic but not rich behavioral context.
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?
Two sentences with zero filler. The main purpose is front-loaded and the cascading behavior is stated concisely without 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?
The output schema exists, so return details are covered there. The description explains the core behavior (fetching options and tour counts, cascading updates) adequately. The only gap is a lack of explicit guidance on when to use this vs. sibling tools, but given the simplicity, it is nearly complete.
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%, and the input schema already documents each parameter with examples and enums. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 applies.
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 specific purpose: fetching filter dropdown options (departure areas, tour styles, mountain lodges) and tour counts for Maitabi bus tours. This distinguishes it from sibling tools like search_tours (which returns tour results) and get_tour_detail (which returns a single tour).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for populating filter UI and notes cascading behavior, but it does not explicitly state when to use this over alternatives (e.g., when not to use search_tours) or provide exclusion criteria. The guidance is merely implicit rather than direct.
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, the description carries the full burden. It discloses that the tool performs a fetch and returns a JSON string with a specific content structure, which is useful. However, it does not explicitly state whether this is a read-only operation, potential side effects, or any authentication/rate-limit requirements. Given the name and 'Fetch', it is likely safe, but not explicitly confirmed.
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 two sentences, front-loaded with the action and resource, and each sentence contributes relevant information. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the existence of an output schema, and complete parameter descriptions in the schema, the description adequately covers the tool's purpose and behavior. It even mentions the return type and contents, which adds completeness beyond what the schema provides.
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?
All parameters (year, month, travel_type) have descriptions in the schema, covering 100% of them. The description adds no additional semantic meaning beyond saying 'for a given year and month', which is already in the schema. This meets the baseline for complete 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 uses a specific verb ('Fetch') and identifies the resource ('monthly departure calendar and tour schedule matrix') and the website (www.maitabi.jp). It clearly distinguishes itself from sibling tools like search_tours or get_tour_detail by focusing on the calendar/matrix for a given year and month.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that the tool is for retrieving a calendar for a specific year/month, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives among the sibling tools, so no clear exclusion or alternative guidance is provided.
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, the description carries the burden. It mentions the return format (JSON string with specific fields) and the site, but does not disclose pagination behavior, result limits, or any constraints beyond the parameters. It fails to mention that search is read-only (which is likely obvious) but also doesn't discuss potential errors or rate limits. This is a moderate disclosure, but the core behavior is indicated.
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?
Two concise sentences that front-load the resource and action. The description is efficient, with no redundant content, and clearly states the return type.
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 100% schema coverage and output schema present, the description is complete for a search tool. It names the domain, the site, and the return content. However, it doesn't specify combination semantics (AND/OR) of filters, which might be valuable, but that's often implied by search filters. So it's adequate.
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 has 100% coverage with descriptive parameter explanations, so the description adds no additional parameter information. The baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches mountain bus tours and lodge packages on a specific site (Maitabi) and returns a JSON string with tour details. This distinguishes it from sibling search_general_tours which likely handles general tours.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for mountain bus tours and lodge packages but does not explicitly contrast with alternatives like search_general_tours or mention when not to use it. It provides clear context that this is for mountain-specific tours, so an agent can infer when to use it, but no explicit exclusions are given.
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:

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

Score Badge

Copy to your README.md:

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

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