Skip to main content
Glama
open-crater

opencrater-mcp

by open-crater
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Server Quality Checklist

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

  • Latest release: v0.1.0

  • 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.

  • Average 2.9/5 across 3 of 3 tools scored. Lowest: 2.1/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 3 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • 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.

  • 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.

  • 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.

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

opencrater-mcp MCP server

Copy to your README.md:

Score Badge

opencrater-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/open-crater/opencrater-mcp'

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