Free blind-play night-fishing game over MCP. Deterministic engine, zero LLM calls, save codes.
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 4/5 across 5 of 5 tools scored. Lowest: 3.3/5.
Each tool targets a distinct aspect: manual, new game, gameplay actions, save metadata, and card generation. There is no overlap; even the broad 'play' tool is clearly the single channel for game commands, distinct from the others.
All tools share the 'fishing_' prefix, which creates a strong pattern. However, the suffixes mix conventions: 'play', 'save_info', and 'share_card' are verb_noun, while 'manual' is a noun and 'new_game' is adjective_noun, a minor deviation from a fully consistent verb_noun style.
With 5 tools, the server is well-scoped for a fishing game. It covers instructions, gameplay, lifecycle, metadata, and social features without unnecessary bloat, making the count ideal for the purpose.
The tool set provides complete coverage of the game's core loop: learn via manual, restart with new_game, all actions through play, save metadata via save_info, and sharing through share_card. No obvious gaps exist; the single gameplay channel handles all in-game operations.
fishing_manualBInspect玩法说明与全部指令列表(中文)。 / Game manual and full command list (Chinese).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It only describes content ('manual and command list') but does not disclose that that invocation is read-only, what the return value looks like, or that the content is in Chinese.
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 exceptionally concise, delivering the essential information in two short lines without any redundant words. It is perfectly structured for quick consumption.
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?
Although the tool is simple with no parameters or output schema, the description does not specify the return format or behavior. It notes the content is in Chinese, which is useful, but otherwise lacks sufficient detail for an agent to know what to expect when invoking it.
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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters beyond noting it's a manual, which it does.
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 provides a game manual and full command list, distinguishing it from sibling tools that perform game actions. It lacks an explicit verb, but the resource and purpose are specific.
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?
Usage is implied: an agent needing instructions would call this tool. However, no explicit when-to-use/when-not-to-use guidance or alternatives are mentioned, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fishing_new_gameAInspect重开一局(会覆盖当前进度,必须传 confirm:true 确认)。 / Start over (overwrites progress; requires confirm:true).
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | 可选:32 位整数种子(便于复现)。不填则随机取种。 / Optional 32-bit integer seed for reproducibility; random if omitted. | |
| confirm | Yes | 必须显式为 true 才会重开(防误重开覆盖进度)。 / Must be explicitly true to start over (guards against accidental reset). | |
| player_code | No | 可选:要在哪个存档码上重开(形如 WNF-XXXX-XXXX-XXXX)。不填则发一个新码开新局。 / Optional save code to start over on; omit to get a fresh code and a new game. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses two critical behaviors: that it overwrites progress (destructive side effect) and requires explicit confirmation via confirm:true. This goes beyond the basic schema and provides essential safety information.
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 exceptionally concise, using a single bilingual phrase plus parenthetical to convey the essential information. It is front-loaded with the action "Start over" and wastes no words.
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 simplicity of this reset tool and complete parameter descriptions in the schema, the description plus schema provides adequate context. It could mention the return value or what exactly happens after reset, but the core behavior (overwrites progress, requires confirm) is fully covered.
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%, with all three parameters (seed, confirm, player_code) individually described. The tool description adds no extra parameter-level meaning beyond what the schema already provides, so 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 purpose with a specific verb phrase "Start over" (重开一局) and explicitly notes it overwrites current progress, differentiating it from sibling tools like fishing_play or fishing_save_info.
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 clear context for usage: it overwrites progress and requires confirm:true. This implies it should be used when intentionally discarding current progress. It does not explicitly mention alternatives or when not to use it, but the conditions are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fishing_playAInspect执行钓鱼指令,一切游戏操作走这里(如 cast 5、status、buy basic_worm 3;支持用 ; 叠加最多 8 条)。 / Run a fishing command; the main gameplay channel.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | 引擎指令,如 cast 5 / status / buy basic_worm 3;支持用 ; 叠加最多 8 条。 / A fishing command, e.g. 'cast 5'; up to 8 chained with ';'. | |
| player_code | No | 可选:你的存档码(形如 WNF-XXXX-XXXX-XXXX)。首次玩不填,服务器会发一个并在结果里告诉你,记下它下次续玩报回来即可;不填则每次都是新的临时局。 / Optional save code (e.g. WNF-XXXX-XXXX-XXXX). Omit on first play; the server issues one and returns it—keep it and pass it back next time to resume. |
| Name | Required | Description |
|---|---|---|
| text | Yes | 引擎原样输出文本 / Raw engine output text. |
| events | Yes | 轻量事件摘要(不含概率)。 / Lightweight event summaries (no probabilities). |
| player_code | Yes | 本局对应的存档码(报码续档用;未用存档码模式时为 null)。 / Save code for this session (for resuming; null if not in save-code mode). |
| encyclopedia_count | Yes | 当前图鉴已收录种数(文本无进度时为 null)。 / Encyclopedia count so far (null if not present in text). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses key behavioral details: commands can be chained with ';' up to 8 times, and the player_code parameter behavior is explained (server issues one on first play, omitting it creates a temporary game). This goes beyond what a typical schema would convey.
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 concise, front-loaded with the core action in both Chinese and English, and includes relevant examples plus a key constraint (max 8 chained commands). Every sentence earns its place, with no redundant filler.
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 that an output schema exists, the description doesn't need to explain return values. It covers the tool's purpose, command syntax, chaining rule, and save-code behavior, which is sufficient for an agent to use it correctly. The sibling tools cover manuals and save management, so no additional context is 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?
Schema coverage is 100% and the description largely repeats the schema's parameter documentation (e.g., examples and chaining rule for 'command'). The added value is marginal—it reinforces the chaining limit and save-code instructions, but does not introduce new semantics beyond the schema.
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 executes fishing commands ('Run a fishing command') and identifies it as 'the main gameplay channel,' distinguishing it from siblings like fishing_manual or fishing_share_card. It provides concrete command examples (cast, status, buy), 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 phrase '一切游戏操作走这里' (all game operations go through here) tells the agent when to use this tool for gameplay actions. While it doesn't explicitly mention alternatives like fishing_manual or fishing_new_game, the sibling names and the term 'main gameplay channel' imply that other tools handle non-command tasks (manual, save info, sharing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fishing_save_infoAInspect存档元信息(路径 / schema 版本 / 身份模式 / 进度摘要,不含游戏机密)。 / Save metadata (path, schema version, identity mode, progress); no game secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| player_code | No | 你的存档码(形如 WNF-XXXX-XXXX-XXXX),用来查这个存档的信息。不填就先 fishing_play 玩一竿拿到码,再来查。 / Your save code (e.g. WNF-XXXX-XXXX-XXXX) to inspect this save; play once first if you don't have one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly notes 'no game secrets', adding a behavioral boundary beyond the schema. However, with no annotations, it doesn't state whether it is read-only, what the exact return shape is, or any error cases, leaving some transparency gaps.
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?
Two short bilingual sentences deliver the core purpose and a key usage note without waste. Front-loaded with 'Save metadata' and immediately followed by scoping details.
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 metadata lookup with one optional parameter and no output schema, this description is sufficient: it explains what metadata is included/excluded and the prerequisite. It could mention return format, but that's not essential given the tool's simplicity.
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 100% of the parameter and includes a detailed description (save code format and prerequisite). The tool description adds little beyond this, so the schema carries the explanatory burden; baseline 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 retrieves save metadata with specific components: path, schema version, identity mode, and progress summary. This distinguishes it from siblings like fishing_play (gameplay) and fishing_share_card (sharing), giving a specific verb ('save metadata') and resource scope.
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 actionable guidance: if no player_code, play once first to obtain it. This clarifies a prerequisite and a typical usage flow. It doesn't explicitly contrast with alternatives, but the context is strong enough to imply when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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!