@true402.dev/mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct operation: address safety, deployer reputation, web checks, token analysis, on-chain monitoring, and LLM inference. There is no functional overlap between any two tools.
Naming Consistency4/5
Most tools use a descriptive verb_noun pattern (e.g., address_safety, token_report). The exception is 'chat', which breaks the pattern but is still clear and functional.
Tool Count5/5
14 tools is well-scoped for a server covering blockchain safety, web diagnostics, and LLM services. Each tool addresses a specific need without unnecessary redundancy.
Completeness5/5
The set covers the full lifecycle of its domain: individual checks (address, token, deployer), aggregated reports (token_report), on-chain monitoring (new_pairs, liquidity_pulls, whale_swaps), web analysis (link_preview, seo_audit, headers_check, robots_check), and LLM capabilities (chat, list_models). No obvious gaps.
Average 4.2/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on June 28, 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses payment requirement and wallet setup, but does not mention rate limits, error handling, or consequences of insufficient funds. The description partially covers behavior but leaves 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, front-loaded with the primary action, and no wasted words. Every sentence adds necessary information about the service and prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 required), no output schema, and no annotations, the description is minimal. It covers the payment aspect but lacks details on model availability, response format, or error scenarios, making it incomplete for a transactional 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?
Schema coverage is 100% with detailed descriptions for each parameter (model, messages, max_tokens). The description adds no extra semantics beyond what the schema already provides, earning the baseline score.
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 sends a chat completion request to an LLM via a specific paid service (true402). The verb 'send' and resource 'chat completion request' are explicit, and the service detail distinguishes it from sibling tools.
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 the paid nature and wallet requirement, providing context on when to use it (if funded). However, it lacks explicit guidance on when not to use it or alternatives, leaving the AI to infer from sibling tool names.
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 fully discloses behavior: it monitors burn events, returns pool/token/amounts, is a paid service (402 for unpaid), and requires a funded wallet. This is transparent about cost and error condition.
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 three sentences, front-loaded with core purpose and parameter list, then output and payment info. It is concise and well-structured, though could separate output format more clearly.
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 output schema and 4 parameters, the description covers purpose, parameters, output fields, cross-reference, and payment model. It lacks return format details but is sufficient for an agent to use effectively.
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 covers all 4 parameters with descriptions, so baseline is 3. The description adds extra context by explaining 'since' as block number, 'limit' as max 1–200 default 50, 'dex' as filter, and 'minQuote' as threshold, enhancing usability beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides liquidity-pull/rug alerts on Base by monitoring burn events on recently-launched DEX pools. It specifies the output includes pool, token, and WETH/USDC amounts, which distinguishes it from sibling tools like 'new_pairs' or 'token_safety', though it could explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting rug pulls via burn events, but lacks explicit guidance on when to use versus alternatives or when not to use. It mentions cross-checking with token safety, but no exclusions or context for non-use.
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 discloses key behaviors: returns formatted content, has a flat pricing model, and a 402 error for unpaid requests. However, it lacks details on error handling for invalid URLs, timeouts, or content size limits, which would improve 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 very concise: two sentences that cover functionality and payment model, plus a parenthetical note. Each sentence contributes value, and the key information is front-loaded. 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?
Given one parameter, no output schema, and no annotations, the description adequately covers the tool's core functionality and payment model. It could be improved by mentioning error cases beyond 402 and content limitations, but overall it is fairly complete for a simple extraction 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 only parameter 'url' is already described in the input schema as 'The page URL to extract (http/https)'. The tool description does not add additional semantics beyond this, and with 100% schema coverage, a 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 action (fetch), resource (web page), and output (clean readable text, light markdown, title/description/links). It distinguishes from sibling tools like link_preview and robots_check by specifying the complete extraction of text and metadata.
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 specifies the HTTP method (POST), the required parameter (url), and importantly, the payment requirement and the 402 error for unpaid requests. It does not explicitly state when not to use the tool, but the payment context implies usage only with a funded wallet.
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 reveals the tool is read-only (on-chain reads), lists all returned fields, and discloses payment requirement (402 response, server needs funded wallet). No destructive behavior mentioned; it's a safe operation.
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?
Description is somewhat long but each sentence adds value: purpose, returned data, payment model. Front-loaded with main purpose. Could be slightly more concise, but 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?
No output schema, but description thoroughly explains what the tool returns (contract status, balances, activity, contract details, risk band). Also covers payment context and chain limitation. Complete for a safety check 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?
Schema coverage is 100% with descriptions for both parameters (chain default 'base', address any 0x). Description adds context about address being EOA or contract and purpose, but does not add significant new semantic meaning beyond schema. Baseline 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?
Description clearly states the tool provides a structural safety profile for any Base address (EOA or contract) before sending funds, approving, or calling. It specifically lists returned data (contract-vs-EOA, balances, tx-count, contract details, risk band) and distinguishes from siblings like token_safety by covering general addresses.
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 states when to use: before sending funds, approving, or calling a contract. Mentions on-chain read-only nature and paid service (402 if unpaid). Does not explicitly exclude scenarios or compare to alternatives, but context is clear enough.
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 are provided, so the description carries the full burden. It discloses that the tool is a paid service (returns 402 if unpaid) and requires a funded wallet on Base. It also mentions the return includes block and approx age. Missing details like rate limits or error handling, but this is adequate disclosure 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?
Description is front-loaded with the core purpose in the first sentence. It compresses parameters, return fields, use-case advice, and payment info into a few sentences. While efficient, it is slightly dense and could be structured more clearly. 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?
Given the absence of output schema and annotations, the description explains the data source, DEXes, token details, use case, bundling suggestion, and payment requirement. It covers most essential context for an agent to decide to use the tool, though it lacks explicit error scenarios or exact JSON structure.
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 all parameters have descriptions in the schema. The description simply lists the parameters without adding extra meaning beyond what the schema provides, thus minimal added value. 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?
Description clearly states it returns recently-created Base DEX pairs from a background log-watcher for trading agents/snipers. This verb+resource combination distinguishes it from sibling tools like token_safety or whale_swaps, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly suggests bundling with /v1/token-safety for rug/honeypot checks, indicating a common use case. It implies usage for fresh token launches, but does not explicitly state when not to use this tool or name alternative tools beyond the bundle suggestion.
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 exist, so the description fully bears behavioral disclosure. It notes payment requirements, the 402 error for unpaid requests, and the use of POST. It does not cover rate limits or other behaviors, but for a simple fetch this is sufficient.
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 sentences: purpose, request format and error condition, and pricing/wallet requirements. No extraneous information, well-structured and front-loaded.
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 no output schema, the description lists all return fields (title, description, image, etc.) and explains the 402 error. For a simple tool with one parameter, this provides sufficient context for an agent to use it 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?
The input schema has 100% coverage with a single 'url' parameter described as 'The page URL (http/https)'. The description adds that the tool uses POST, but does not explain the parameter format beyond the schema. Baseline 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 fetches a URL and returns Open Graph card data, listing specific fields (title, description, image, etc.). This distinguishes it from siblings like web_extract, which likely extracts all content.
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 context on when the tool is appropriate: it's a paid service requiring a funded wallet, and unpaid requests return 402. However, it does not explicitly advise when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 return fields (id, provider, prices), pricing model (3% over cost, min fee), and payment method (x402). Missing details on pagination or limits, but acceptable for a listing 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?
Single paragraph, front-loaded with purpose. Concise but could be slightly shorter. No wasted sentences.
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?
No output schema, but description details return values (id, provider, prices). Covers essential behavior. No obvious gaps given zero parameters.
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?
Input schema has 0 parameters and schema description coverage is 100%. Description does not need to add param info; baseline 4 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 tool lists LLM models with live pricing, using specific verbs ('list', 'returns'). It distinguishes from sibling tools (e.g., chat, address_safety) which have unrelated purposes.
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?
Implied usage: when an agent needs to pick a model and know cost before paying. No explicit when-not or alternatives, but sibling tools are unrelated, so no confusion.
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?
In absence of annotations, the description discloses the POST method, 402 error for unpaid requests, and payment mechanism (USDC on Base). It doesn't cover rate limits or other edge cases, but addresses critical behavioral 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?
Two sentences with no redundancy. First sentence defines core purpose concisely; second sentence adds essential payment context. Every sentence earns its place.
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 tool with 1 parameter and no output schema, the description covers purpose, behavior, and payment requirement fully. No gaps for agent decision-making.
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 covers 100% of the single 'url' parameter. Description adds no additional meaning beyond the schema description 'Any URL on the site', thus baseline score 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 tool fetches robots.txt and llms.txt, reports AI crawler status, and includes sitemaps, using a specific verb 'Fetch' and distinct resource. It differentiates from siblings like 'headers_check' or 'seo_audit'.
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 checking AI crawler permissions and sitemaps, and notes payment requirements. It lacks explicit when-not-to-use or alternative tools, but the uniqueness of the tool makes usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the paywall behavior (402 response, flat pricing, USDC on Base, MCP wallet needed) and return format (structured JSON with scores). It does not mention side effects or rate limits, but covers the major behavioral aspects.
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 front-loaded with the main purpose and is concise (4-5 sentences). Every sentence adds value, including payment and output details. No wasted words, though it could be slightly more structured.
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?
In the absence of an output schema, the description explains the return format (JSON with per-category scores and issues). It also covers the payment flow and prerequisites, but does not enumerate all possible error states beyond 402.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for parameters, and the description adds value by specifying the HTTP method (POST), the optional nature of 'mode' (default both), payment details, and output structure. This goes 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 clearly states the tool audits a web page for SEO and GEO, with specific verb 'Audit' and resource 'web page'. It distinguishes from sibling tools like 'headers_check' and 'robots_check' by being broader and including payment details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the payment requirement (402 for unpaid) and the workflow, but does not explicitly state when to use this tool versus alternatives like 'web_extract' or 'headers_check'. However, the payment and return format provide 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?
Discloses payment requirement and behavior (402 if unpaid). No annotations, so description carries full burden. Does not mention any side effects or whether URL is fetched publicly, but overall 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 fluff. First sentence states core function; second adds critical payment context. Highly 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?
Covers purpose, parameter, and payment. Lacks example output or detailed list of headers, but for a single-parameter tool this is adequate. Could include a note about required authentication or rate limits, but not essential.
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 already documents 'url' parameter well. Description adds value by indicating HTTP method (POST) and that the URL is the payload. With 100% schema coverage, baseline is 3, but extra context merits a 4.
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 fetches a URL and analyzes HTTP security headers, outputting present/missing and a score. Differentiates from siblings like seo_audit or robots_check which focus on other aspects.
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 notes paid service with 402 for unpaid, and prerequisite of funded wallet. No explicit when-not-to-use, but sibling tools are distinct enough to avoid confusion.
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 are present, so the description carries full burden. It discloses payment model (402 if unpaid), result fields, and usdValue calculation. Could add rate limits or auth details, but current info is solid.
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 well-structured paragraph: purpose first, then parameter list, then result fields, then payment note. Every sentence adds value, 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?
Covers result content (pool, token, quote, USD size, direction, block, age, txHash) and usdValue computation. Lacks default ordering or sorting details, but complete enough for a fetch tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds defaults (min=10000, limit=50) and clarifies direction refers to 'non-quote token', providing value beyond 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 it returns 'recent large DEX Swap events' for whale-following/copy-trading, specifying DEXs (Uniswap V3 + Aerodrome) and chain (Base). It uniquely identifies the tool's function among siblings.
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 usage context (whale-following signal), parameter hints (POST with filter options), and payment requirement ('PAID x402 service'). No explicit when-not or alternatives, but sufficient implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses payment model, server dependencies, error codes (402, 503), and cautions that raw contract count is not a rug verdict. Also explains the 'deep' flag behavior. This is comprehensive 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?
Description is somewhat dense but front-loaded with core purpose. Every sentence adds value, though some restructuring could improve readability. Still, it's concise enough for an AI agent.
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 output schema, the description covers what the tool returns (reputation profile) and hints at additional results for 'deep'. It does not specify exact output format but provides enough context for expected behavior. Missing explicit return shape, but acceptable for a profiling 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?
Schema coverage is 100% with clear descriptions for all 3 parameters. Description adds value by explaining the 'deep' flag's full effect, the supported chain, and the POST method for the token. No contradictions.
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 resolves and profiles the deployer of a Base token, including reputation metrics like age, balance, contracts shipped, and fresh wallet detection. It distinguishes from siblings like token_safety or address_safety by focusing solely on deployer reputation, not token-level safety.
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 mentions the tool is a paid x402 service, requires a wallet on the server, and returns 402/503 for payment/config issues. It implies usage for deployer reputation checks but does not explicitly compare with siblings or state when to use vs not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the composite nature, the verdict format, the paid service requirement (USDC on Base with funded wallet), and the 402 error for unpaid calls.
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?
Description is detailed but front-loaded with the core purpose. Some redundancy (e.g., repeating 'PAID x402 service'), but overall efficient for the tool's complexity.
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 no output schema and tool complexity, the description adequately covers return values (verdict, reasons, underlying reports) and operational context (payment, chain support). Complete for an agent to understand and 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 100%, so baseline is 3. Description adds that 'token' is an ERC-20 address on Base and 'chain' defaults to 'base', but these are already in the schema descriptions. No additional semantic enrichment beyond 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's purpose: a composite that runs token-safety checks, liquidity removal, and whale activity on a Base ERC-20, returning a single verdict. It distinguishes from sibling tools (token_safety, liquidity_pulls, whale_swaps) by being a one-call alternative.
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?
Explicitly says 'one call instead of five' and 'cheaper than buying... separately', indicating when to use this composite over individual tools. Also notes unpaid requests return 402, implying payment is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses paid nature (x402), explains honeypot simulation as a gas-free eth_call, and mentions return format (0-100 score + risk flags) and 402 for unpaid requests.
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?
Description is informative yet reasonably concise for the complexity, with clear structure: purpose, checks, return, payment. Slightly long but every sentence adds value.
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 complexity (multi-check, paid service) and no output schema, description covers purpose, checks, return format, payment requirement, chain, and technical details (eth_call). No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by specifying that 'token' is an ERC-20 address on Base, that 'chain' defaults to 'base', and provides context about on-chain reads.
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 it performs a rug/honeypot safety check for ERC-20 tokens on Base, listing specific checks (conformance, ownership, mint, liquidity, honeypot simulation). It distinguishes from sibling tools that cover other domains (chat, SEO, 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 when to use (safety check for ERC-20 on Base) and mentions paid service. Lacks explicit when-not-to-use or comparison to siblings, but context is clear and sufficient.
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:

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

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/true402/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/true402/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/true402/mcp-server'

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