tea-planner

by blyatman996

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action or resource: logging, undo, inventory, history, hot recommendation, cold recommendation, add/remove/clear inventory, brewer settings, and feedback tuning. Even the closely related record and review tools are clearly separated by purpose—one logs a drink event, the other records feedback and adjusts brewing parameters.
Naming Consistency4/5
Most tools follow a clear lower_snake_case verb pattern like add_tea, remove_tea, clear_inventory, and set_brewer. Minor deviations exist: inventory and history are noun-style commands rather than verb_noun, and undo_record is a prefixed form, but the overall naming remains readable and predictable.
Tool Count5/5
With 11 tools, the server is well-scoped for a personal tea planning application. Each tool covers a distinct workflow from inventory management and drinking logs to hot/cold recommendations and brew parameter tuning, with no obvious redundancy.
Completeness4/5
The tool surface covers the core lifecycle: add/remove/clear/list inventory, log/undo/history drinking, recommend hot and cold brews, adjust brewer capacity, and record tasting feedback. A minor gap is the lack of a direct tea parameter editing tool, though re-adding teas and review-based tuning mitigate this.
Average 4.3/5 across 11 of 11 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under BSD 3-Clause.
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?
No annotations are provided, so the description must carry the burden. '查看' makes clear this is a read operation, and '最近' implies recency ordering, but the description does not disclose whether results are sorted, how the limit applies, or what happens when there are no records. Basic behavior is transparent, but details are left out.
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?
A single, front-loaded sentence that states the tool's purpose with no filler. It is appropriately sized for a simple read tool and every word contributes meaning.
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?
The tool is simple, has one optional parameter, and an output schema exists, so return details do not need explanation. Still, the description fails to explain the `limit` parameter and gives no explicit usage guidance beyond the obvious purpose, leaving minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single `limit` parameter has 0% schema description coverage and is not mentioned in the tool description. The name and default value are self-explanatory, but the description adds no meaning about how the limit is applied or what range of values is acceptable.
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 ('查看' = view) and a concrete resource ('最近喝茶记录' = recent tea-drinking records), making it clear this is a read-oriented history tool. It is easily distinguishable from siblings like `record` or `inventory`, which imply writing or current stock rather than past records.
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 context for use is implied: call it when you need to see recent tea-drinking logs. However, it does not explicitly name alternatives or state when not to use it, so an agent must infer the boundary against siblings like `record` or `review`.
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 does state that only the most recent record is affected, but it omits critical traits like whether the action is destructive, irreversible, or what happens if no record exists yet. For a mutation tool, this is a significant gap.
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 a single, front-loaded sentence that states the core action and follows with a brief use-case clarification. Every word contributes meaning, and there is no redundancy or irrelevant information.
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?
For a stateless, zero-parameter tool that has an output schema, the description is nearly sufficient. However, because there are no annotations, it would benefit from explaining edge-case behavior (e.g., attempted undo with no records) or explicitly noting irreversible side effects.
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?
The tool accepts zero parameters, so there is no schema detail for the description to clarify. The empty schema already provides complete coverage of the parameter space, making the baseline 4 appropriate.
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 a specific action (撤销/undo) applied to a specific resource (最近一条喝茶记录 / most recent tea-drinking record). The parenthetical '记错了可悔' reinforces the use case, and the tool is unambiguously distinct from siblings like record, history, and inventory-related commands.
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 the tool should be used when a tea-drinking record was made by mistake, but it does not explicitly compare with alternatives such as record or history, nor does it define exclusion conditions. Usage guidance relies on the parenthetical hint rather than a clear statement of when to choose this tool over others.
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 full disclosure burden. It does reveal meaningful side effects (fatigue weighting, inventory rotation) and fuzzy matching, but it does not detail exactly what is modified, whether duplicate records are allowed, or how reversible the action is.
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?
One compact sentence packs the action, purpose, and matching behavior with no filler. The action pattern is front-loaded, making it immediately 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?
For a one-parameter tool with an output schema and low complexity, the description covers the essentials for selection and invocation. It could add a pointer to undo_record for accidental entries, but nothing critical is missing.
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?
The input schema only lists 'name' with no description, and schema coverage is 0%. The description compensates by identifying the parameter as a tea name and noting that fuzzy matching is supported, which adds meaning beyond the schema. It omits format or matching details, but with only one parameter the core meaning is clear.
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 uses a concrete pattern ('我刚喝了XX') to define the tool as recording a tea-drinking event, and clearly states the downstream purpose (fatigue downweighting and inventory rotation). It is distinguishable from siblings like add_tea and undo_record despite not explicitly naming them.
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 the trigger condition (the user has just drunk a tea) and gives clear context for when the tool is relevant. However, it does not explicitly say when not to use it or point to alternatives such as undo_record for correcting mistakes.
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?
With no annotations provided, the description must carry the behavioral burden. The verb 列出 clearly signals a read-only query operation and names what is returned, which is sufficient for a simple list tool. It does not explicitly discuss ordering, pagination, or live-vs-snapshot semantics, but these are minor for this low-complexity operation.
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 one compact sentence that front-loads the action and resource, then adds the only parameter information an agent needs. Every clause contributes; there is no filler.
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?
For a one-parameter list operation with an output schema, the description covers the core behavior and filter values completely. It stops just short of full completeness by not explicitly stating that an omitted category returns all items and by not framing when inventory should be preferred over sibling tools.
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 input schema provides only a bare string with an empty default and no enum, while the tool description supplies the full parameter meaning: category is an optional filter and all ten accepted values are enumerated. This fully compensates for the 0% schema description 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 opens with the explicit verb 列出 and names the exact resource 库存茶品及壶泡参数, making the tool's function unmistakable. This also separates it from mutation siblings like add_tea, remove_tea, and clear_inventory, which clearly imply write operations rather than listing.
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?
No guidance is given about when to choose inventory over siblings such as history, recommend, or coldbrew_recommend, and no exclusions or alternative conditions are stated. The only usage hint is the optional category filter, which is parameter-level guidance rather than tool-selection guidance.
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 the behavioral burden. It usefully discloses default current-time usage, randomness semantics (0=regular, 1=surprise), count limits, and mood options, which is meaningful. However, it does not state whether the recommendation uses inventory data, whether it has side effects, or what constraints apply beyond the parameters.
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 one purpose line plus a tight parameter list with no filler. The primary function is front-loaded, and each bullet adds distinct, useful information.
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 description covers all parameters and the high-level return shape, and an output schema exists to handle return details. It is slightly incomplete because it does not explicitly route between hot-brew recommend and coldbrew_recommend, nor state whether inventory is considered, but it remains highly usable.
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?
Input schema coverage is 0%, but the description compensates fully by documenting all four parameters: datetime_str ISO syntax and fallback, randomness range with default 0.6, count default and max 5, and mood examples. This gives an agent everything needed to form correct arguments.
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 opening line states a specific verb ('推荐') and a concrete resource: what tea to drink today or at a given datetime, plus the exact output shape (400ml 壶泡一泡的完整参数). The '壶泡' detail implicitly differentiates it from the sibling coldbrew_recommend, so an agent can tell them apart.
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?
No explicit when-to-use or when-not-to-use guidance is given, and no sibling alternative such as coldbrew_recommend is named. The '壶泡' wording implies hot-brew usage and the datetime parameter implies current-time behavior, but the choice is left to inference rather than spelled out.
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 behavioral burden. It discloses that built-in teas are reversibly marked as consumed, self-purchased teas are directly deleted, and names use fuzzy matching. It does not mention no-match handling or whether the action is logged, but core safety-relevant behavior is covered.
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 entire description is one compact sentence that front-loads the trigger phrase and packs in operation, conditional behavior, restoration path, and match semantics. There is no filler or redundant restating of the tool name.
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?
For a destructive one-parameter tool with no annotations, it covers the key user-facing differences: reversible built-in consumption, irreversible self-purchased deletion, and fuzzy matching. An output schema exists, so return details are not required; however, ambiguous/no-match outcomes and interaction with undo_record/history are not addressed.
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?
The schema provides only 'name: string' with 0% coverage, so the description must add meaning. The 'XX' template in 'I drank up XX' maps the parameter to a tea name, and 'fuzzy match' explains acceptable input behavior. It could be more explicit about the field name, but the command-template approach is sufficient.
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 states a concrete verb and resource ('remove tea from inventory') and gives a natural trigger phrase ('I drank up XX'). It further distinguishes built-in teas (marked consumed) from self-purchased teas (deleted), making the tool's purpose clear relative to add_tea and clear_inventory.
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 trigger phrase and the parenthetical restoration note ('I bought XX' to restore) communicate when to use remove_tea and suggest add_tea as the inverse. It does not explicitly mention when not to use it or how record/undo_record relate, so it falls short of full guidance.
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?
With no annotations, the description carries the behavioral burden and does so well: it discloses auto-exclusion of matcha/cocoa/tea paste/medicinal tea pills, the default-current-time behavior for datetime_str, and the meaning of randomness and count. It only omits edge-case behaviors such as empty inventory, which is minor for a recommendation tool.
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 front-loaded with a short purpose phrase, then gives outputs, exclusions, and parameter meanings in a tight structured list. No sentence is wasted or redundant with the schema.
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?
For a tool with no required parameters and an output schema, the description covers the essential invocation context: defaults, ranges, output fields, and excluded inputs. Missing behavior like empty-inventory errors is not necessary for correct selection and invocation.
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?
Schema description coverage is 0%, but the description fully compensates by explaining datetime_str's ISO format/default, randomness's 0-1 range/default, and count's max/default. This is exactly the semantic information an agent needs beyond the bare schema fields.
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?
Description states a specific action: recommend cold-brew tea for a 1.6L cold-brew pot at refrigerator temperature, and names concrete outputs (tea amount, cold-brew duration, ready-to-drink time). This clearly separates it from the generic sibling `recommend` by scoping it to cold brewing.
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 intended scenario is explicit: use when the user wants a cold-brew tea recommendation for the 1.6L pot, with automatic exclusion of unsuitable tea forms. It does not explicitly name sibling alternatives or state when to use `recommend` instead, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and does so thoroughly. It discloses that exact-name matches with built-in teas restore original parameters, that new teas get category-default brewing parameters, that 0/-1 means use defaults, and that batch mode does not support explicit parameters.
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 front-loaded with a concrete usage example, followed by concise behavioral notes and a structured parameter list. Every sentence adds useful information, and the format is easy for an agent to parse.
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's complexity—batch mode, defaults, fuzzy categories, restore behavior—the description covers the crucial operational details well. It does not explain every edge case, such as duplicate non-built-in tea names, but the core invocation path is complete and the output schema exists to cover return values.
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?
Schema description coverage is 0%, so the description must fully compensate. It explains name separators, fuzzy category matching with an example, note content examples, and the special semantics of g/temp/minutes/rinse, including batch-mode restrictions. This goes far beyond the bare parameter names in the schema.
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 states a specific verb and resource: adding new tea to inventory, with a natural-language trigger 「我买了XX」. It also clarifies batch addition with examples, which clearly distinguishes this from sibling tools like remove_tea or record.
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 opening examples make the intended invocation context clear: when the user reports buying tea, including batch purchases. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses exactly what gets destroyed, the built-in items are marked removed, self-purchased items are deleted, and history/review tuning is cleared. It also discloses the confirm-before-execute safeguard and the first-call preview behavior, which is strong transparency for a destructive tool.
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 compact and front-loaded: it opens with the scenario, states the full effect, then gives the post-condition and parameter rule. Every sentence earns its place and there is no filler.
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?
For a one-boolean-parameter destructive tool with an output schema available, the description is complete: it defines the action, the scope, the safety mechanism, the preview flow, and the recovery/import path. No critical call-relevant information is missing.
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 schema provides no parameter descriptions (0% coverage), so the description must compensate. It fully explains the single `confirm` parameter: it must be True to actually execute, it prevents accidental triggering, and the first call returns a preview. This is complete semantic 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 clear verb, 清空 (clear), and precisely defines the affected scope: all inventory (built-in and self-purchased), drinking history, and review tuning. This explicitly distinguishes it from the single-item sibling tools like remove_tea and undo_record.
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?
It provides a concrete trigger scenario, 「我搬到了外地」, and explains the intended post-condition: the user can batch-import a new tea list afterward. It does not explicitly name alternatives or exclusions, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses persistence to state.json, automatic adjustment logic, reset semantics, direct parameter precedence over auto-adjustment, and mode-specific behaviors such as prewash ranges and lid settings.
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 long, but justifiably so for 11 parameters with substantial behavior semantics. It is front-loaded with the core purpose, followed by a well-organized parameter list where every line adds necessary decision and invocation information.
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 high complexity, absent schema descriptions, and no annotations, the description covers side effects, defaults, precedence, resets, and all 11 parameter semantics. An output schema exists, so return-value documentation is not required. The only minor unstated edge case is behavior when a name fails fuzzy matching, but this does not undermine overall completeness.
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?
Schema description coverage is 0%, so the description must compensate, and it does comprehensively. Each parameter—name, feedback, mode, reset, g/temp/minutes, hours, prewash, lid, and note—is explained with meaning, defaults, valid ranges, and behavioral effects.
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 opens with a specific verb and resource: 「记录喝感评价，并自动微调该款茶的热泡/冷泡参数」, making it clear this is a review/refinement tool. It also distinguishes itself from siblings by emphasizing automatic parameter adjustment persisted to state.json, rather than just recording.
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 clearly establishes when to use this tool: when actual drinking experience deviates from theoretical parameters due to merchant quality, aging, or storage issues. It provides detailed conditional behavior for different feedback words, but it does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden—and it delivers. It discloses that tea amount scales proportionally, water temperature and time stay unchanged, stored values are always baseline amounts, conversion happens only at display time, and reset restores defaults. This goes well beyond a typical setter 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?
The description is well-structured: purpose and examples first, then storage/default behavior, then a clean parameter list. Every line adds operational value and there is no filler or repetition of schema fields.
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?
The tool is simple and the description covers defaults, scaling semantics, storage normalization, reset behavior, and parameter constraints. Since an output schema exists, explaining return values is unnecessary. No critical calling information is missing.
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?
Schema description coverage is 0%, but the description fully compensates by documenting each parameter's unit, valid range, activation condition ('>=0 才生效'), and reset behavior. An agent can correctly construct calls without any external knowledge.
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 opens with a specific verb and resource ('修改壶具容量') and gives concrete user-phrase examples, making the tool's function unmistakable. It is clearly distinct from all listed siblings, which concern records, inventory, recommendations, and reviews.
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 supplies clear trigger examples ('我的茶壶是500ml' / '冷泡壶换成2L') that tell an agent exactly when to invoke this tool. It does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
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

tea-planner MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![tea-planner MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/blyatman996/Tea-Chay-Advisor/badges/card.svg)](https://glama.ai/mcp/servers/blyatman996/Tea-Chay-Advisor)

Score Badge

Copy to your README.md:

[![tea-planner MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/blyatman996/Tea-Chay-Advisor/badges/score.svg)](https://glama.ai/mcp/servers/blyatman996/Tea-Chay-Advisor)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![tea-planner MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fblyatman996%2FTea-Chay-Advisor%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/blyatman996/Tea-Chay-Advisor)

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/blyatman996/Tea-Chay-Advisor'

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