Skip to main content
Glama
open-crater

opencrater-mcp

by open-crater
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

opencrater-mcp

An MCP server for OpenCrater — the monetization network for the terminal. Surface OpenCrater inside any MCP client (Claude Code, Codex, …): live network stats, supported AI tools, and how to start earning USDC from your own MCP server or CLI tool.

No credentials needed — every tool reads public data.

Tools

Tool

What it returns

opencrater_network_stats

Live network momentum — Blips delivered, developers reached, budget committed to creators, USDC earned by maintainers, supported tools.

opencrater_supported_tools

The AI coding tools where OpenCrater Blips render.

opencrater_get_started

How a maintainer starts earning USDC with OpenCrater.

Related MCP server: refinore-mcp

Install

Two ways to connect — a local stdio package, or the hosted remote endpoint.

Local (stdio, via npx)

npx opencrater-mcp
{
  "mcpServers": {
    "opencrater": {
      "command": "npx",
      "args": ["-y", "opencrater-mcp"]
    }
  }
}

Hosted (remote, Streamable HTTP)

No install — point any MCP client at the hosted endpoint:

https://opencrater.to/mcp
{
  "mcpServers": {
    "opencrater": {
      "url": "https://opencrater.to/mcp"
    }
  }
}

Run from source

npm install
npm run build
node dist/index.js

Monetize your tool

If you maintain an MCP server or CLI tool, you can earn USDC with a single tasteful sponsored Blip at a natural pause — free to add, opt-out always a keystroke away. → https://opencrater.to/monetize

License

MIT

Available Tools

3 tools
opencrater_get_startedAInspect

How a maintainer can start earning USDC from their MCP server or CLI tool with OpenCrater.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description should disclose behavioral traits. It implies the tool provides informational content but does not specify what occurs upon invocation (e.g., returns guide text, redirects, etc.), nor does it address safety 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?

The description is a single, clear sentence with no redundant information. It is front-loaded with the core purpose and uses exact words efficiently.

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 zero parameters and no output schema, the description is minimal but sufficient for a simple informational tool. However, it could be enhanced by indicating what the tool returns (e.g., a step-by-step guide or link), making it more complete for agents.

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 no parameters, so the baseline is 4. The description adds meaning by explaining the tool's purpose, which is helpful for an agent given 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?

The description clearly states the tool's purpose: instructing maintainers on how to earn USDC from their MCP server or CLI tool with OpenCrater. It distinguishes itself from siblings (network_stats, supported_tools) by focusing on the onboarding process.

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, nor any prerequisites or limitations. The description simply states what it does, 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.

opencrater_network_statsBInspect

Live OpenCrater network momentum: Blips delivered, developers reached, advertiser budget committed to reward creators, USDC earned by maintainers, and the number of supported AI coding tools.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 bears full responsibility for behavioral disclosure. It mentions 'Live' but does not explain data freshness, caching behavior, or any side effects (none expected, but not stated). Lack of detail on rate limits or authorization also reduces transparency.

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 concise, using a single sentence with a colon and list. It front-loads the key concept ('Live OpenCrater network momentum'). Slight ambiguity in the term 'momentum' prevents a 5.

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 no output schema, the description attempts to list metrics but lacks detail on data types (e.g., integers, floats) or whether values are cumulative, current, or averages. It is adequate but leaves room for interpretation.

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

Parameters4/5

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

There are zero parameters, so baseline is 4 per rules. The description does not need to elaborate on parameters, and the schema coverage is 100%.

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 'Live OpenCrater network momentum' and enumerates specific metrics (blips delivered, developers reached, etc.). This effectively differentiates it from siblings like 'opencrater_get_started' and 'opencrater_supported_tools'. However, it lacks an explicit verb like 'get' or 'retrieve'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description does not mention usage context or when not to use it.

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

opencrater_supported_toolsCInspect

The AI coding tools where OpenCrater Blips can render.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.1/5.0
Behavior1/5

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

No annotations provided, so description carries full burden. Description is a single noun phrase with no behavioral details: no mention of read-only nature, side effects, or output characteristics. Fails to disclose basic operational traits.

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?

Description is extremely short (one noun phrase), which is concise but under-specified. Lacks complete structure (no verb, no object). Every sentence should earn its place; this one does not.

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 parameters and no output schema, the description should at least explain the return value or purpose more completely. It only says 'the AI coding tools' without specifying that this tool returns a list or provides information.

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 has 0 parameters with 100% trivial coverage. Baseline is 4, but description adds no meaningful context beyond the schema; does not describe what the tool returns or how to interpret results.

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

Purpose2/5

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

Description is a noun phrase lacking a verb: 'The AI coding tools where OpenCrater Blips can render.' It does not clearly state what action the tool performs (e.g., list, get, retrieve). Vague purpose, not distinguishing from siblings.

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 (siblings opencrater_get_started and opencrater_network_stats). No context about prerequisites or typical scenarios.

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.

  1. 3 tool updatesv0.1.0
    • First observedopencrater_get_started
    • First observedopencrater_network_stats
    • First observedopencrater_supported_tools
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool addresses a distinct aspect: getting started, network stats, and supported tools. No overlap in purpose.

Naming Consistency5/5

All tools follow a consistent 'opencrater_' prefix with clear, descriptive snake_case names.

Tool Count4/5

Three tools is slightly minimal but adequate for an informational server; however, the scope feels limited.

Completeness2/5

The server lacks any action-oriented tools (e.g., creating or managing resources), which is a significant gap for a service claiming to help maintainers earn USDC.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • refinore-mcp

    JussCubs
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that enables AI agents to autonomously manage ORE mining on the Solana blockchain via the refinORE platform. It provides tools for starting mining sessions, monitoring rewards, and managing multi-token balances through natural language commands.
    12
    7 npm
    1
    MIT

  • maxia-mcp

    majorelalexis-stack
    A
    license
    Not graded
    quality
    C
    maintenance
    AI-to-AI marketplace MCP server with 46 tools — swap 65+ crypto tokens on 7 chains, rent GPUs, trade 25 tokenized stocks, on-chain escrow (Solana + Base), DeFi yields, sentiment analysis, wallet monitoring, and image generation. Supports USDC payments across 14 blockchains.
    MIT

  • GenTech Agent Kit

    ProtoJay4789
    A
    license
    C
    quality
    A
    maintenance
    An MCP server that gives AI agents real-time market data, DeFi intelligence, and automatic tool discovery via plugins. Supports x402 micropayments and is always updated.
    23
    MIT