tiangong-mcp

Server Quality Checklist

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

Latest release: v0.1.19
Disambiguation4/5
Most tools have clear, distinct purposes (e.g., forge_agent for creation, refine_agent for updates, quest for bounties). A few pairs like growth_flywheel and growth_campaign could be confused, but descriptions differentiate them well.
Naming Consistency3/5
Tool names are in snake_case but mix verb_noun patterns (forge_agent, check_tribulation) with noun phrases (my_realm, public_growth_report) and single words (quest, sect). While readable, the pattern is inconsistent.
Tool Count3/5
26 tools is on the high side for a single server. Some tools like public_install_command seem trivial and could be merged. However, the broad domain (cultivation, agents, growth, quests) justifies the count without being excessive.
Completeness3/5
Core lifecycle operations for agents (create, refine, publish) and quests are covered. However, missing delete operations for agents/artifacts and no way to view other users' profiles are notable gaps in the coverage.
Average 3.5/5 across 26 of 26 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 36 commits in the last 12 weeks
- Last stable release on June 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It does not disclose whether the tool is read-only or destructive, what side effects occur, or what permissions are needed. The term 'preflight' suggests a check but is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus argument line) with no redundant information. It could benefit from a clearer structure, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits essential behavioral context (side effects, return value nature) and does not explain how the tool fits into the workflow. The agent lacks information to decide when to invoke it.
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 has no description for the parameter (0% coverage), but the description adds context: 'target_contributors: public campaign target contributor count used in recheck commands.' This clarifies the parameter's purpose beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses vague terms like 'direct release runbook' and 'closing the public TianGong growth loop,' which do not clearly specify the tool's action or output. No verb indicating what operation is performed (e.g., check, validate, execute).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its siblings, nor any conditions or prerequisites. The description offers no comparison to other similar tools like public_growth_report or public_install_command.
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?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, has side effects, or requires authentication. The phrase 'based on real PyPI readiness' hints at dynamic computation but lacks clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the tool name. It is concise with no unnecessary words.
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?
For a tool with no required parameters and an output schema, the description might be minimally sufficient, but it lacks context about the output format, potential prerequisites, or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is trivially 100%. The description does not add parameter information because none exist. According to the rubric, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides the 'shortest current install path' based on PyPI readiness, implying an install command. However, it does not explicitly say it outputs a command string, making the purpose somewhat vague.
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 on when to use this tool versus siblings. For example, it is unclear if this should be used after public_launch_preflight or before installation.
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, the description must fully disclose behavior. It fails to mention side effects (e.g., creating a persistent card), required permissions, or any limits. The agent has no indication of what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with minimal waste, using emoji and bilingual summary. However, the structure mixes purpose and parameter lists without clear separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool's description omits integration context (e.g., how this card relates to other tools), prerequisites, or what constitutes a 'flywheel bottleneck'. For a creation tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The inline parameter descriptions add bilingual text and a brief role (e.g., 'target contributors in 72 hours'), but no constraints, examples, or format details. Since schema coverage is 0%, the description partially compensates but remains insufficient for precise understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 'public launch card' from a 'flywheel bottleneck', providing a specific action and resource. However, it doesn't differentiate from sibling tools like 'public_launch_preflight', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives, such as when a campaign is appropriate or prerequisites. No exclusions or context provided.
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?
No annotations are present, and the description provides minimal behavioral insight beyond parameter hints (e.g., '72-hour public campaign target'). It does not disclose side effects, authentication needs, or safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a one-line summary followed by a clear parameter list. It is not overly verbose, though the parameter descriptions could be more concise.
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 description adequately covers parameter semantics but lacks usage context, differentiation from siblings, and behavioral details. Given the presence of an output schema, return values are not required, but overall completeness is moderate.
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?
With 0% schema description coverage, the parameter descriptions in the text add significant meaning, explaining each parameter's role and context (e.g., 'target_contributors: 72-hour public campaign target used in proof URLs'). This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is a 'no-network Growth/Share proof kit and external contributor invite' but does not clearly specify the action (create, generate) or differentiate from siblings like 'growth_campaign' or 'public_growth_report'. The purpose is vague.
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 on when to use this tool versus alternatives. No explicit conditions or exclusions are provided, leaving the agent without direction for appropriate invocation.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that it logs an event, but does not mention whether it is destructive, idempotent, requires authentication, or what happens on duplicates. The behavior beyond the basic action is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes a redundant Chinese-English pair. The args list is clear, but repeating the same information in two languages adds unnecessary length. The structure is adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) which may document return values, but the description does not mention output, errors, prerequisites, or side effects. All parameters are optional with defaults, but the description doesn't explain the implications. Given 5 parameters and a potentially complex event, the description is incomplete.
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 description provides brief explanations for each parameter (e.g., 'route: IssueOps 路由', 'source_url: 公开 GitHub Issue/PR/Discussion URL'), which adds meaning beyond the schema's titles and defaults. Although schema coverage is 0%, the description compensates well. A score of 4 reflects good semantic value, though could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it logs a 'public IssueOps-to-MCP return event' and provides a Chinese explanation. It specifies the action and resource (recording growth referrals). However, it does not explicitly distinguish itself from sibling tools like 'record_share_attribution', which may cause ambiguity.
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 provided on when to use this tool versus alternatives. The description only explains what the tool does, without specifying context, prerequisites, or when not to use it. This leaves the agent without decision-making support.
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?
No annotations are provided, so the description must bear the full burden. It states the tool writes to a ledger ('写入激活账本'), indicating a recording action, but fails to disclose whether it is idempotent, whether it can overwrite, or any permission requirements. The behavioral transparency is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses an emoji and bilingual headers, which may be visually noisy. The parameter list is clear but not extremely concise. It is moderately structured but could be more efficient.
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?
All 7 parameters are described, but there is no explanation of the return value or output schema, despite one existing. The description does not cover edge cases or integration with sibling tools. For a tool with moderate complexity, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides brief explanations for all 7 parameters, including Chinese translations and examples for 'contribution' (forge/refine/publish/infuse/quest/sect). However, it does not specify exact allowed values or format constraints for 'share_url', and the list for 'contribution' appears to be examples rather than a closed set. Given 0% schema coverage, the description adds some meaning but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a public share URL associated with a real TianGong contribution, using the verb 'record' and specifying the resource. However, it does not differentiate from the sibling tool 'record_growth_referral', which could be confused for a similar recording action.
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 explicit guidance on when to use this tool compared to alternatives like 'share_attribution_report' or 'record_growth_referral'. The description implies it's for post-contribution attribution, but no when-not-to or prerequisites are given.
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, the description carries full burden. It indicates a create operation but lacks details on side effects, duplicate handling, permissions, or error behavior. The flavor text does not compensate for this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with thematic and bilingual content, but the purpose is front-loaded. Could be more concise without sacrificing clarity.
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?
Covers parameters adequately but misses behavioral context (side effects, validation) and does not mention output despite an existing output schema. Acceptable but not thorough for a tool with 8 parameters and no annotations.
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?
Since schema coverage is 0%, the description effectively explains all 8 parameters with bilingual labels and hints (e.g., agent_type values). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Forge a new AI Agent' and 'create and register your AI Agent', providing a specific verb and resource. It distinguishes from sibling tools like refine_agent and publish_agent, though it does not explicitly contrast them.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, contexts, or when not to use forge_agent.
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, the description must fully disclose behavior. It mentions setting up installation, MCP config, first artifact, and growth re-entry, but does not explain what side effects occur (e.g., creates resources, modifies user state, requires permissions). The vague phrase 'defaults to env config' hints at environment dependencies but lacks clarity. The tool's behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses emoji and bilingual text, which adds visual clutter and redundancy. It has three short sentences but repeats information. While it is relatively brief, the front-loaded emoji and Chinese phrase may distract or confuse an English-based agent. It could be more concise by using only English and focusing on essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. However, it fails to explain what the artifact_name parameter does or what constitutes a valid name. The tool has only two optional parameters and a simple onboarding purpose, so the description covers the basic function but lacks depth on prerequisites or outcomes.
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?
Schema description coverage is 0%, so the description carries the burden. It defines both parameters (username and artifact_name) with bilingual explanations, noting that username defaults to environment config. This adds meaning beyond the schema's simple titles and default values. However, it does not specify constraints or valid values for artifact_name.
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 states it is a 'first-session onboarding card for new TianGong users' and mentions setup tasks (installation, MCP config, first artifact, growth re-entry). This clearly identifies the tool's purpose as initiating the cultivation process for new users. The verb 'Start Cultivation' is specific and distinct from sibling tools like forge_agent or refine_agent, which focus on later stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for new users ('first-session'), but does not explicitly state when to use this tool versus alternatives. No exclusions or contrasting guidance is provided. Sibling tools cover different onboarding or growth activities, but the description fails to guide an agent on selecting 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It mentions the report is 'public' and derived from a 'local MCP event ledger', implying a read-only operation, but does not explicitly confirm it is non-destructive, state whether authentication is required, or describe any side effects. The agent needs more certainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short sentences and a parameter line. It is front-loaded with the main purpose. However, it could be slightly more structured by separating the overall function from the argument explanation. Still, it is efficient without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with one optional parameter and an output schema exists (external), the description provides the core idea but lacks deeper context. It does not explain what 'public contribution-share proof' means, nor does it mention return value structure or pagination. For a tool with many siblings, more context would help the agent decide when to use it.
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 description adds meaningful context to the single parameter, stating it is an optional 'GitHub username filter'. The schema only provides the title 'Username' and a default. The description clarifies the source (GitHub) and the filtering purpose, which helps the agent correctly use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to summarize public contribution-share proof from the local MCP event ledger. The verb 'summarize' and the resource 'contribution-share proof' provide specific action and object, distinguishing it from related tools like record_share_attribution which likely creates such proof.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention when to choose it over sibling tools like public_proof_pack or other report tools, nor does it specify prerequisites or exclusions. The agent is left to infer usage from the name and brief description.
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?
The description suggests a read-only evaluation (no mention of modifications), but without annotations, it does not explicitly state whether it has side effects, requires permissions, or other behavioral traits. The term 'evaluate' implies non-destructive, but it's not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with an emoji. It includes both Chinese and English, which may aid multilingual agents but introduces slight redundancy. Overall, it's concise without unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name and output schema, the description could provide more context about what constitutes a 'growth flywheel' and how the snapshot is derived. The mention of 'weakest link and next command' adds value but leaves some ambiguity.
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?
No parameters required, and schema coverage is 100% (trivial). Baseline for zero parameters is 4, and the description adds no param information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it evaluates the current real growth loop snapshot, with added context from Chinese about weakest link and next command. However, it does not distinguish from sibling tools like growth_campaign or activation_funnel.
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 explicit guidance on when to use this tool versus alternatives. The description implies a general evaluation use but lacks context-specific recommendations.
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?
No annotations are provided, so the description must disclose behavioral traits. It states it can 'generate' an invite, implying a mutation, but does not clarify idempotency, side effects, or authentication needs. This ambiguity 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual and repeats the same information in Chinese and English, making it longer than necessary. The Args section is helpful but could be integrated more concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (reducing need to describe return values), the description covers purpose, parameters, and optional functionality. It does not mention limitations, but for a simple viewer it is fairly complete.
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?
Schema coverage is 0%, but the description provides clear explanations for both parameters (username defaults to env config; apprentice_username generates invite). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays a cultivator profile including realm, natal artifacts, tribulation history, and progress. However, it does not explicitly differentiate from sibling tools like 'check_tribulation' or 'forge_agent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing personal cultivation data and generating an apprentice invite. No explicit guidance on when to use versus alternatives or when not to use.
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?
No annotations are provided, so the description must fully convey behavioral traits. It lacks details on idempotency, mutability, authorization (e.g., GitHub username requirement), rate limits, or side effects. The bilingual text adds some context but omits critical behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear header and a list of arguments. The bilingual format adds length but serves a dual audience. Every sentence is meaningful and earns its place.
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?
Parameter details are well-covered, and an output schema exists. However, broader context is missing, such as prerequisites (e.g., required realm level), relationship to sibling tools, or error scenarios. The system domain is niche but the description assumes familiarity.
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 providing clear explanations for each parameter, including examples (e.g., 'evidence_key: lineage_users, artifact_downloads, dependent_projects') and constraints (e.g., 'amount must be a positive integer', 'source_url must be an http(s) URL'). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Submit Tribulation Evidence — Record public evidence for high-realm gates.' It uses a specific verb and resource, and the name differentiates it from sibling 'check_tribulation'. However, it does not explicitly contrast with siblings.
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 on when to use this tool versus alternatives like 'check_tribulation'. No prerequisites, context, or exclusions are provided. The user is left to infer usage from the name and description.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, destructive, requires authentication, or any rate limits. The term 'local MCP event ledger' hints at a read operation, but it is not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two lines covering Chinese and English, but the bilingual format may be redundant for a single language environment. Still, it is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown) and the simplicity of the tool (one optional parameter), the description is minimally adequate. However, it lacks context on what an 'activation funnel' is and does not clarify the meaning of 'real local' vs. other scopes.
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 description adds meaning to the only parameter 'username' by clarifying it is an optional GitHub username filter. Since schema description coverage is 0%, the description compensates well by providing context beyond 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 clearly states the tool evaluates real local first-session conversion events using the MCP event ledger. The verb 'Evaluate' and resource 'first-session conversion events' are specific and differentiate it from sibling tools like 'growth_campaign' or 'achievement_card'.
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 on when to use this tool versus alternatives. The description only mentions an optional username filter but does not specify scenarios where activation_funnel is appropriate or not.
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?
No annotations are provided, so the description must fully disclose behavior. It mentions generating data but does not state side effects, authentication needs, or whether it is read-only. The presence of 'generate copyable commands and share war letter' suggests some action, but is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes both Chinese and English, which adds redundancy. It is front-loaded with a summary but could be more concise. Overall adequate length.
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 tool with one parameter and an output schema, the description adequately explains the purpose and parameter. It does not detail output format, but the output schema exists. The tool seems sufficiently specified for an AI agent to use correctly.
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?
With 0% schema description coverage, the description adds value by explaining that the 'username' parameter is a GitHub username and defaults to an environment config variable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (check/inspect) and the resource (tribulation/realm gate). It distinguishes from sibling tools like 'submit_tribulation_evidence' by focusing on inspection rather than submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus others, nor does it mention prerequisites or exclusions.
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?
No annotations are provided, so the description must disclose behavioral traits. It describes the rating calculation but does not state whether the tool creates/modifies data, requires permissions, or has any side effects. The tool name 'infuse_spirit' suggests a mutation, but this is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with bilingual content (Chinese and English), emojis, and redundant formatting. While it is structured with sections, it could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description should cover behavioral context. It explains the rating formula but omits whether the appraisal is saved or returned. Since an output schema exists, the lack of return value description is acceptable, but the behavioral gap remains. For a tool with 9 parameters and 1 required, the description is moderately complete.
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?
Although the input schema has 0% description coverage, the description provides detailed explanations for each parameter (e.g., 'inscription: 📝 铭文（描述清晰度）1-10'). This adds significant meaning beyond the schema's titles and default values, fully compensating for the lack of schema descriptions.
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 'Artifact Appraisal — Rate an artifact across six dimensions' and lists the specific six dimensions (inscription, formation, etc.), which uniquely identifies the tool's purpose and distinguishes it from siblings like 'forge_agent' or 'refine_agent'.
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 explicit guidance on when to use this tool vs. alternatives is provided. The description only explains what the tool does, without mentioning prerequisites, exclusions, or context for use.
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?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or side effects. The tool likely performs a read operation, but this is not stated, leaving the agent to infer safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, brief intro, and bullet points for type options. It is concise but includes bilingual text (Chinese and English) which adds length. Each sentence adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It covers the main functionality and parameter details. However, it omits potential issues like error handling, pagination, or data freshness. For a simple tool with two parameters, it is adequate but not thorough.
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?
Schema description coverage is 0%, but the description compensates well by explaining each value of the 'type' parameter in detail, including ranking criteria and default. The 'top_n' parameter is also briefly described. However, it does not include parameter constraints or formats beyond what is implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for viewing platform-wide rankings ('Celestial Leaderboard — View platform-wide rankings.') and lists specific leaderboard types with ranking criteria. It distinguishes itself from sibling tools (e.g., my_realm, forge_agent) by its unique function of aggregating rankings across the platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing rankings, but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or how it compares to sibling tools. The different types provide some context, but no exclusion criteria or prerequisites are mentioned.
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 full burden. It discloses the tool is read-only (generates a card from existing data), mentions the ethical constraint of not faking data, and describes the output format. However, it does not mention auth requirements, rate limits, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear title, brief explanation, and bullet-style parameter list. The bilingual text adds length but could be trimmed for English-only agents. Overall, it is well-structured and front-loaded with the key action.
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 simplicity (2 optional params, no complex behavior) and the presence of an output schema, the description is largely complete. It covers inputs, outputs, and ethical stance. Missing are error scenarios, rate limits, and explicit read-only indication. Still adequate for most agents.
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?
Schema coverage is 0%, but the description explains both parameters: username is GitHub username (defaults to env config) and theme has allowed values 'celestial' or 'light'. This adds meaning beyond the schema's titles and defaults. The allowed values for theme are explicitly listed, though not as enums in 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 clearly states the tool generates a chat-visible visual achievement card based on real GitHub data, producing Markdown SVG, snapshots, next steps, and sharing text. It also explicitly says it does not fake data. This is specific and distinct from siblings like leaderboard or public_growth_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like check_tribulation or forge_agent. There are no usage conditions, prerequisites, or exclusion criteria mentioned.
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 burden. It indicates the tool is read-only ('view', 'shows'), which is transparent about behavioral traits. However, it does not disclose any potential side effects, authentication needs, or rate limits, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title line, bilingual details, and an Args section. It is not overly verbose, but the bilingual repetition slightly reduces conciseness. Each sentence earns its place, though some redundancy exists.
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 presence of an output schema (implied by context), the description does not need to explain return values. It covers the main functionality and parameters adequately. However, it could mention the format or scope of data (e.g., all artifacts or filtered) for completeness.
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 has one parameter (username) with no schema description (0% coverage). The description compensates by explaining it is a GitHub username and defaults to env config, adding meaningful context beyond the schema. This meets the need for low coverage, scoring above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows artifacts, grades, and local cave status, with specific details like refinement count. It uses strong verbs 'view' and 'show', and the bilingual text ensures clarity. While there are sibling tools like treasure_pavilion, my_vault distinguishes itself by focusing on the cave, forge, and vault status rather than just treasures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing personal artifacts and cave status, but does not explicitly state when to use this tool over alternatives like forge_agent or treasure_pavilion. No guidance on prerequisites or exclusions is provided, relying on the agent to infer from the purpose.
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 burden. It discloses the side effect of `record_snapshot` (appends to ledger), but lacks details on permissions, rate limits, or idempotency. The behavioral disclosure is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a one-line purpose followed by parameter explanations. Every sentence adds value with no redundancy.
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?
An output schema exists but is not shown. The description omits details about what the comparison returns, how 'public GitHub traction' is defined, or the nature of the 'local MCP growth ledger.' Given the high sibling count and no annotations, more context would help.
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?
Schema coverage is 0%, so the description must explain parameters. It does so effectively: `record_snapshot` appends the GitHub snapshot, `target_contributors` tracks a campaign goal. This adds meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'compare real GitHub public traction with the local MCP growth ledger.' This specific verb+resource combination distinguishes it from sibling tools like 'achievement_card' or 'activation_funnel', which focus on different areas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing GitHub traction with a local ledger, but provides no explicit guidance on when to use this tool versus alternatives. With 25 sibling tools, clear usage context is lacking.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that changes are recorded but does not mention side effects, idempotency, permissions, or whether previous versions are overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with a clear structure using an English explanation and a bilingual Args list. The poetic lines add some verbosity but do not detract significantly. It is front-loaded with the main purpose.
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 description covers purpose and parameters adequately, and an output schema exists (so return value details are not needed). However, due to the lack of annotations, more behavioral context (e.g., side effects, safety) is needed for a mutation tool.
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 has 0% description coverage, but the description's Args section adds meaningful context for all three parameters: agent_id (source from forge_agent), changes (description of changes), refiner (who refined, defaults to creator). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'refine' or 'optimize' and the resource 'existing AI Agent'. It distinguishes from sibling tools like forge_agent (creation) by specifying it's for improvements. The poetic lines reinforce the concept of refinement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for improving existing agents, and the Args section clarifies key parameters. However, it lacks explicit guidance on when to use this tool vs alternatives (e.g., forge_agent for new agents) 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions summon modifies local vault but lacks detail on side effects (e.g., what is destroyed, authentication needs, rate limits). No mention of behavior beyond action descriptions.
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?
Well-structured with sections, emoji, examples. Front-loaded purpose and action types. Every sentence adds value, no fluff. Efficient despite length.
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?
Covers all actions, parameters, and search syntax. Output schema exists so return values not needed. Lacks error handling or edge cases, but sufficient for typical use.
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?
Schema coverage 0%, but description explains each parameter in detail: action with allowed values, query with search syntax, artifact_name with required conditions. Adds significant meaning beyond schema defaults.
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 clearly states the tool is for searching, summoning, and exploring community artifacts. Uses specific verbs (search, summon, lineage) and resource (community artifacts). Distinguished from sibling tools like forge_agent or refine_agent.
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?
Explicitly describes action types and when to use each (search default, summon for pulling, lineage for exploring relationships). Provides search query syntax and examples. Does not explicitly mention alternatives or when not to use, but context is clear.
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 carries full disclosure burden. It states the outcome: rewarding the refiner if approved ('发放灵力奖励'). It also implies the action is destructive (changing state) and requires publisher authorization. However, it does not describe error conditions, rate limits, or what happens on rejection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains both Chinese and English versions with some redundancy (e.g., both 'Verify Refinement — Review and approve submitted refinement solutions.' and the Chinese equivalent). The 'Args' section is well-structured, but repeated information reduces conciseness.
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 5 parameters, zero schema descriptions, and no annotations, the description covers the core functionality, parameters, authentication constraint, and the reward side-effect. The presence of an output schema partially mitigates the need to describe return values. However, it lacks guidance on error handling or rejection behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Args' section provides brief natural-language meanings for each parameter (e.g., 'quest_issue_number: 淬炼令 Issue 编号'). This adds context beyond the schema, but it lacks details on constraints (e.g., valid values, formats) and some default behaviors are mentioned only for 'feedback' and 'reviewer'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('verify', 'review and approve'), the resource ('refinement solutions' / '淬炼成果'), and the role constraint ('发布者审查'). It distinguishes from siblings like 'refine_agent' (for submission) and 'submit_tribulation_evidence' (for evidence submission).
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 explicitly mentions that the reviewer must be the publisher ('需与发布者一致'), providing a clear prerequisite. It implies when to use (after refinement submission) but does not explicitly contrast with siblings or state when not to use. However, the auth condition is a strong guideline.
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 provided, so description carries full burden. It describes what each action does but does not mention side effects, permissions, or consequences of posting/claiming/submitting quests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with action headers and parameter lists. It is slightly lengthy due to bilingual text, but the organization aids readability.
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 multi-action tool with 8 parameters and no required ones, the description covers all actions and parameter roles adequately. It could mention return values or output schema details, but is otherwise complete.
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?
With 0% schema coverage, the description adds significant value by explaining each parameter's purpose per action (e.g., 'artifact_name' required for post, 'quest_issue_number' for claim/submit). This compensates for the sparse 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 clearly states the tool as a 'Quest Board' with specific actions: browse, post, claim, submit. It distinguishes from sibling tools by focusing on refinement quests.
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 explains when to use each action via the 'action' parameter and lists required/optional parameters per action. However, it does not explicitly state when not to use the tool or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions key behaviors like cooldowns, realm requirements, and management restrictions, but lacks details on side effects (e.g., data changes, logging), error handling, or idempotency. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the complexity, using a structured list of actions and parameters. It is front-loaded with a title and overview. However, it is somewhat verbose due to bilingual (Chinese and English) content and emoji, which could be trimmed without losing clarity.
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 description explains all actions and parameters well, but does not cover return values or output schema (though an output schema exists). It also lacks error scenarios or what happens if prerequisites are not met. For a multi-action tool with complex logic, this leaves some gaps in 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% (no descriptions in input schema properties). The description compensates fully by explaining each parameter's purpose and when it's required: action options, sect_name for info/create/join, motto for create, target_user and manage_action for manage, username for operator identity, and top_n for leaderboard count. All seven parameters are clearly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool handles a 'Sect System' with explicit actions: 'Create, join, manage, and view cultivation sects.' It distinguishes from sibling tools like 'leaderboard' (which might be a separate tool) by showing that leaderboard is an action within this tool, and other cultivation tools are different. The purpose is specific and unambiguous.
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 provides detailed usage guidance for each action, including prerequisites (e.g., 'create requires at least 结丹期 realm'), cooldown ('leave has 7-day cooldown'), and role restrictions (e.g., only sect leader can transfer). However, it does not explicitly contrast with alternatives like the standalone 'leaderboard' tool, leaving some ambiguity about when to use this tool's leaderboard action vs. the sibling tool.
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 bears full transparency burden. It explains the three modes (list/show/export) and covers parameter effects: output_dir required for export, force overwrites. However, it omits details like permissions, rate limits, or side effects on existing files.
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 extremely concise: a one-line purpose statement followed by a compact args listing. Every sentence adds value without redundancy, and the critical action modes are front-loaded.
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 output schema exists, return value explanation is unnecessary. The description covers all parameters, modes, and constraints (e.g., output_dir required for export). Minor omission: could clarify that 'list' doesn't need skill_name, but it's implied.
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 documents all 4 parameters: action (valid values), skill_name (association with show/export), output_dir (required for export), force (overwrite behavior). This adds essential meaning beyond the schema's default values and titles.
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 it operates on portable Agent Skill bundles with specific verbs: list, show, or export. This distinguishes it from sibling tools like forge_agent which create agents, making the purpose distinct and unambiguous.
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 provided on when to use this tool versus alternatives. The description simply lists actions without context about appropriate scenarios or exclusions, which is insufficient for an AI agent to decide between sibling tools.
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 full burden. It discloses the mutation behavior (uploading from forge/, AI review, becoming permanent) and the two parameters. It does not mention destructive actions, auth needs, or rate limits, but the lifecycle is sufficiently transparent.
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 concise, front-loaded with an emoji and bilingual header, uses a clear bullet list for arguments, and every sentence adds value without redundancy.
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 2 parameters, no annotations, and an output schema, the description covers purpose, usage flow, parameter meanings, and outcome (transient to permanent via review). It is complete and self-contained.
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?
Given 0% schema coverage, the description fully explains both parameters: artifact_name is the folder name under forge/, and is_anonymous indicates anonymous upload (default real name). This adds significant meaning beyond the bare 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 clearly states the verb 'publish' and the resource 'artifact to TianGong community'. It explains the process of uploading from forge/ and transitioning from transient to permanent artifact after AI review, which distinguishes it from sibling tools like forge_agent or refine_agent.
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 provides clear context on when to use the tool (to publish an artifact to the community) and outlines the flow (upload, review, permanent status). It does not explicitly state when not to use or alternatives, but the process is well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![TianGong MCP server](https://glama.ai/mcp/servers/JinNing6/TianGong/badges/card.svg)](https://glama.ai/mcp/servers/JinNing6/TianGong)

Score Badge

Copy to your README.md:

[![TianGong MCP server](https://glama.ai/mcp/servers/JinNing6/TianGong/badges/score.svg)](https://glama.ai/mcp/servers/JinNing6/TianGong)

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/JinNing6/TianGong'

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