What can you do with this server?

The GenTech Agent Kit gives AI agents full-stack market data, DeFi intelligence, x402 micropayment rails, creative content generation, and system monitoring — all in one server, with plugin extensibility. 📈 Market Data (CoinMarketCap-powered) * Fetch real-time crypto price quotes (get_quote), top token listings by market cap (get_listings), token metadata/search (search_token), trending gainers/losers/most-visited (get_trending), and DEX pair data across exchanges (get_dex_pairs). 🔗 Algorand x402 Payments * Check gateway/account status, verify x402 payments and receive session tokens, and get crypto quotes settled in ALGO via GoPlausible (0.001 ALGO/query). 🏦 Robinhood Chain x402 * Get network status, list tokenized stocks (AAPL, NVDA, TSLA, MSFT, META, etc.) with contract info, fetch stock prices ($0.005 USDG/query), get crypto quotes ($0.001 USDG or free tier), and verify USDG payments via Naven Network for 60-minute session tokens. 🛡️ Output Enforcer * Monitor tool output validation violations (filterable by tool/time), inspect circuit breaker statuses, clear violation records, and check overall enforcer health. 🎨 Pika Creative Suite * List available creative skills (4K VFX, UGC ads, anime, viral hooks, etc.), generate content via any skill, build full brand identities (strategy, logo, palette, typography) from a brief, create 15-second app launch videos from an app store link or GitHub repo, and produce polished explainer videos from a URL, repo, or brief. 🔧 Platform Utilities * Check kit version, available tool list, and update status (kit_info).

Which integrations are available for this server?

Provides real-time market data, token metadata, trending tokens, and DEX pair information via the CoinMarketCap API.

How do I use GenTech Agent Kit?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GenTech Agent Kit get a quote for BTC" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

GenTech Agent Kit

by ProtoJay4789

Overview Schema Related Servers Score Discussions

Python

Remote

GenTech Agent Kit

One install. Full stack. Your agent, running.

Release License Language Skills x402 Atelier

The GenTech Agent Kit packages the entire GenTech stack into a single installable MCP server. One command gives any AI agent real-time market data, DeFi intelligence, payment rails, and agent identity infrastructure.

uvx --from git+https://github.com/ProtoJay4789/genTech-agent-kit.git gentech-kit

Install as Agent Skills

# Install the main skill
npx skills add ProtoJay4789/genTech-agent-kit

# Install specific skills
npx skills add ProtoJay4789/genTech-agent-kit --skill x402-payments
npx skills add ProtoJay4789/genTech-agent-kit --skill robinhood-chain
npx skills add ProtoJay4789/genTech-agent-kit --skill output-enforcer

Related MCP server: opendexter

Quick Start

# Install and run
uvx --from git+https://github.com/ProtoJay4789/genTech-agent-kit.git gentech-kit

Requires: CMC_API_KEY env var (get one free at coinmarketcap.com/api)

export CMC_API_KEY="your-key-here"

Tools

Market Data

Tool	Description
`get_quote(symbol)`	Real-time price for BTC, ETH, SOL, etc.
`get_listings(start, limit)`	Top tokens by market cap
`search_token(symbol)`	Token metadata, description, tags, logo
`get_trending(kind)`	Gainers, losers, most visited, latest
`get_dex_pairs(symbol)`	DEX pair data across exchanges

Platform

Tool	Description
`kit_info()`	Agent Kit version, tool list, update status

Plugins (auto-discovered)

Plugin	Tools	Settlement
Algorand x402 Gateway	`algorand_x402_info`, `algorand_verify_payment`, `algorand_get_quote`	ALGO via GoPlausible
Robinhood Chain x402	`rh_info`, `rh_list_stocks`, `rh_get_stock`, `rh_crypto_quote`, `rh_verify_payment`	USDG via Naven Network
Output Enforcer	`output_enforcer_status`, `output_enforcer_violations`, `output_enforcer_clear`, `output_enforcer_breakers`	—
Pika Creative Suite	`pika_skills`, `pika_generate`, `pika_build_brand`, `pika_app_sizzle`, `pika_explainer`	—

Demo: x402 Payment Flow

# Hit a paid endpoint without payment
curl -i https://api.naven.network/x402-test/ping
# → HTTP 402 Payment Required with x402 v2 challenge
# → Network: Robinhood Chain (eip155:4663)
# → Token: USDG ($0.0001 per query)

Why GenTech Agent Kit?

Feature	Benefit
Always updated	Active development — new tools ship continuously. `uv tool install --reinstall` gets the latest.
Adaptive stack	Modular design. Tools discovered dynamically — the kit grows without breaking existing integrations.
x402 native	Every API supports machine-to-machine micropayments. Pay per query, no subscription.
Open source	MIT license. Audit, fork, extend. No vendor lock-in.
Premier distribution	Listed on Atelier, PortalHQ, Monad Agent Hub. Your agent finds us automatically.

MCP Client Setup

Claude Code

claude mcp add gentech-agent-kit \
  --env CMC_API_KEY=your-key-here \
  -- uvx --from git+https://github.com/ProtoJay4789/genTech-agent-kit.git gentech-kit

Claude Desktop

{
  "mcpServers": {
    "gentech-agent-kit": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/ProtoJay4789/genTech-agent-kit.git", "gentech-kit"],
      "env": { "CMC_API_KEY": "your-key-here" }
    }
  }
}

License

MIT — GenTech Labs

About

GenTech Labs builds payment infrastructure for AI agents. We make it possible for agents to pay each other, subscribe to services, and earn revenue — all on-chain, all autonomously.

Available Tools

8 tools

get_trendingA

Get trending crypto data. Options: gainers, losers, most_visited, latest. Cost: $0.001 USDC/query.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No		latest

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

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 the cost ($0.001 USDC/query) and implies the kind parameter values. However, it does not detail side effects, rate limits, idempotency, or behavior on invalid input.

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-load the action and options, with no wasted words. Efficient and scannable.

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?

The tool is simple with one optional parameter and an output schema. The description covers the core purpose and valid options. However, it does not hint at the structure of the returned data (e.g., token names, prices), which could be useful given siblings like get_quote offer more detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description compensates by listing valid options for the 'kind' parameter (gainers, losers, most_visited, latest). This adds meaning beyond the schema default of 'latest', though the description could clarify what each option returns.

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 retrieves trending crypto data and lists specific options (gainers, losers, most_visited, latest). It distinguishes the tool's focus on 'trending' data from siblings like get_listings, though it does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as get_dex_pairs or search_token. It mentions cost but does not clarify context or exclude cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

output_enforcer_clearA

Clear all violation records (memory + disk). Returns count cleared.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses destructive behavior (clear) and mentions it affects both memory and disk, but lacks details on required permissions, reversibility, or side effects. The return count is positive.

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 (12 words, two sentences) and front-loaded with the action and scope. Every word 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 no parameters and an output schema, the description is complete: it states what the tool does, what it affects, and what it returns. No additional context is necessary.

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, so the description cannot add meaning beyond the schema. Schema coverage is 100% by default (empty schema). The baseline for 0 parameters is 4, and the description suffices.

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 ('Clear'), the resource ('all violation records'), the scope ('memory + disk'), and the return value ('Returns count cleared'). It distinguishes itself from sibling tools like 'output_enforcer_breakers' and 'output_enforcer_status' by specifying a clear operation.

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 resetting violation records but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not scenarios. No guidance on prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

output_enforcer_violationsB

Get recent validation violations. Filter by tool name (optional) and time window.

Args: tool_name: Optional tool name to filter by. Empty string returns all. hours: How many hours back to look (default 24).

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No
`tool_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It does not specify if the operation is read-only, whether authentication is needed, rate limits, pagination, or what constitutes a violation. The description is insufficient for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using a clear structure with a one-line summary followed by an Args section listing each parameter. Every sentence adds value, and there is no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 optional params, output schema exists). The description covers the basic purpose and parameters but lacks details on output format, limits, or behavior when no violations are found. It is adequate but not fully complete given the availability of an 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?

The schema has 0% description coverage, so the description compensates by explaining both parameters: tool_name (optional, empty returns all) and hours (default 24). This adds meaningful semantics beyond the raw schema, clarifying defaults and filtering behavior.

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 retrieves recent validation violations with optional filtering by tool name and time window. This distinguishes it from sibling tools like 'output_enforcer_breakers' (likely different violation types) and 'output_enforcer_status' (status). However, it does not explicitly state that it returns a list, which would enhance clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear context (validation violations) and mentions filtering options, but lacks explicit guidance on when to use this tool versus alternatives like 'output_enforcer_clear' or 'output_enforcer_breakers'. No exclusions or prerequisites are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pika_app_sizzleA

Create a 15-second launch video from an app store link, product screens, or GitHub repo URL.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of disclosure. It specifies the output duration (15 seconds) and accepted source types, but omits behavioral traits such as authentication requirements, processing time, error handling, or any side effects. This is insufficient for a tool with no other behavioral hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence of 14 words. It is front-loaded with the core action and resource, with no redundant or superfluous information.

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 one parameter, an output schema (not shown but exists), and simple behavior, the description covers the key input types and output duration. However, it lacks usage guidelines and behavioral transparency, leaving gaps for an agent to make fully informed decisions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only a 'url' parameter with no description (0% coverage). The description compensates by clarifying that the URL can be an app store link, product screens, or GitHub repo URL, adding meaningful context beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create', the resource '15-second launch video', and the source types 'app store link, product screens, or GitHub repo URL'. This distinguishes it from sibling tools like pika_explainer or pika_build_brand, 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 Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus its siblings (e.g., pika_explainer, pika_build_brand). No explicit 'when-not-to-use' or alternative recommendations are given, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pika_build_brandC

Generate a complete brand identity from a product brief. Creates brand strategy, tone of voice, logo direction, color palette, typography, and brand.md.

ParametersJSON Schema

Name	Required	Description	Default
`brief`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present. The description indicates creation of multiple brand assets but does not disclose whether the tool is stateful, requires authentication, or has any side effects. For a generative tool, this is vague.

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, efficient sentence that front-loads the action ('Generate a complete brand identity') and lists key outputs. Every word serves a purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and presence of an output schema, the description covers the basic intent. However, it omits usage context, parameter clarification, and behavioral notes, making it merely 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?

The only parameter 'brief' has no schema description (0% coverage). The description mentions 'product brief' but does not explain required format, content, or length, leaving ambiguity for the agent.

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 explicitly states it generates a complete brand identity from a product brief, listing components like strategy and tone of voice. However, it does not differentiate from sibling generative tools like pika_generate, which could perform similar tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description implies usage from a product brief but offers no exclusions or comparisons to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pika_explainerB

Turn a URL, GitHub repo, or written brief into a polished explainer video.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only describes the transformation input-output without detailing side effects, prerequisites, limits, or constraints. This minimal transparency leaves the agent uninformed about how the tool operates.

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 of 13 words, extremely concise and to the point. Every word serves a purpose, making it easily parsable with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and an output schema, the description covers basic input-output. However, it lacks context on video style, length, or quality guarantees. Given the presence of many sibling tools, more differentiation detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for its single 'url' parameter. The description adds meaning by suggesting the URL can be a website, GitHub repo, or written brief, which is helpful but vague. It partially compensates for schema lack but does not specify format or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: turning a URL, GitHub repo, or written brief into an explainer video. It specifies the input types and output format, effectively distinguishing it from potential sibling tools. However, it doesn't fully align with the schema (only 'url' parameter) and could be more precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like pika_app_sizzle or pika_generate. Without explicit when-to-use or when-not-to-use instructions, the agent lacks context for selection among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pika_generateC

Generate content using a Pika creative skill. Skills: 4k-vfx, app-sizzle, app-store-screens, build-a-brand, founder-product-video, explainer, podcast, ugc-ads, voxel-it, anime-soccer, gameday, kiss-cam, baseball-trend, viral-hook, content-director, fix-my-look, persona-builder, language-swap, stagefight, vfx. Pass params as JSON string.

ParametersJSON Schema

Name	Required	Description	Default
`skill`	Yes
`params`	No		{}

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.5/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, and the description fails to disclose any behavioral traits such as creation of persistent resources, idempotency, authentication needs, or rate limits. The listing of skills does not explain what each skill does or how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with purpose. The list of skills is lengthy but necessary for this tool. The instruction to pass params as JSON string is clear. However, the list could be partially moved to the schema as an enum.

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 the complexity of 20 skills and lack of parameter documentation, the description is incomplete. It does not provide enough context for an agent to correctly invoke the tool, such as what each skill does or how to format params. The presence of an output schema reduces the need for return details, but the description still lacks essential context.

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?

With 0% schema description coverage, the description should compensate but only states that the 'skill' parameter is a listed skill and 'params' is a JSON string. It does not explain the structure or allowed keys for the params JSON, leaving the agent without sufficient guidance on parameter values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates content using a Pika creative skill and lists 20 specific skills. However, it does not differentiate this tool from its sibling tools like pika_app_sizzle or pika_build_brand, which may serve similar purposes for individual skills.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternative Pika-specific siblings. It merely lists skills without context on appropriate usage or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pika_skillsA

List available Pika creative skills — 4K VFX, App Sizzle, Build-a-Brand, Explainer, Founder Video, Podcast, UGC Ads, and more.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only states listing of skills. It is straightforward but lacks behavioral details such as auth requirements or data freshness. Adequate given tool simplicity.

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?

Single sentence efficiently conveys purpose and examples with no extraneous text.

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?

Tool has zero parameters and an output schema; the description fully captures its listing functionality with examples.

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; schema coverage is 100% (empty). Baseline 4 as no extra info needed beyond empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses 'List available Pika creative skills' with specific verb+resource and lists concrete examples, clearly distinguishing it from generation or other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like pika_generate or other pika tools; it only describes what it lists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

15 tool updatesv0.3.2Jul 17, 2026
- Removedalgorand_get_quote
- Removedalgorand_verify_payment
- Removedalgorand_x402_info
- Removedget_dex_pairs
- Removedget_listings
- Removedget_quote
- Removedkit_info
- Removedoutput_enforcer_breakers
- Removedoutput_enforcer_status
- Removedrh_crypto_quote
- Removedrh_get_stock
- Removedrh_info
- Removedrh_list_stocks
- Removedrh_verify_payment
- Removedsearch_token
17 tool updatesJul 11, 2026
- Addedalgorand_get_quote
- Addedalgorand_verify_payment
- Addedalgorand_x402_info
- Addedoutput_enforcer_breakers
- Addedoutput_enforcer_clear
- Addedoutput_enforcer_status
- Addedoutput_enforcer_violations
- Addedpika_app_sizzle
- Addedpika_build_brand
- Addedpika_explainer
- Addedpika_generate
- Addedpika_skills
- Addedrh_crypto_quote
- Addedrh_get_stock
- Addedrh_info
- Addedrh_list_stocks
- Addedrh_verify_payment
6 tool updatesv0.3.0Jul 9, 2026
- First observedget_dex_pairs
- First observedget_listings
- First observedget_quote
- First observedget_trending
- First observedkit_info
- First observedsearch_token

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Disambiguation2/5

The tool set spans three unrelated domains (crypto, output enforcement, Pika creative), but within the Pika subdomain, pika_generate subsumes the functionality of pika_app_sizzle, pika_build_brand, and pika_explainer, causing ambiguity. Additionally, output_enforcer tools are distinct but weakly connected to the rest.

Naming Consistency2/5

Naming conventions are inconsistent: some tools use verb_noun (get_trending), others use noun_verb (output_enforcer_clear), and the Pika tools mix brand prefix with various patterns (nouns, verbs, phrases). No unified pattern emerges.

Tool Count3/5

8 tools is a reasonable number, but the set feels fragmented across unrelated domains. The Pika subdomain occupies 5 tools, which is too many given the redundancy, while the other domains have minimal coverage. The count is borderline appropriate.

Completeness2/5

Each domain is incomplete: crypto only offers trending data with no CRUD; output enforcement lacks configuration or detailed reporting; Pika tools are redundant with pika_generate covering most use cases. Missing essential operations like update, delete, or search across domains.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

AgentLot Marketplace C
io.agentlot
AI marketplace for agents to find paid work and trade digital services via MCP and x402.
E-commerce & Retail Payments & Billing
1241
crypto-defi-mcpOAuth
com.thenextgennexus
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
Cryptocurrency Finance Blockchain
2
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
mcp A
com.everstake
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
Blockchain Cryptocurrency
1111

Related MCP Servers

DEX Pools MCP
Blockchain Cryptocurrency Finance
kukapay
A
license
A
quality
D
maintenance
An MCP server that provides AI agents with real-time access to DEX liquidity pool data, enabling smarter trading, analytics, and automated strategies.
Updated a year ago (2025-10-01 08:54 UTC)
10
1
MIT
opendexterofficial
Payments & Billing Cryptocurrency
Dexter-DAO
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI agents to search, pay for, and call paid APIs using the x402 protocol, with automatic USDC settlement.
Updated a day ago (2026-09-05 01:39 UTC)
2
MIT
superhighway-mcp
Search Cryptocurrency Web3 & Decentralized Tech
patwalls
A
license
A
quality
D
maintenance
An MCP server that provides real-time web search to AI agents via a pay-per-search USDC microtransaction system.
Updated 3 months ago (2026-06-11 02:15 UTC)
5
67
1
MIT
Solana DeFi Intelligence MCP
ragna999
-
license
Not graded
quality
Not graded
maintenance
An MCP server that gives AI agents real-time Solana DeFi intelligence — smart money tracking, rug detection, wallet analysis, and token research.
Updated 3 months ago (2026-06-14 10:37 UTC)
-

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/ProtoJay4789/genTech-agent-kit'

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

GenTech Agent Kit

Install as Agent Skills

Quick Start

Tools

Market Data

Platform

Plugins (auto-discovered)

Demo: x402 Payment Flow

Why GenTech Agent Kit?

MCP Client Setup

Claude Code

Claude Desktop

License

About

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

opendexterofficial

Latest Blog Posts

MCP directory API