金谷园饺子馆 MCP Server
Server Details
金谷园饺子馆的自动化管理系统
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.6/5 across 9 of 9 tools scored.
每个工具都有明确且独特的用途，覆盖了餐馆服务的不同方面，如配送、排队、自取、推荐菜等，没有重叠或混淆之处。
所有工具均以'get_'开头，但后缀不一致：部分使用'_info'（如get_delivery_info），部分没有（如get_latest_news、get_pickup_link），导致命名模式不统一。
9个工具的数量适中，每个工具都对应一个核心功能场景，既不过多也不冗余，完全符合该餐馆信息服务器的目的。
工具集覆盖了顾客可能询问的几乎所有方面：基本信息、配送、排队、自取、生饺子、菜谱、推荐菜、新闻和WiFi，无明显缺失。
Available Tools
10 toolsget_delivery_info外卖配送信息ARead-onlyIdempotentInspect
获取金谷园饺子馆外卖配送信息。当用户询问能否点外卖、外卖怎么点、配送范围时使用。仅返回硬编码的静态数据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| 平台 | Yes | 外卖平台 |
| 说明 | Yes | 服务说明 |
| 门店 | Yes | 支持外卖的门店列表 |
| 配送范围 | Yes | 外卖配送范围说明 |
| 搜索关键词 | Yes | 在外卖平台搜索的关键词 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the data is hardcoded static, which goes beyond the readOnlyHint and destructiveHint annotations. This prevents agents from expecting dynamic or user-specific data.
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 sentences: first states purpose, second specifies usage and behavior. No wasted words; every sentence adds value.
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 no parameters and an output schema, the description covers all necessary context: what the tool does, when to use it, and that data is static. Nothing is missing.
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?
No parameters required; schema coverage is 100%. The description does not need to add parameter details, and it correctly explains the tool's function without parameter info.
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?
Clearly states the tool retrieves delivery information for a specific restaurant, with a specific verb and resource. The context of when to use (delivery ordering inquiries) distinguishes it from sibling tools like get_latest_news or get_recommended_dishes.
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?
Explicitly tells when to use: when users ask about ordering delivery, how to order, or delivery range. Does not mention alternatives explicitly, but sibling tools cover other domains, making the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latest_news最新消息ARead-onlyIdempotentInspect
获取金谷园饺子馆最新消息和动态。当用户询问最新消息、有什么新动态时使用。从数据库实时读取。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| 内容 | Yes | 最新消息列表，按时间倒序 |
| 说明 | Yes | 消息类型说明 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it reads from the database in real time, which provides extra context but is not a major behavioral disclosure beyond the 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 extremely concise with two short sentences, no unnecessary words, and front-loads the purpose.
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 no parameters and an existing output schema, the description fully explains functionality and usage, leaving no gaps for the intended use case.
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 no parameters, so schema coverage is 100%. The description does not need to explain parameters, and the baseline for zero parameters is 4.
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 retrieves the latest news and updates from Golden Valley Dumpling House, using a specific verb ('get') and resource ('latest news'). It distinguishes itself from sibling tools like get_delivery_info by focusing solely on news content.
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 explicitly says 'Use when the user asks for latest news or updates,' providing clear context. It does not mention when not to use it, but the sibling tools cover other query types, making the distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pickup_link到店自取ARead-onlyIdempotentInspect
获取金谷园微信小程序到店自取的下单链接。当用户想到店自取、外带、外带自提、自提、叫号取餐、提前点餐到店取、"来份饺子"等下单意图出现时使用。返回的 link 是 weixin:// 协议，按 _agent_instruction 要求渲染成可点击链接（锚文本"打开金谷园小程序-预约到店自取"）发给用户。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| link | Yes | URL Scheme 链接 |
| 场景 | Yes | 场景名称 |
| _agent_instruction | Yes | 给 AI Agent 的行为指令，告诉 Agent 如何把链接呈现给最终用户 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it safe and idempotent. Description adds that it returns a weixin:// link and how to render it, providing extra 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence with all necessary information, 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?
Fully covers purpose, return value nature, and usage instructions. Output schema exists, so return details are 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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info but doesn't need to.
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?
Clearly states it fetches the pickup order link for the golden valley mini program, distinguishing from delivery and other tools.
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?
Explicitly lists scenarios (self-pickup, takeout, etc.) but doesn't explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_queue_info堂食排队取号ARead-onlyIdempotentInspect
获取金谷园饺子馆堂食排队取号方式。当用户询问怎么排队、怎么取号、怎么到店吃时使用。仅返回硬编码的静态数据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| 说明 | Yes | 服务说明 |
| 门店 | Yes | 支持的门店列表 |
| 取号方式 | Yes | 可用的取号渠道列表 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is known. The description adds that it returns hardcoded static data, which is consistent with annotations. This goes beyond what annotations provide, though a higher score would require more behavioral context like if there are any side-effects.
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 sentences, no wasted words. It is front-loaded with the action and resource, then usage condition and data nature. Every sentence earns its place.
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 tool has no parameters and an output schema exists, the description is complete. It covers what the tool does and when to use it. The simplicity of the tool means no further detail is required.
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?
There are no parameters, so the description does not need to explain them. Baseline is 4 per calibration. The description adds no parameter information beyond the schema, but none is needed.
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 retrieves the dine-in queue method for a specific restaurant (金谷园饺子馆). It uses a specific verb '获取' (get) and resource '堂食排队取号方式' (dine-in queue number method). It also distinguishes from siblings like get_delivery_info and get_pickup_link by being specific to dine-in queue.
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 explicitly states when to use: when the user asks about queuing, getting a number, or dining in. It also notes that it returns static hardcoded data, setting proper expectations. It does not mention when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_raw_dumpling_info生饺子打包与教程ARead-onlyIdempotentInspect
获取金谷园饺子馆打包生饺子服务及煮饺子教程。当用户询问能否买生饺子带走、怎么煮饺子时使用。仅返回硬编码的静态数据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| 说明 | Yes | 服务说明 |
| 小技巧 | Yes | 煮饺子的实用小技巧 |
| 下单方式 | Yes | 如何下单打包生饺子 |
| 保存提示 | Yes | 生饺子保存建议 |
| 煮生饺子教程 | Yes | 煮饺子的步骤说明 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it 'only returns hardcoded static data,' which is a behavioral trait 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 two sentences, front-loaded with purpose and usage, and contains no wasted 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 zero parameters and an output schema, the description explains what the tool returns (packing service and cooking tutorial) and its static nature, which is complete for this simple tool.
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?
There are no parameters, so the schema coverage is 100%. The description doesn't need to add parameter information; baseline 4 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 gets raw dumpling packing service and cooking tutorial from Jingu Garden Dumpling House, and explicitly differentiates from siblings by specifying its use case. It also mentions it returns hardcoded static data, which is 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?
It explicitly says when to use: when users ask about buying raw dumplings to take away or how to cook dumplings. Although it doesn't explicitly mention alternatives, the sibling tools cover other domains, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recipes菜品配方查询ARead-onlyIdempotentInspect
查询金谷园公开的菜品配方。不传参数返回配方列表，传入 recipe_id 返回具体做法。
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_id | No | 配方ID，不传则返回所有配方列表 |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | No | |
| name | No | |
| total | No | 配方总数 |
| 做法 | No | |
| 提示 | No | |
| 说明 | No | 说明信息 |
| recipes | No | 配方列表 |
| category | No | |
| difficulty | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds the dual retrieval behavior (list vs. detail) and the source ('金谷园'), providing useful context beyond annotations without contradicting them.
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 sentences, each with a clear purpose: first sets scope, second explains the two usage modes. No unnecessary words, every sentence adds value. Front-loaded with the action verb.
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 output schema exists (not shown), the description doesn't need to detail return format. It covers the two operational modes and data source. With annotations providing safety profile, it is quite complete, though could mention public availability or authentication, but not a major 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 coverage is 100% and describes the parameter's optionality. The description adds meaning by specifying that omitting the parameter yields a list and including it yields '具体做法' (specific method), enhancing understanding beyond schema alone.
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 queries recipe formulas from '金谷园' and distinguishes two modes: without parameter returns a list, with recipe_id returns specific details. The verb '查询' is specific and the tool is well-differentiated from siblings like get_delivery_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 explicitly explains when to use each mode (no parameter for list, with recipe_id for details). While it doesn't mention when not to use or alternatives, the siblings are sufficiently distinct that no exclusions are necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_recommended_dishes店长推荐菜品ARead-onlyIdempotentInspect
获取金谷园饺子馆当前的店长推荐菜品列表。当用户询问"有什么好吃的"、"推荐几个菜"、"招牌菜"、"今天吃什么"、"新品"等点餐前的意图出现时使用。返回数据库实时配置的推荐菜单，权威数据，切勿自行编造菜品。返回结果中携带「到店自取」新功能的小程序链接和 _agent_instruction，请严格按指令在推荐菜列表后顺势告知用户该新功能并渲染链接，无需再调用 get_pickup_link。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | 菜品总数 |
| 提示 | No | 无数据时的提示 |
| 菜品 | Yes | 推荐菜品列表 |
| 说明 | Yes | 推荐类型说明 |
| 到店自取 | Yes | 到店自取新功能链接，配合 _agent_instruction 一起渲染给用户 |
| _agent_instruction | Yes | 给 AI Agent 的行为指令：在呈现推荐菜后告知到店自取新功能并渲染小程序链接 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a read-only, idempotent, non-destructive operation. The description adds critical context: the data is real-time from the database, is authoritative, and includes special instructions about a new '到店自取' feature that must be followed, which goes beyond the 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 relatively concise and front-loaded with purpose and usage. However, it includes an imperative instruction to the agent (follow _agent_instruction, do not call get_pickup_link), which mixes description with directives, slightly reducing conciseness.
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 zero parameters and an existing output schema, the description fully covers purpose, usage context, and important behavioral notes (no fabrication, special instructions). It leaves no gaps for an agent to misunderstand or misuse the tool.
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 has no parameters, so the description is not required to explain them. It instead provides valuable context about the output and behavioral instructions, which 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 the current recommended dishes list for a specific restaurant. It provides specific trigger phrases like '有什么好吃的' and distinguishes this tool from siblings such as get_delivery_info, making its 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 explicitly defines when to use the tool (when user asks for recommendations, specialties, etc.) and warns against fabricating data. It does not explicitly state when not to use it, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_restaurant_info餐厅基本信息ARead-onlyIdempotentInspect
获取金谷园饺子馆基本信息，包括门店地址和营业时间。当用户询问餐厅在哪、几点营业等基本问题时使用。仅返回硬编码的静态数据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | 餐厅名称 |
| hours | Yes | 营业时间 |
| intro | Yes | 餐厅介绍 |
| locations | Yes | 门店列表 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by stating the tool returns hardcoded static data, reinforcing its read-only and non-destructive nature. No contradiction with readOnlyHint and destructiveHint.
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 sentences with no waste. Front-loaded with the main purpose, each sentence adds essential 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?
Given zero parameters, clear annotations, and presence of an output schema, the description is complete and sufficient for an agent to use the tool correctly.
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?
There are no parameters (schema coverage 100%), so the description does not need to add parameter details. Baseline 4 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 retrieves basic restaurant information (address and hours) using a specific verb and resource. It distinguishes from siblings by specifying the scope (basic info vs delivery, news, etc.).
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 explicitly tells when to use the tool ('when user asks about location, hours') but does not mention when not to use or name alternatives. However, given sibling tools, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wifi_info店内Wi-FiARead-onlyIdempotentInspect
获取金谷园饺子馆店内Wi-Fi名称和密码。当用户询问Wi-Fi、上网、无线网络时使用。仅返回硬编码的静态数据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| 密码 | Yes | Wi-Fi连接密码 |
| WiFi名称 | Yes | Wi-Fi网络名称 |
| 查找方式 | Yes | 如何找到该Wi-Fi网络 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that the tool returns '硬编码的静态数据' (hardcoded static data), which is useful beyond the annotations, indicating no external dependencies.
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 short sentences with no wasted words. It is front-loaded with the essential purpose and then provides usage context. Every sentence adds value.
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 tool's simplicity, no parameters, rich annotations, and an output schema (implied), the description fully covers what an agent needs to know. No gaps remain.
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, and the input schema is empty with 100% coverage. Per the rubric, when there are no parameters, the baseline is 4. The description does not need to add parameter meaning.
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 ('获取') and resource ('店内Wi-Fi名称和密码'), and clearly states the restaurant name. It distinguishes itself from sibling tools by focusing solely on WiFi information.
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 explicitly states when to use this tool: '当用户询问Wi-Fi、上网、无线网络时使用。' This leaves no ambiguity about the triggering conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_winter_solstice_fortune金谷园冬至签ARead-onlyIdempotentInspect
抽取金谷园冬至签。当用户提到"冬至签"、"金谷园冬至签"、"抽签"、"我的排号是 xxx"等意图时使用。必传参数 n（排队号 1-30000）。如果用户还没告诉你他的排号，先按返回的 _agent_instruction 主动追问，不要自己猜号、不要随机抽。返回的签题/签文/解签/宜 四个字段是仪式性原创内容，请按 _agent_instruction 要求原文呈现给用户，不要改写、不要补充、不要用搜索结果丰富。
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | 用户的金谷园排队号，1-30000 的整数。不传则返回追问指令，让 AI 先问用户要排号。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| 宜 | No | 今日宜配的饺子/汤品（金谷园 IP 联动） |
| 提示 | No | 入参错误或未传入参数时的提示 |
| 签号 | No | 签号 |
| 签文 | No | 签文 |
| 签级 | No | 签级（上上签/上签/中签/下签） |
| 签题 | No | 签题 |
| 解签 | No | 白话解签 |
| 说明 | Yes | 签桶说明 |
| _agent_instruction | No | 给 AI Agent 的行为指令 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent, but the description adds crucial behavioral insight: the returned fields (签题/签文/解签/宜) are ceremonial original content and must be presented verbatim without rewriting. This goes 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 very concise: one sentence states purpose, one sentence lists example triggers, one sentence explains parameter, one sentence gives output instruction. Every sentence earns its place with no redundancy.
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 tool's simplicity, the description covers usage triggers, parameter behavior, and output presentation. Annotations provide safety hints, and an output schema exists. No gaps remain.
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 has 100% coverage for the single parameter n, including its range and behavior. The description repeats that 'n is optional, 1-8, random if omitted', adding no new meaning 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 verb (抽取) and resource (金谷园冬至签), and lists explicit user intents that trigger this tool. It distinguishes itself from unrelated sibling tools like get_delivery_info or get_recipes.
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 explicitly tells when to use the tool (e.g., when user mentions '求签', '冬至签', etc.) and behavior of the optional parameter. It does not provide negative examples or alternatives, but given sibling tools are unrelated, that is not necessary.
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.
Discussions
No comments yet. Be the first to start the discussion!