k402-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Every tool has a clearly distinct purpose, targeting either text processing (classify, embed, extract, generate, rewrite, summarize, read_url, search), Kaspa blockchain data (balance, fee, network, tx status, UTXOs), or session management (open, status). No significant overlap; descriptions clarify any potential confusion.
Naming Consistency4/5
Most tools follow a verb_noun pattern in snake_case (e.g., embed_text, kaspa_balance, open_session). There are minor deviations like 'catalog' (noun used as command) and 'read_url' (verb_noun), but overall the pattern is consistent and readable.
Tool Count4/5
17 tools is slightly above the ideal range but still reasonable for a gateway that combines text AI services and blockchain data. Each tool serves a distinct function, and the count matches the breadth of the server's purpose.
Completeness4/5
The tool set covers a wide range of text operations (classification, embedding, extraction, generation, summarization, semantic search) and essential Kaspa blockchain queries (balance, fees, network status, transactions, UTXOs). Minor gaps like transaction broadcasting or session closure are acceptable for the stated scope.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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 must fully disclose behavioral traits. It mentions the cost (paid, ~$0.001 in KAS) which is helpful, but lacks other critical details such as mutability, idempotency, data retention, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but sacrifices necessary detail. While concise, it omits parameter explanations and usage context, making it minimally effective.
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?
Given two required parameters, no output schema, and no annotations, the description is incomplete. It fails to specify instruction format, supported tones, response shape, or any constraints, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the parameters. It does not mention 'text' or 'instruction' beyond their names, providing no additional semantic value. The agent must guess what constitutes a valid instruction or text limits.
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 rewrites text according to an instruction, with examples like tone, format, and length. This verb+resource combination distinguishes it from sibling tools such as 'extract' or 'generate', which perform different operations.
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 like 'summarize' or 'classify'. The description only states the general purpose and cost, without suggesting contexts, prerequisites, or 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?
Describes the action (run prompt on GPU tiers) and output (returns completion text). With no annotations, it provides basic transparency but omits details like statelessness, logging, or rate limits.
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?
Two sentences with front-loaded action and return value. Concise and efficient, though adding parameter details could improve without harming conciseness.
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?
With 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks parameter explanations, output format details, and usage context relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. Only 'tier' is partially explained with four options; 'prompt', 'system', and 'max_tokens' are not described. Major gaps remain.
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 function: 'Run a prompt on a GPU model tier' and lists the specific tiers with costs. It distinguishes from sibling tools like 'classify' and 'summarize' by focusing on generative completion.
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 like 'classify' or 'extract'. The description implies usage for text generation but does not help the agent choose among siblings.
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 behavior. It mentions 'current' (implying a read-only snapshot) but does not disclose whether the data is cached, how often it updates, or if it requires network access. The return structure is unspecified.
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 very short but includes a cryptic fragment 'Paid (~$0.00015)' that may be confusing or irrelevant. It could be more concise by omitting this or explaining it. The structure is front-loaded but not optimally clear.
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?
Given no output schema and simple tool, the description should explain the return format (e.g., list of buckets, JSON structure). It fails to do so, leaving a gap in completeness for an agent expecting to parse results.
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 zero parameters, the schema coverage is 100%, so the description need not add parameter details. Baseline score of 4 applies as per rules, and the description does not provide additional semantics beyond what the schema declares.
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 the tool provides 'Current Kaspa mainnet feerate buckets' in specific units, which is clear enough. However, the phrase 'Paid (~$0.00015)' is ambiguous and could be confused with a cost rather than a fee estimate, slightly diminishing clarity.
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 offers no guidance on when to use this tool versus siblings like kaspa_balance or kaspa_network. There is no mention of prerequisites, alternatives, or context, leaving the agent without decision 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?
Discloses cost (~$0.0003 in KAS) but no other behavioral traits. No annotations provided, so description bears full burden; missing idempotency, side effects, auth requirements, or error 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?
Two concise sentences covering purpose and cost. No redundant information, front-loaded with key action.
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 main output (UTXO set with scriptPublicKey and covenant_id) and cost, but lacks details on error handling, output format, or pagination. Adequate for a simple tool but has gaps.
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?
Single parameter 'address' is described as a Kaspa mainnet address, adding context beyond the schema. However, no format or validation details provided; schema coverage is 0%.
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?
Clearly states it returns the UTXO set for a Kaspa mainnet address, distinguishing it from siblings like kaspa_balance and kaspa_tx_status. However, lacks a strong action verb like 'Retrieves'.
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 vs. alternatives (e.g., kaspa_balance for balance only, kaspa_tx_status for transaction status). Only notes it is paid, which is not usage guidance.
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. It mentions the max_words constraint and cost, but fails to disclose behavior when both text and url are provided, error conditions, or whether changes are destructive. This is insufficient for a paid tool.
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 and front-loaded, containing only two pieces of information. Every word earns its place, though it could benefit from slightly more detail without losing conciseness.
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?
Given three parameters, no output schema, and no annotations, the description is minimal. It lacks return format, error handling, and nuanced behavior, making it incomplete for fully informed agent usage.
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%, but the description adds meaning by clarifying that the tool can summarize either text or a URL and respects max_words. However, it does not specify mutual exclusivity or precedence rules for the text and url parameters.
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 summarizes text or a public URL, specifying the verb and resource. However, it does not distinguish from sibling tools like 'extract' or 'rewrite', so it lacks sibling differentiation.
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 includes cost information ($0.001 in KAS), which is a usage consideration, but does not provide explicit when-to-use or when-not-to-use guidance compared to 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?
No annotations are provided, so the description carries the burden. It discloses the tool is paid ($0.0003 KAS) and that results are constrained to the label set. However, it does not cover authentication, rate limits, or other behavioral traits like speed or data handling.
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-loading the core action and key constraints. It includes cost information efficiently. Slightly more structured formatting could help, but it is concise and clear.
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 classification tool with no output schema, the description covers the main purpose and key parameters. However, it lacks details on the return format (e.g., single string or array) and any limitations (e.g., maximum text length). This is adequate but not comprehensive.
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?
Although schema coverage is 0%, the description adds value by clarifying that 'multi=true' enables multiple labels and that labels must be between 2 and 32 items. This goes beyond the schema which only provides types and defaults.
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 classifies text into labels, with a constraint to the provided label set. It specifies input range (2-32 labels) and optional multi-label. This distinguishes it from sibling tools like 'extract' or 'summarize' which have different purposes.
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 when to use (for text classification) but does not explicitly mention when not to use or provide alternatives among siblings. No exclusions or context for choosing over other tools.
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 discloses cost and guarantee of schema matching, but does not address error handling, failure modes, or behavior on invalid schema.
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 with no redundant information. It is front-loaded with the core action and constraint.
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?
Given three parameters, no output schema, and a paid tool, the description is too minimal. It does not explain what is returned (beyond 'as JSON'), how to use the instruction parameter, or provide examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains 'text' and 'schema' implicitly via its purpose, but fails to mention the 'instruction' parameter, leaving it undocumented.
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 (extract structured data from text), the key property (JSON guaranteed to match schema), and distinguishes from best-effort extraction. It is specific and differentiates from sibling tools like generate or classify.
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 mentions 'schema-constrained decoding, not best-effort', implying when to use it (when schema compliance is required), but lacks explicit guidance on when not to use it or alternatives among siblings.
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 convey behavioral traits. It discloses that the tool is paid with a specific cost, which is good. However, it does not mention error handling (e.g., what happens if the URL is invalid or the page is inaccessible), rate limits, or other non-obvious behaviors.
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 only two sentences long, with no wasted words. It front-loads the core purpose, then adds the distill option and usage context. Every sentence adds value.
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 2 parameters and no output schema, the description covers the basics: what it does, what it returns, and when to use it. However, it omits details like supported URL schemes, maximum page size, or error scenarios. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage. The description explains the 'distill' parameter ('distill=true adds key-fact bullets') but does not explain the 'url' parameter beyond the tool's general purpose. Since schema coverage is very low, the description should provide more parameter-level detail, especially for the required 'url'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and resource 'public web page', and clearly states the return format (title + clean markdown) and an optional distill mode. It distinguishes from sibling tools by focusing on web page retrieval, though it doesn't explicitly compare to similar tools like 'extract'.
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 a clear usage context: 'Useful when you have no web access of your own.' It also mentions the cost, which helps the agent decide whether to use it. However, it does not specify when not to use it or suggest 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?
No annotations are provided. The description adds cost information (~$0.0003 KAS) and mentions returns scores, but does not disclose other behavioral traits like authentication, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: first states purpose and return type, second adds cost. 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?
Adequate for a simple search tool: explains purpose, return type, and cost. However, it lacks details on the collection parameter, query format, and potential errors. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'top-k' but does not explain what parameters like 'q' (query string) or 'collection' represent, leaving the agent to infer from names alone.
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 performs semantic search on a previously indexed collection, returning top-k matches with scores. It distinguishes from siblings like 'search_index' or 'catalog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the collection must already be indexed but does not explicitly state when to use vs alternatives like 'search_index'. No exclusions or alternative guidance provided.
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 burden for behavioral disclosure. It reveals key traits: the tool is paid, produces 768-dim vectors, uses a specific model (nomic-embed-text), and has a limit of 64 texts. This is substantial transparency for a paid 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 a single sentence containing all critical information: action, limit, model, output dimension, cost. No redundant words or filler. Front-loaded with the action and limit.
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 complexity (paid embedding, output vectors, cost), the description covers the main aspects: model, dimensionality, limit, cost. No output schema exists, but description mentions output dimension. However, it does not explain output format or when to prefer this tool over semantic siblings.
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 0%, so description must compensate. It adds meaning to the single parameter 'texts' by specifying the limit (up to 64 texts) and implying they are strings. However, it omits details like encoding or format requirements. The parameter name is clear, but description adds moderate value 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 embeds texts, with specific verb 'Embed', resource 'texts', and quantitative details (up to 64 texts, 768-dim vectors, nomic-embed-text model). It distinguishes from siblings like classify, extract, etc., which perform different operations.
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 provides usage context (limit of 64 texts, paid costing ~$0.0003) but does not explicitly state when to use this tool versus alternatives such as classify or generate. It implies a dedicated embedding use case but lacks direct comparison or when-not-to-use 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?
The description notes the tool is paid with a specific cost, which is important behavioral disclosure. However, it does not mention other traits like rate limits, idempotency, or data freshness, and no annotations are provided to fill 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 no wasted words: the first states the purpose and outputs, the second adds pricing context. Front-loaded and efficient.
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 no parameters and no output schema, the description adequately explains the return values. It could mention data frequency or pagination, but it's fairly complete for a simple status endpoint.
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 parameters, the baseline is 4. The description adds value by listing the returned metrics, which is sufficient since no input parameters exist.
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 retrieves Kaspa mainnet status with specific fields (DAA score, block count, difficulty, node sync state), distinguishing it from sibling tools like kaspa_balance or kaspa_fee_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, but the tool's purpose is clear enough to infer general usage. No alternatives are mentioned despite sibling tools existing.
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 full burden. It notes 'Free.' which is a behavioral cost disclosure. It does not mention side effects, authentication needs, or error conditions. The tool appears read-only and safe, but transparency could be improved with more detail on 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 extremely concise: two short sentences. The main action is front-loaded, and every word adds value. 'Free.' is a relevant behavioral note. No unnecessary 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 status-check tool with no parameters and no output schema, the description covers the core functionality and return data. It lacks mention of prerequisites (e.g., an active session) or behavior when no session exists, but these are minor omissions for a straightforward tool.
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 no parameters, and the input schema is empty (100% coverage trivially). The description adds value beyond the schema by detailing what is checked and returned. Per guidelines, 0 parameters baseline is 4, and the description fulfills this.
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 explicitly states 'Check the current payment session' and lists the specific data returned (deposit address, deposited/spent/remaining KAS). It clearly distinguishes from sibling tool 'open_session', which creates a session, by focusing on status checking.
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: this tool is for checking the status of an existing payment session. However, no explicit when-to-use, when-not-to-use, or alternatives are given. The presence of sibling 'open_session' hints at the workflow, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the interpretation of mempool absence and the cost. It doesn't mention error cases or limits, but the behavior is fairly 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?
Two sentences, no wasted words. Front-loaded with the core purpose, then adds critical usage nuance and cost information. Very efficient.
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 tool with one parameter and no output schema, the description is reasonably complete: it covers purpose, interpretation, alternative, and cost. Minor omission of status values or error handling, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not elaborate on the txid parameter beyond its name. It doesn't provide format, examples, or constraints, so the agent lacks guidance on how to specify the transaction ID.
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 explicitly states it returns the mempool status of a Kaspa transaction, and clarifies the meaning of absence. It distinguishes itself from siblings like kaspa_utxos and kaspa_balance by its specific function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance: if transaction is absent from mempool, it could be accepted or unknown, and suggests using kaspa_utxos to confirm. Also mentions the cost, aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the operation is paid (~$0.0015 in KAS) and advises on security (keeping collection name secret). This adds useful behavioral context beyond the basic store operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence front-loads the purpose and input format; second adds security and cost. 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?
Lacks details on the replace parameter behavior (whether append or overwrite) and does not describe the return value. With 3 parameters and no annotations, the description is somewhat incomplete for confident 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 description coverage is 0%, so description compensates by explaining the documents parameter structure (id, text, meta) and the collection parameter (named, secret). However, it does not explain the replace parameter.
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 ('Store documents'), specifies the input format (documents with id, text, optional meta), and the purpose (semantic search). It distinguishes itself from sibling tools like search_query, which is used for querying.
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?
Provides clear context: use a secret collection name and mentions cost. While it implies when to use this tool (for indexing) versus search_query (for querying), it does not explicitly state when not to use it or name alternatives.
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?
Implicitly indicates a read-only operation by describing balance query. Adds cost detail (~$0.00015). No annotations provided, so description carries burden but adequately conveys non-destructive 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?
Two sentences, no extraneous text, front-loaded with the core purpose. Each part adds 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 single-parameter tool, the description covers key aspects: network, source, cost. Missing return format is minor given simplicity.
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 'MAINNET' and 'any address' context, clarifying the parameter's scope beyond the schema's minimal definition.
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?
Clearly states it returns the balance of a Kaspa MAINNET address. Differentiates from sibling tools like kaspa_fee_estimate and kaspa_utxos by specifying direct node query without indexer or API key.
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?
Implies usage for querying Kaspa balance. Notes it is paid and direct from node, but does not explicitly state when not to use or suggest alternatives 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?
No annotations provided, so description carries full burden. Clearly states it's free, returns a session key and deposit address, describes deposit confirmation, and notes automatic saving. Could mention session overwrite behavior but covers essential traits.
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?
Three sentences, each adding value: purpose, deposit mechanics, and automatic saving. No wasted words, front-loaded with 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 no parameters or output schema, the description covers purpose, usage, and key behaviors. Lacks info on session expiration or multi-session handling, but adequate for the tool's simplicity.
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; baseline set at 4. Description adds meaning by explaining what the session is and how it functions, compensating for the lack of parameters.
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?
Clearly states the tool opens a prepaid payment session, returns a session key and deposit address. Specific verb 'Open' and resource 'prepaid payment session' distinguish it from sibling tools like 'session_status'.
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?
Tells when to use (to get a deposit address and session key for paid tool calls), includes minimum deposit amount (0.25 KAS) and that the session is saved locally. Does not explicitly exclude other use cases but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds value by stating 'Free' and 'live prices', indicating no cost and real-time data. Does not mention auth or side effects, but for a read-only listing this is adequate.
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 wasted words. Front-loaded with the main action 'List every service'. Highly concise and well-structured.
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?
No output schema, but description explains what is returned (list of services with prices in KAS and USD). Also clarifies it's free and a starting point. Fully complete for a simple catalog 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?
No parameters in input schema, so description cannot add parameter semantics beyond what schema provides. Baseline 4 for 0 params, but description adds context about output content (services, prices in KAS/USD), earning a 5.
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 lists all services with live prices, using specific verb 'List every service'. Distinct from sibling tools that perform different functions like classify, embed, etc.
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 says 'Start here' to discover what's available and costs, providing clear usage context. No explicit when-not-to-use, but the guidance is sufficient for a catalog tool.
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:

[![k402-mcp MCP server](https://glama.ai/mcp/servers/Kali123411/k402-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Kali123411/k402-mcp)

Score Badge

Copy to your README.md:

[![k402-mcp MCP server](https://glama.ai/mcp/servers/Kali123411/k402-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Kali123411/k402-mcp)

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/Kali123411/k402-mcp'

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