@thryx/mcp-server

Server Quality Checklist

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

Latest release: v1.5.0
Disambiguation4/5
Most tools have clear, distinct purposes, but thryx_info, thryx_safety_score, and thryx_rug_check all draw from the same token detail endpoint and could be confused. Similarly, thryx_balance and thryx_portfolio overlap somewhat. However, the descriptions are explicit enough that an agent can usually select the right tool.
Naming Consistency4/5
All tools share a consistent 'thryx_' prefix and use snake_case, making the set predictable. The second part mixes nouns (info, balance) and verbs (buy, sell) rather than a strict verb_noun pattern, but this is a minor deviation given the strong prefix consistency.
Tool Count3/5
With 21 tools, the set is in the 'heavy' range. Each tool does cover a distinct aspect (discovery, analysis, trading, referral, stats), but there is some redundancy among the stats and token-detail tools that could be consolidated without much loss.
Completeness4/5
The tool surface covers the core workflow: token discovery, analysis, trading, launching, claiming fees, and referral management. Obvious gaps like transaction history or a list of a creator's launched tokens are missing, but these are workaround-able and do not create dead ends.
Average 3.8/5 across 21 of 21 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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?
With no annotations, the description carries full responsibility for disclosing behavior. It only mentions that the token is algorithm-picked, but does not describe side effects, response format, or any operational characteristics. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no fluff. However, it is somewhat under-informative, so it earns a 4 rather than a 5.
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?
There is no output schema and no annotations, so the description must explain what the agent will receive. It only defines what the token is, not the return structure or any other contextual detail, leaving the agent uncertain about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so baseline is 4. The description adds no parameter-specific information, but none is needed since there is nothing to explain.
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 identifies a specific resource (the featured token of the day) and adds context about the platform algorithm, but it lacks an explicit action verb like 'get' or 'retrieve'. This makes the purpose somewhat vague, though it does distinguish from siblings like trending or recent tokens.
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 such as thryx_recent_tokens or thryx_trending. There are no mentions of contexts, exclusions, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not state that this is a safe read-only operation, nor does it mention any side effects, permissions, or output format. The behavior is implied but not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key information (what is returned and the range options). Every word earns its place, with no filler or 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?
For a simple tool with one parameter and no output schema, the description explains the content and range but does not specify the response structure (e.g., whether traders and creators are separate lists, or how many entries are returned). It is adequate but leaves some ambiguity.
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 coverage is 100% with the 'range' parameter having an enum and description. The tool description repeats the range values but does not add new meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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 returns top traders by volume and top creators by fees, which is a specific resource and metric. It distinguishes itself from siblings like thryx_trending (trending tokens) and thryx_stats_v2 (general stats) by focusing on user leaderboards. The absence of an explicit verb like 'list' or 'get' is a minor deduction.
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 alternatives. It does not mention exclusions or prerequisites. The description implies it is for leaderboard queries but does not differentiate from similar tools such as thryx_trending or thryx_stats_v2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the graduation concept but does not disclose the return format, sorting behavior, or any safety implications. The agent is left without clear information about pagination or how results are ordered.
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 two sentences long, front-loaded with the core purpose. The second sentence adds interpretive context but is concise. Every word serves a purpose, though the phrase 'high-conviction late-stage curve plays' is somewhat redundant.
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 simple list tool with one optional parameter and no output schema, the description provides adequate context explaining what 'graduation' means. It does not explicitly state it returns a list or mention the limit parameter, but the schema compensates. Lacks explicit guidance on output structure or sort order, keeping it at minimum viable.
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 schema covers the single 'limit' parameter fully (description, range, default), so the baseline is 3. The description does not add any parameter-specific information, but the schema is sufficiently self-explanatory.
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 identifies the tool returns tokens closest to graduation, with the specific threshold of 250M THRYX raised. It distinguishes itself from siblings like thryx_trending or thryx_recent_tokens by focusing on graduation, though it lacks an explicit verb like 'list' or 'get'.
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 phrase 'high-conviction late-stage curve plays' implies a use case for users interested in late-stage Curve tokens near migration. However, there is no explicit guidance on when to use this tool over alternatives or any exclusion criteria, leaving the usage context implied rather than stated.
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 the full burden but only states the search criteria; it does not disclose return format, pagination, matching behavior, or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the verb and object, with zero wasted words.
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 no output schema and no annotations; the description should explain what the search returns but does not. This leaves a gap for the agent.
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 schema already documents the 'query' parameter as 'name fragment, symbol, or address' (100% coverage). The description adds no additional parameter meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'search' and resource 'tokens' with scope 'by name, symbol, or address', clearly distinguishing it from sibling tools like thryx_recent_tokens or thryx_trending.
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, or any exclusions. It simply states what it does.
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 present, so the description carries the full burden of behavioral disclosure. It does reveal a key consequence (the referrer earns 5% of protocol fee share), which adds useful context. However, it doesn't disclose whether the operation is reversible, requires specific permissions, or has side effects beyond the fee share, leaving gaps.
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?
Two sentences with zero filler. The description is front-loaded with the action and immediately provides a relevant consequence. Every word 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?
For a simple single-parameter tool, the description covers the core purpose and a consequence, but it lacks usage guidance and doesn't clarify how this relates to sibling tools like thryx_claim_referral. Without annotations or an output schema, more contextual detail would improve completeness.
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 coverage is 100% with a clear description for the referrer parameter ('0x-prefixed 40-char hex'). The tool description adds context that the referrer earns fees, which helps explain the parameter's role, but it doesn't elaborate on format or constraints beyond the schema. This matches the baseline for high schema coverage.
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 action: 'Set a referrer wallet for your account.' This is a specific verb+resource combination. It doesn't explicitly differentiate from siblings like thryx_claim_referral, but the action is distinct enough that a capable agent would understand the purpose.
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 vs alternatives. It doesn't mention prerequisites, exclusions, or call out related tools like thryx_claim_referral. This leaves the agent to infer usage context on its own.
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 carries the full burden. It discloses that the score is computed from liquidity, holder distribution, deployer history, and trading patterns, and that it reads the healthScore field. This adds context but omits details about error handling, rate limits, or data freshness.
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 two concise sentences, front-loading the key output (score range and meaning) and providing relevant computation context. Every sentence earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description sufficiently explains the return value (0–100 scale, higher is safer) and the data source. For a simple one-parameter tool this covers the essential operational context, though it could mention whether the score is an integer or decimal.
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 fully describes the only parameter 'token' as 'Token contract address.' The description adds no additional meaning or format details, matching the baseline for high schema coverage.
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 defines the tool as returning a safety score (0–100) computed from on-chain factors, and explicitly mentions reading the healthScore field from the token detail endpoint. This distinguishes it from siblings like thryx_rug_check by stating the exact data source, though it lacks an explicit action verb like 'retrieve'.
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 about when to use this tool versus alternative safety-related tools such as thryx_rug_check. The description explains what the tool does but not the context or conditions for choosing it.
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 present, so the description carries the full burden. It indicates a read operation by stating 'Live protocol params' and 'Pulled from /api/protocol-params', providing the data source and freshness. However, it does not disclose potential side effects, error behavior, or authentication requirements, which is a moderate gap for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key phrase 'Live protocol params' and efficiently lists specific fields and the API source. Every piece of information is relevant, and there is no fluff.
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 simple, parameterless read-only tool with no output schema, the description covers the essentials: what it returns and where it pulls data from. Missing details like response format or authentication are not critical for this context, but the description could have been more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning by enumerating the output fields (fee, creator fee split, graduation threshold, etc.), helping the agent understand the tool's return content without needing parameter details.
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 identifies the tool's purpose: retrieving live protocol parameters, listing specific fields like fee, creator fee split, and graduation threshold. It distinguishes from sibling tools by focusing on protocol-level data, but lacks an explicit verb such as 'get' or 'retrieve', relying on the tool name and context.
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 thryx_info or thryx_stats_v2. There are no explicit 'use this when' instructions or exclusions, leaving the agent to infer usage from the resource name.
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 disclose behavioral traits. It states it returns tokens with high trading activity, but the phrase 'top conviction signals' is ambiguous and undefined. It does not clarify how conviction is measured, whether rankings refresh, or what fields are returned. This leaves the agent uncertain about the tool's output semantics.
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 two short sentences, front-loading the core purpose and adding a hint of unique value ('top conviction signals'). No wasted words; it is appropriately sized for such a simple tool.
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 low complexity and full schema coverage, the description gives the essential purpose. However, the undefined term 'conviction signals' and the lack of information about the return format (e.g., token names, addresses, metrics) leave the agent guessing about what data it will receive. Without annotations or output schema, more detail would be helpful.
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 fully documents the only parameter 'limit' with a clear description ('How many to return. 1–20, default 10.'). The tool description adds no extra parameter information, but since schema coverage is 100%, baseline 3 applies.
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 resource (tokens) and the criterion (most trading activity in the last 6 hours). This distinguishes it from siblings like thryx_recent_tokens (likely recent listings) and thryx_token_of_day (daily pick) by specifying the time window and activity focus.
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 use for discovering currently active tokens (trending), but provides no explicit guidance on when to choose this over similar tools like thryx_leaderboard or thryx_recent_tokens. No alternatives are named and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the fee calculation but does not mention that claiming is a financial mutation, whether authentication is required, if fees are cleared after claiming, or any side effects or failure cases. 'No body required' only addresses request format, not behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tightly scoped sentence plus a short note: 'Claim accumulated referral fees (5% of protocol fees on trades made by accounts you referred). No body required.' Every clause adds value—purpose, fee formula, and a practical invocation detail—with zero wasted 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 zero-parameter tool with no output schema, the description covers the core purpose and the fee formula, and it mentions the body is not required. However, it lacks context about the claiming process itself, such as whether funds are transferred to the referrer's balance, whether the action is irreversible, or any account prerequisites. This incomplete context limits an agent's ability to predict the outcome and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and per the rubric the baseline is 4. The description adds no parameter-related semantics (there are none), and the 'No body required' note is about the HTTP body, not parameters. It adequately covers the empty 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?
Description clearly states the tool's action: 'Claim accumulated referral fees' with a specific resource and an explanatory formula. It differentiates from sibling 'thryx_claim' by specifying 'referral fees' and providing a 5% fee rate detail.
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?
Usage context is implied by the name and description—you use this when you have referral fees to claim. However, there is no explicit when-to-use vs alternatives, no prerequisites, and no mention of exclusions, though 'No body required' gives a lightweight invocation hint.
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 carries the burden of behavioral disclosure. It does state 'No key required' (an access condition) and lists output fields. However, it does not discuss rate limits, error handling, or confirm read-only semantics beyond the implied 'info' context, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It avoids redundancy and front-loads the core purpose, then lists the specific data fields, all without unnecessary words.
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 low-complexity tool with one well-documented parameter and no output schema, the description covers the main need: what data is returned and that no key is needed. It lacks explicit response structure or error behavior, but the provided field list gives a good sense of the output, making it sufficiently complete for its simplicity.
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 schema already fully describes the single 'token' parameter with 100% coverage. The description adds no further parameter-level detail, so it meets the baseline but earns no extra credit.
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 provides 'Detailed info for a single token' and enumerates the exact fields returned (price, supply, raised, fees, graduation status, V4-native flag, healthScore). This distinguishes it from sibling tools like thryx_safety_score or thryx_rug_check, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when comprehensive token details are needed, but it does not explicitly mention when to avoid this tool or point to alternatives. The only usage guideline is 'No key required', which is more about access than tool selection.
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 carries the transparency burden. It reveals that the data is 'live' and sourced from /api/status, and the listed fields imply a read-only snapshot. However, it omits details like return format, units, error behavior, or any access constraints, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence with no wasted words. It front-loads the core purpose and adds only relevant details (fields and data source), making it an model of 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?
For a simple no-argument status tool, the description covers the essential output categories and the endpoint. It is largely complete, though a sample response shape or units for 'capacity' would increase confidence in what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the empty input schema fully covers 100% of the parameter surface. With no parameters to document, the baseline of 4 applies; there is nothing missing in parameter semantics.
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 identifies a specific resource ('paymaster state') and enumerates its key fields (sponsored ETH balance, THRYX reserves, capacity). It distinguishes itself from sibling stats/info tools by focusing on paymaster-specific state, even without an explicit verb.
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 the many sibling statistics tools like thryx_info, thryx_stats_v2, or thryx_balance. The description implies it is for paymaster state but does not state alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses gasless execution via paymaster, slippage protection, and the need for wallet ETH to cover the trade value while gas is sponsored. This gives an agent awareness of the payment model and potential failure due to insufficient funds. It stops short of describing response format or other failure modes, but covers the most critical behavior.
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 three concise sentences, each contributing essential information: purpose, key features, and prerequisites. The most important action ('Buy a token with ETH') is front-loaded. No filler or redundant phrasing.
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 buy operation with no output schema, the description covers the essentials: what it does, payment/gas model, and required inputs (API key, wallet ETH). It lacks details on return values or transaction confirmation, but given no output schema and the presence of a clear input schema, it is adequately complete for an agent to invoke.
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 coverage is 100%, so the baseline is 3. The description adds context about the amount being the ETH trade value and the need for matching wallet balance, which reinforces the purpose of the 'amount' parameter. It does not add new parameter details beyond what the schema already provides.
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 starts with 'Buy a token with ETH', which clearly states the action and resource. It distinguishes from siblings like thryx_sell by specifying 'buy' and mentioning ETH as the payment asset. The added features (gasless, slippage protection) are secondary but do not dilute the purpose.
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 gives important usage conditions: requires THRYX_API_KEY and enough ETH to cover the trade value, with gas sponsored separately. However, it does not explicitly reference alternatives like thryx_sell or thryx_launch, nor does it state when not to use it. The action is implied by the verb 'buy', but exclusions are absent.
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 carries the full behavioral disclosure burden. It discloses the action (claim), the return format (claimed amount + txHash), and prerequisites (API key and creator status). It adds context about the 70% fee accrual, which is useful. However, it does not mention potential side effects, idempotency, or failure behavior (e.g., no fees to claim), leaving some behavioral gaps.
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 two sentences with no redundant phrasing. It front-loads the primary purpose and immediately gives essential details: fee accrual, return format, and prerequisites. Every sentence earns its place, achieving high conciseness without sacrificing clarity.
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 simple single-parameter schema and no output schema, the description covers the necessary context: what the tool does, who can use it, what is returned, and a key protocol detail (70% fee). It is complete enough for an agent to select and invoke the tool correctly, though it could optionally mention error cases or that claiming may be a one-time action.
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 schema already provides 100% coverage with a clear description for tokenAddress ('The token whose creator fees you want to claim'). The tool description adds context about needing to have launched the token, but does not introduce new parameter-level meaning. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Claim') and resource ('accumulated creator fees for a token you launched'), and clearly distinguishes from sibling 'claim_referral' by specifying creator fees and launching context. It also mentions the return format (claimed amount + txHash), leaving no ambiguity about the tool's purpose.
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 states prerequisites: 'Requires THRYX_API_KEY and creator status' and clarifies the scope ('for a token you launched'). It implies when not to use (when you are not the creator), but does not explicitly name alternatives or exclusion conditions. It provides clear context and usage constraints, though not a direct 'use X instead' statement.
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 carries the full burden. It discloses that gas is paid via paymaster, the tool returns tokenAddress + txHash, and an API key is required. However, it does not mention that launching a token is an irreversible on-chain write, nor any failure modes or rate limits, which are relevant for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. Every sentence adds a distinct piece of information: gasless mechanism, return values, auth requirement, and image constraint. No redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (8 params, no output schema, no annotations), the description covers essential invocation facts: purpose, chain, gas handling, return values, auth, and a key parameter constraint. Optional social fields are self-explanatory and the schema provides URI formats. It stops short of failure/error details but is otherwise sufficient for an agent to invoke correctly.
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 coverage is 50%, so the description must compensate partially. It adds the important external parameter THRYX_API_KEY and restates the image requirement, but it does not clarify the purpose of the optional social/link parameters (twitter, website, telegram) or the 'description' field beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Launch a new token on Base (gasless)', identifying both the verb and resource. It also distinguishes this tool from siblings (e.g., thryx_buy, thryx_claim) by focusing on token creation and explicitly mentioning the return values tokenAddress + txHash.
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: use this to launch a new token on Base with gasless execution. It does not explicitly name alternatives or when-not-to-use scenarios, but the unique action and the prerequisite (THRYX_API_KEY) give adequate usage direction.
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 carries full behavioral burden. It discloses that no key is required and that results are sorted newest-first, which are useful. However, it does not state whether the operation is read-only, describe response contents beyond a list, or mention any rate limits or pagination behavior, leaving notable transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, focused fragments: purpose, auth requirement, and sorting. It is immediately clear and every sentence earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the core aspects: what is returned, the ordering, and access requirements. It is sufficient for basic use, though a slightly richer explanation of what constitutes a 'token' record could make it fully complete.
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 100%, fully defining the optional 'limit' parameter. The description adds no additional parameter-level meaning, so it sits at the baseline of 3 without enhancing or compensating.
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 returns 'Most recently launched tokens' and explicitly notes the ordering 'Sorted newest-first.' This precisely defines the tool's function and differentiates it from siblings like thryx_trending or thryx_graduating, which are not time-based.
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 when you need the newest token launches and adds the practical note 'No key required,' indicating it is a public endpoint. However, it does not explicitly mention alternative tools or situations where a different tool would be more appropriate, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the endpoint reuse and the surfacing of specific fields, but does not explicitly state read-only behavior, error handling, or the output format, which would add transparency.
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 two concise sentences. The first lists the key indicators front-loaded, and the second provides context relative to thryx_info. Every sentence earns its place with no wasted words.
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 simple one-parameter tool with no output schema or annotations, the description is mostly complete: it lists the returned indicators, identifies the endpoint, and differentiates from a sibling. It could specify the return type or read-only nature, but it is adequate for a basic lookup tool.
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 schema already provides 100% coverage for the single 'token' parameter with a clear description. The tool description does not add additional meaning about the parameter beyond confirming it is 'for a token,' so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides rug-risk indicators for a token, listing specific fields (deployer address, graduated status, trade count, anti-sniper window, fee tier). It also distinguishes itself from thryx_info by noting it uses the same endpoint but focuses on rug-check-relevant data.
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 rug-risk assessment by referencing the same endpoint as thryx_info and highlighting rug-check fields. This gives clear context for when to use it, though it does not explicitly mention when not to use other tools like thryx_safety_score.
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 the full burden and does well by disclosing three non-obvious behaviors: gasless via paymaster, dual routing based on token status, and slippage protection. It omits potential details like prerequisites (approvals) or failure modes, but the disclosed traits are meaningful and help the agent set expectations.
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 three short sentences, with the primary action first and supplementary details following. Every sentence delivers distinct information (what, gasless, routing/slippage), with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple sell tool with only three parameters and no output schema, the description provides a solid overview: purpose, execution mechanism, and protection. It does not explain the return value or requirements, but these are either implied or not critical given the tool's simplicity. Slightly more detail on prerequisites would improve completeness.
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 schema already provides descriptions for the required parameters (token address and amount as decimal string), covering 67% of parameters. The description adds no additional parameter semantics, and the optional 'comment' parameter is left undocumented, though its purpose is fairly obvious from the name. This is acceptable but not enhanced.
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 starts with a clear, specific action ('Sell a token for ETH') that immediately distinguishes it from sibling tools like thryx_buy. It also adds context about gasless execution and routing, reinforcing the tool's role without ambiguity.
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 establishes the tool's purpose clearly—selling tokens for ETH—which implies its use case. However, it does not explicitly state when not to use it or name alternative tools (e.g., thryx_buy for purchases), leaving the agent to infer from context. This is clear but lacks explicit exclusions.
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 present, so the description bears the full burden of disclosing behavior. It does not explicitly state that this is a read-only call, but 'stats' and the listed metrics strongly imply a safe query. It adds the data source '/api/stats' but does not mention caching, rate limits, or response format.
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?
Two sentences with no filler. The first enumerates all returned data categories, and the second gives the endpoint. Every word contributes value.
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 simple zero-parameter stats tool, the description covers the core metrics and source endpoint. However, since there is no output schema, it does not describe the response structure (e.g., field names, nesting), which would improve 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 tool has zero parameters, and the input schema is already complete. The description adds no parameter details, which is acceptable; baseline 4 for 0-parameter tools.
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 identifies the tool as returning platform-wide statistics, with a concrete list of metrics (tokens, users, trades, prices, reserves, fees, reward pool). The phrase 'Platform-wide stats' distinguishes this from more specialized sibling tools like thryx_paymaster_stats or thryx_protocol_params.
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 establishes clear context via 'Platform-wide stats', implying this tool is the go-to for global aggregate metrics. It does not explicitly name alternatives or exclusion conditions, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key prerequisite ('Requires THRYX_API_KEY') and a performance characteristic ('Heavier than thryx_balance'). It does not explicitly state read-only behavior, but 'portfolio scan' and the return specification strongly imply it.
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 two sentences, front-loaded with the core purpose, and every sentence adds value: the first defines the tool, the second adds prerequisites and comparative usage. No wasted words.
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 parameterless tool with no output schema, the description covers the essential return content (token holdings, live prices, PnL) and usage context (API key, heavier than balance). It is sufficiently complete, though it could include a note about output format or limits, but these are not critical.
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?
There are zero parameters, so the schema is empty and coverage is effectively 100%. Per the rubric, a baseline of 4 is appropriate since there are no parameter semantics to clarify.
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 identifies the action ('Full portfolio scan') and the resource ('your wallet'), and specifies what it returns ('every token holding with live prices and PnL'). It explicitly distinguishes itself from the sibling tool thryx_balance with 'Heavier than thryx_balance.'
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 usage context: 'call when you need per-token detail' and contrasts with thryx_balance by noting it is 'Heavier' (i.e., more resource-intensive). It also notes the prerequisite API key. While it doesn't explicitly list exclusions, it implies when not to use it (if you only need a simple balance).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool is always available and requires no key, which is useful behavioral context. The tool is inherently read-only, and the overview description implies no side effects, adding meaningful transparency beyond the name.
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 two short sentences, front-loaded with 'Protocol overview' and a list of contents, followed by availability and usage cue. Every word earns its place, with no 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 simple zero-parameter tool without an output schema, the description fully covers what it returns (Diamond address, chain, agent surfaces, doc links), how it behaves (always available, no key), and when to use it (first connection). It is complete for an agent to select and invoke 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?
The tool has zero parameters, so the description needs no parameter details. The baseline of 4 applies, and the description does not add irrelevant param info while still clarifying the tool's purpose.
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 identifies the tool as a protocol overview, specifying the exact content (Diamond address, chain, agent surfaces, doc links). It distinguishes itself from siblings by positioning itself as the starting point for new agents, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'Start here when an agent first connects.' It also notes 'Always available, no key required,' which is a strong usage condition. It does not mention alternatives or when not to use, but the guidance is clear enough for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the requirement for THRYX_API_KEY (auth) and equivalence to GET /api/agent/home, implying a read-only operation. It also mentions the 'recommended next-action' feature, adding context beyond simple balance retrieval. This is good but does not describe error behavior or output format, so not a 5.
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: two sentences, roughly 20 words, front-loaded with the core purpose. Every sentence earns its place, including the API key requirement and the endpoint equivalent. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description is remarkably complete. It specifies the exact outputs (ETH, THRYX, total value, recommended next-action), the prerequisite (API key), and the underlying HTTP method. An agent can confidently select and invoke this tool without further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The baseline for 0 params is 4. The description adds no parameter-specific information, but none is needed. The mention of outputs (ETH, THRYX, total value, next-action) provides some semantic context about what the returned data will contain.
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 what the tool does: it returns the wallet balance including ETH, THRYX, total value, and a recommended next-action. This is a specific verb+resource description that distinguishes it from sibling tools like thryx_portfolio or thryx_info by focusing on the balance and a suggested action.
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 for when to use the tool: when needing wallet balance information. It also implicitly excludes write actions by mentioning it is equivalent to a GET request, but does not explicitly name alternatives or when-not-to-use. The API key requirement is a useful prerequisite, though no explicit 'instead of' guidance is given.
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:

[![thryx-mcp-server MCP server](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/thryx-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/thryx-mcp-server)

Score Badge

Copy to your README.md:

[![thryx-mcp-server MCP server](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/thryx-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/thryx-mcp-server)

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/lordbasilaiassistant-sudo/thryx-mcp-server'

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