The digeguigui (滴个龟龟) server is a comprehensive reptile pet (爬宠) platform focused on species identification, genetics, valuation, and care guidance.
Search Species – Find reptile species by common name, scientific name, nicknames (e.g., "小青"), or group categories (e.g., 蛋龟, 陆龟, 水龟).
Get Species Profile – Retrieve full profiles including taxonomy, care parameters, pricing, aliases, distribution, and conservation status.
Identify Turtle by Photo – Upload a base64-encoded image for AI-powered species identification with confidence scores (≥70% gives a direct conclusion).
Estimate Value – Calculate market value based on species, morph/gene traits, and grade (S/A+/A/B/C, etc.).
Verify Provenance – Authenticate a reptile's identity via anchor ID, returning species info, birth date, and blockchain (Git) hash record.
Genetics Calculator – Run Punnett square calculations from parent genotypes to get offspring probability tables, supporting dominant/recessive/co-dominant/polygenic traits.
Search by Care Traits – Reverse-search species by care requirements such as diet, temperature, size, difficulty, and lifespan.
Health Check / Symptom Diagnosis – Input symptoms (e.g., "浮水歪斜 拒食") to get matched disease diagnoses, causes, treatment plans, and prevention advice.
Database Statistics – View platform-wide coverage stats for species, morphs, genes, prices, and images.
Uses Git commit hashes for tamper-proof provenance verification of reptile bloodlines, allowing users to verify authenticity via anchor IDs.
不是养殖，不是看病，不是交易。是看、是懂、是晒。
一句话：爬宠收藏品的"腕表之家" + "MorphMarket品系图谱" + "血统证书区块链"。
给谁用：
收藏者/鉴赏家（核心用户）—— 追踪品系、展示藏品、学习选育路线
繁育者（内容供给）—— 记录血统、标注选育路线、获取行业认可
爱好者/围观者（流量基石）—— 刷品系展示、学品系知识、看价格趋势
不是什么：
❌ 不是活体交易平台（不碰C2C交易、不抽佣金）
❌ 不是电商/用品商城
❌ 不是养殖教程/医疗求助
❌ 不是贴吧式灌水社区
是什么：
✅ 品系百科：每个品种的品系基因树，带直观的视觉对比
✅ 选育路线：繁育者的配对记录、品系培养路径，像GitHub commit历史
✅ 藏品展示墙：用户上传藏品 → AI自动识别品系特征 → 挂载到品系树对应位置
✅ 价格气象站：历史成交价趋势、品系热度指数（不是交易撮合，是价格参考）
✅ 圈内认可：繁育者认证、品系贡献者声望、年度品系评选
Related MCP server: Sports Trading Card Agent
观赏 ──→ 鉴定 ──→ 研究选育路线 ──→ 展示藏品 ──→ 获得圈内认可
│ │ │ │ │
│ 这是什么品系？ 父母是谁？ 我有这只！ 大佬认证了！
│ 稀有吗？ 能配出什么？ 看品相如何！ 选育路线记入史册！
│ 值多少钱？ 这条路怎么走？ AI帮我分析了！
│
└─── 连「看别人展示」本身就是满足收藏品行业的底层驱动力：
"懂"比"拥有"更让人满足 — 能准确鉴定一只蛇的基因组合，比花钱买下来更有成就感
"晒"比"藏"更快乐 — 藏品要被人看到、被认可，才有完整的价值闭环
"追根溯源"是收藏品的灵魂 — 知道一只龟/蛇的选育路线，就是知道它在品系进化史上的位置
这是整个产品的基石。没有这个，后面的展示和选育都没有锚点。
功能描述：
每个品种（球蟒、豹纹守宫、蛋龟等）的品系基因树
类似GitHub的commit graph — 显示每条选育路线的分支、融合、关键节点
每个节点 = 一个品系特征（表型描述+基因型组合说明+代表性图片）
支持缩放查看：从大类概览到具体品系的基因组合细节
用户价值：
新手：快速建立「品系坐标系」——知道什么稀有什么常见
进阶：研究选育路线，理解基因组合逻辑
资深：查阅完整品系树，发现潜在的选育方向缺口
功能描述：
用户上传爬宠照片
AI分析表型特征（颜色、纹路、体型特征等）
返回推测的品系/基因组合 + 置信度
关联到品系图谱对应位置
用户价值：
小白：拍一只蛇，AI告诉我"这是Pied Ball Python，50%概率含Het Clown"
繁育者：做配对前的基因组合验证
所有用户：给藏品自动打上品系标签
功能描述：
繁育者创建「繁育项目」：记录父母个体的品系+基因型
自动计算后代的基因型概率分布
每次配对结果可以追踪记录
多条选育路线形成分支，展示在品系图谱上
用户价值：
繁育者的血统管理工具（替代Excel）
选育路线公开后获得行业声望
选育成果被挂载到品系图谱，永久署名
功能描述：
用户拍/上传自己的爬宠照片
AI自动鉴定品系 → 挂载到品系图谱对应节点
展示内容包括：照片、品系标签、饲养时长、繁育者信息（如果有）
支持点赞、品系匹配（"这只的品系和你的收藏成对"）
排行榜：按品种、按品系热度、按收藏者声望
用户价值：
收藏者的社交货币 — "我的藏品在品系树上有位置了"
围观者的收藏推荐 — "这个品系好看，我也想收一只"
繁育者的活广告 — "看，我繁育的品系长这样"
功能描述：
收集各品系的历史成交价（来源：用户自行填报 + 爬虫采集公开数据）
展示价格趋势图、品系热度指数
按品系、按年份、按品相等级筛选
用户价值：
买家：知道这个品系现在什么价、什么趋势
卖家：知道自己的藏品该标什么价
收藏者：看自己藏品的"增值曲线"
⚠️ 不做交易撮合，不碰资金流。只做信息透明的价格参考。
功能描述：
用户标注"可上门赏玩"
发布同城爬友聚会/品鉴会
支持线下品相评级活动
用户价值：
繁育者之间当面交换基因
收藏者上手看品系细节
新手亲眼感受品种差异
服务 | 付费方 | 定价 | 说明 |
繁育者认证 | 繁育者 | ¥99/年 | 实名认证 + 专属主页 + 选育路线永久署名 |
品系鉴定深度版 | 所有人 | ¥19.9/次 | AI深度学习鉴定（免费版只给出品类，付费版给基因组合推测） |
繁育项目管理 | 繁育者 | ¥49/月 | 血统记录、配对计算器、后代追踪（替代Excel） |
品系认证/评级 | 繁育者 | 按次 | 线下品鉴活动中的官方品系定级（类似AKC血统证书） |
展示墙Pro | 收藏者 | ¥29/月 | 无限上传、高清原图、自定义展示布局 |
品牌广告 | 爬宠品牌 | 展示广告 | 设备商、饲料商、药店 |
核心逻辑：不为交易收费，为「被看到」「被认可」「被记录」收费。
先从你最熟悉的圈子开始：蛋龟圈（你有经验）+ 球蟒圈（品系体系最成熟）
邀请5-10位圈内繁育者/收藏者内测，帮他们把血统记录迁移到平台
核心价值点是：你在品系图谱上的名字会被永久记录
你先上传自己藏品的照片，完善品系数据
让种子用户的藏品展示形成「示范效应」
不做大量虚假填充，真实内容才是吸引力
「我的藏品在XX品系榜第X位」可生成分享卡片
「你认识这是什么品系吗？」AI鉴定H5页面可朋友圈传播
同城品鉴活动带小程序二维码
小程序：微信小程序原生（复用搭肩空投的开发经验）
H5：同构页面用于朋友圈分享、PC端浏览
API服务：Node.js + better-sqlite3（单机足够，与搭肩空投一致的架构）
性能：SQLite WAL模式 + Redis缓存读热点数据
数据库：SQLite（初期零运维成本，后期可升级为MySQL）
品系识别：调用云端大模型视觉API做表型分析 → 匹配知识图谱中的品系特征
知识图谱：品系特征向量化 + 推理引擎（判断父母基因组合→后代概率）
服务器：现有阿里云服务器（8.138.171.33）即可承载初期流量
域名：digeguigui.com（已注册商标）
文件存储：COS对象云存储（与搭肩空投复用）
独立项目、独立代码仓库、独立数据库
共享：微信登录体系、服务器资源、对象存储
不是搭肩空投的衍生品，是全新垂直领域
📊 数据库全景统计 — 物种/品系/基因/价格/图片覆盖度
| 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 burden. It states the tool shows statistics but does not disclose whether it is read-only, any rate limits, or the nature of the operation. Minimal behavioral disclosure beyond the stated scope.
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 sentence with an emoji, front-loaded with the main purpose. No wasted words; efficient and clear.
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?
No output schema, so description should specify return format. It lists coverage areas but does not describe how results are presented (e.g., JSON with counts, string table). Moderate completeness given zero complexity.
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 (schema coverage 100%), so baseline is 4. The description adds value by listing the specific domains covered, overriding the need for further clarification.
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?
Description clearly states the tool provides a panoramic statistical overview of species, lineages, genes, prices, and image coverage, using a specific verb and resource. It is distinct from sibling tools which focus on specific domains like value estimation or genetics.
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?
No explicit guidance on when to use this tool versus alternatives like search_species or get_species_profile. The description implies a broad overview use, but does not state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
价值预估 — 基础价+品系基因溢价×品级系数
| Name | Required | Description | Default |
|---|---|---|---|
| species_id | Yes | 品种ID | |
| genes | No | 品系基因，逗号分隔，如 albino,hypo | |
| grade | No | 品级: S|A+|A|A-|B+|B|C |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states a formula and does not explain side effects, idempotency, auth requirements, or return behavior. The agent lacks information on whether this is a read operation or what the output looks like.
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 a single concise line with no redundancy. However, it lacks structural elements like sections or bullet points. For a simple tool with a clear formula, this is efficient but could be improved.
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?
The tool has no output schema, and the description does not specify the return format (e.g., a number, currency, range). With three parameters and a formula, the agent needs to know what value to expect. The description is too sparse to be complete.
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% for all three parameters. The description adds a formula that explains how parameters relate, but no additional per-parameter semantics beyond what the schema already provides. 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 explicitly states '价值预估' (value estimation) and provides the formula '基础价+品系基因溢价×品级系数', clearly indicating the tool computes an estimated value based on species, genes, and grade. This is distinct from sibling tools like genetic_calculator or search_by_traits.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or typical scenarios. The formula is given but without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🧬 Punnett基因计算器 — 输入亲本基因型，输出子代概率表。支持显/隐/共显/多基因
| Name | Required | Description | Default |
|---|---|---|---|
| parent1 | Yes | 亲本1基因型，如 "het amel anery" 或 "pastel mojave" | |
| parent2 | Yes | 亲本2基因型 | |
| species | No | 物种名(可选)，用于加载物种基因库。默认: 玉米蛇 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description clarifies it's a read-only calculator producing a table. Does not mention limitations, error handling, or data persistence. Supported inheritance types are disclosed, adding value.
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 sentence with emoji, efficiently communicates purpose and supported features. 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?
No output schema, so description should detail return structure. Only says 'probability table', lacking format or explanation. Missing edge cases, species database behavior, and error handling. Adequate but not fully informative.
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 has 100% coverage with clear descriptions for each parameter. Description adds context on supported inheritance types and mentions optional species for gene database loading, beyond 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?
Description explicitly states function: input parental genotypes, output offspring probability table. Lists supported inheritance types (dominant/recessive/codominant/multiple genes). No sibling genetics tools exist, so no confusion.
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?
Implies use for genetic cross calculation, but lacks explicit guidance on when to use or prerequisites (e.g., valid gene names, format). Since no alternative genetics tools exist, the impact is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取品种完整档案: 分类/饲养参数12维/国内价格/别名/分布/保护等级
| Name | Required | Description | Default |
|---|---|---|---|
| species_id | Yes | 品种ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The action verb '获取' (get) implies a read-only operation, and the description lists the data categories returned. While annotations are absent, the description is sufficiently transparent about the tool being a retrieval with no 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?
Single line in Chinese, front-loads the main purpose, and efficiently enumerates key data categories. Every part is necessary and informative.
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 retrieval tool with no output schema, the description covers the main content areas (classification, parameters, price, etc.). Lacks specification of output format but sufficient for basic understanding.
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% with a single parameter species_id described as '品种ID'. The tool description adds no additional meaning beyond the schema, so baseline score of 3 applies.
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?
Description clearly states the tool retrieves a complete species profile and lists specific content areas (classification, husbandry parameters, price, etc.), making the purpose unambiguous and distinguishing it from siblings like search_species which likely return summaries.
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?
No explicit guidance on when to use this tool vs alternatives like search_species or identify_turtle. The usage context is implied but not stated, leaving the AI to infer without exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🩺 症状诊断 — 输入症状描述(如"浮水歪斜 拒食")，匹配爬宠常见病症，返回病因+治疗方案+预防建议。覆盖龟/蛇/蜥蜴/蛙常见病
| Name | Required | Description | Default |
|---|---|---|---|
| symptoms | Yes | 症状描述，如 "壳软 不爱动" 或 "浮水歪斜,拒食" | |
| category | No | 限制品类: 龟/蛇/蜥蜴/蛙/守宫 (可选) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the basic behavior: input symptoms, output diagnosis with cause, treatment, prevention. However, it does not mention any limitations (e.g., only common diseases, confidence level, error handling for unrecognized symptoms), nor does it state whether the operation is read-only or safe. The transparency is adequate but not comprehensive.
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 a single, efficient sentence that includes the emoji for quick visual scanning, the action (symptom diagnosis), an example input, and the output structure. No unnecessary words; every part serves a 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?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers purpose, input format, output content (cause, treatment, prevention), and species scope. However, it does not mention any constraints like 'common diseases only' or that it's for educational purposes, which would improve completeness.
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 both parameters already described in detail (symptoms with examples, category with species list). The description reinforces these examples but adds no new semantic information beyond what the schema provides. Per guidelines, baseline is 3 when schema coverage is high, and the description does not elevate it.
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 is a symptom diagnosis tool for reptile pets, matching input symptoms to common diseases and returning cause, treatment, and prevention advice. It provides an example symptom and specifies the covered species (turtles, snakes, lizards, frogs), distinguishing it from sibling tools that focus on genetics, identification, or statistics.
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 implicitly tells when to use (when you have symptoms to diagnose) without explicit alternatives or when-not-to-use. Given the clear purpose and distinct sibling tools (e.g., genetics_calculator, identify_turtle), the usage context is clear enough, but it lacks explicit guidance on limitations such as not replacing professional veterinary advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
拍照识龟 — 上传龟类图片base64，AI识别品种+置信度。置信度≥70%直接给结论
| Name | Required | Description | Default |
|---|---|---|---|
| image_base64 | Yes | 图片base64编码字符串 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It reveals that the tool uses AI, returns species and confidence, and has a direct conclusion threshold at 70% confidence. This adds useful context beyond the schema. However, it does not mention error handling, auth requirements, or limitations (e.g., need for clear turtle image).
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—two sentences in Chinese. It front-loads the purpose and immediately states the key behavioral rule (confidence threshold). Every word serves a purpose, with no fluff or redundant information. This is an ideal length for quick comprehension.
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 lack of output schema and annotations, the description does a good job covering the core functionality: it specifies the input format (turtle image base64), the output (species + confidence), and a key behavioral rule (direct conclusion at ≥70%). Missing elements include error handling (e.g., poor image, no turtle detected) and any rate limits, but these are acceptable gaps for a simple tool. The description is fairly complete for its complexity.
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 schema describes the parameter 'image_base64' as a base64 string. The description adds the semantic context that the image should be of a turtle ('龟类图片'), which is critical for correct invocation. With 100% schema coverage, the baseline is 3, and the description provides additional meaning beyond the schema, justifying a 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's purpose: identifying turtle species from an image using AI, with confidence scoring. The verb '拍照识龟' (take photo to identify turtle) and the mention of 'AI识别品种+置信度' specifically convey the action and output. It is distinct from sibling tools like get_species_profile or search_species, which handle different operations.
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 does not provide explicit guidance on when to use this tool versus alternatives, such as 'use get_species_profile for known species details'. The intended use case (image-based identification) is implied, but no when-not-to-use or alternative references are given. The threshold behavior (confidence ≥70%) offers some usage context, but lacks comprehensive guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🔍 按饲养条件反查品种 — 如"新手友好+小型+水栖+25°C以下"
| Name | Required | Description | Default |
|---|---|---|---|
| difficulty | No | 饲养难度 1-5 (1=新手) 上限 | |
| temp_min | No | 最低耐受温度°C | |
| temp_max | No | 最高耐受温度°C | |
| adult_size_cm | No | 成体最大尺寸cm | |
| lifespan_years | No | 最小寿命年 | |
| category | No | 品类: 龟/蛇/蜥蜴/蛙/守宫 | |
| diet | No | 食性关键词: 肉食/杂食/草食/昆虫 | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the general search functionality without disclosing behavioral traits such as result format, pagination, filtering logic (AND/OR), or authentication requirements. For a search tool, these details are important.
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 a single sentence with an example, concise and front-loaded. Every part is essential and there is 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?
With 8 parameters, no output schema, and no annotations, the description is insufficient. It does not explain search semantics (e.g., how parameters are combined), result structure, or limitations. Missing context for an agent to use it correctly without additional assumptions.
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 high (88%). The description adds an example of combining parameters, but does not provide additional meaning beyond what each parameter's schema description already conveys. 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 function: searching species by breeding conditions like 'beginner-friendly, small, aquatic, below 25°C'. This distinguishes it from sibling tools like search_species (name-based) and get_species_profile (by ID).
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 implies use when querying by multiple conditions, but does not explicitly contrast with siblings or specify when not to use it. However, the purpose is clear enough for an agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索爬宠品种 — 支持中文名/拉丁学名/圈内俗称(如"小青""蛋龟")/分组(如"蛋龟""陆龟")
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | 搜索关键词 | |
| group | No | 圈内分组: 蛋龟|陆龟|水龟|闭壳龟|侧颈龟|鳖|箱龟|海龟 | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It does not disclose output format, response structure, or limitations beyond the schema's limit parameter. The description lacks details on pagination, sorting, or error handling.
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 a single, front-loaded sentence with no wasted words. It conveys the core purpose and key capabilities efficiently.
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 (3 optional params, no output schema), the description covers search types and group but omits information about return format, error behavior, or result ordering. It is somewhat complete but lacks finishing details.
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 67%, so baseline is 3. The description adds context for q (supported search types) and group (examples), but fails to mention the limit parameter. It does not fully compensate for the missing schema description.
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 searches for reptile species, listing supported search types (Chinese name, Latin name, common names, group). This distinguishes it from siblings like get_species_profile or identify_turtle.
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 implies usage for searching species but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
扫码验证爬宠身份证 — 输入锚定ID，返回品种/出生时间/Git存证哈希
| Name | Required | Description | Default |
|---|---|---|---|
| anchor_id | Yes | 爬宠身份证锚定ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses what the tool returns (breed, birth time, Git hash) but does not mention side effects, authentication needs, or error conditions. Since no annotations are provided, the description carries the full burden and is only partially transparent.
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 a single, front-loaded sentence that efficiently conveys purpose and return data. 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?
The tool has one parameter and no output schema. The description lists three return items but does not specify their format or structure, leaving some ambiguity about the exact output.
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 schema covers 100% of the parameter with a clear description. The tool description only restates the parameter ('input anchor ID') without adding new semantic information 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's action ('verify pet ID') and specifies the return data (breed, birth time, Git hash). It distinguishes from sibling tools like get_species_profile or identify_turtle, which serve different purposes.
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0db_statsestimate_valuegenetics_calculatorget_species_profilehealth_checkidentify_turtlesearch_by_traitssearch_speciesverify_provenanceEach tool targets a distinct function: statistics, valuation, genetics, species profile, health diagnosis, image identification, trait search, name search, and provenance verification. No overlap in purpose.
All tool names follow a consistent snake_case pattern (e.g., genetics_calculator, search_by_traits) without mixing conventions or styles.
With 9 tools, the server covers a broad range of reptile/pet management tasks without being excessive or inadequate for the domain.
The tool set covers search, identification, health, genetics, valuation, statistics, and provenance. Minor gaps like a species comparison tool are not essential for core functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Structured habitat data and advisory tools for aquariums, marine tanks, terrariums and paludariums.
Real sold prices, history & PSA population for graded Pokémon cards (EN/JP/CN). Knows nicknames.
Source-verified pet food regulations, recalls, nutrient standards and species care data.
Crystal meanings, healing properties, chakra and birthstone lookups for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Gaoshan0971/digeguigui'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
