x402-keywords
x402-keywords: Extract keywords from text. 🆓 5 free trial calls per signed wallet
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| term | No | ||
| text | No | ||
| input | No | ||
| limit | No | ||
| keyword | No |
x402-keywords: Extract keywords from text. 🆓 5 free trial calls per signed wallet
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| term | No | ||
| text | No | ||
| input | No | ||
| limit | No | ||
| keyword | No |
Changes observed during successful MCP inspections.
Input schema / properties / input / descriptionRemoved value: -"Input to process"Input schema / properties / keyword / descriptionRemoved value: -"Keyword to process"Input schema / properties / limit / descriptionRemoved value: -"Limit to process"Input schema / properties / n / descriptionRemoved value: -"N to process"Input schema / properties / term / descriptionRemoved value: -"Term to process"Input schema / properties / text / descriptionRemoved value: -"Text to process"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one behavioral fact (a free trial quota tied to a signed wallet), which implies pay-per-call and wallet-based auth. But it says nothing about what extraction method is used, what is returned, language support, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short elements, front-loaded with the purpose before the pricing tag. It is compact, but the brevity reflects under-specification rather than disciplined editing — the pricing line occupies space while the parameter contract is entirely absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six undocumented parameters, no annotations, and no output schema, the description does far too little to make the tool operable. It establishes the broad intent but leaves the input contract, return shape, and wallet/payment requirements unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Six parameters (n, term, text, input, limit, keyword) with 0% schema description coverage and no required fields marked. The description adds zero parameter meaning, leaving an agent unable to tell which of the overlapping-looking inputs (text vs input, term vs keyword) to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Extract keywords from text'), which is clear enough to understand the operation. However, it merely restates the tool name and does not distinguish it from near-identical siblings such as x402-keyword-extract, x402-keyword-density, or x402-ngram. Adequate but with a clear differentiation gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of alternatives, and no prerequisites beyond a generic 'signed wallet' note. The '🆓 5 free trial calls' line is pricing, not usage guidance. An agent has no basis for choosing this over the many sibling keyword tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.