Skip to main content
Glama
dasein108

Cyb MCP Server

by dasein108
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript

Cyb MCP Server

A Model Context Protocol (MCP) server for integrating with the Cyber. This server enables AI agents to interact with the decentralized knowledge graph, create cyberlinks, and retrieve content from IPFS through the Cyber network.

This project is a contribution to the Great Web Foundation, supporting the development of a decentralized, censorship-resistant web.

Cyb MCP Demo 1

Cyb MCP Demo 2

Features

  • sendCyberlink: Create cyberlinks between IPFS CIDs on the Cyber network using CIDs or plain texts

  • searchQuery: Search the Cyber knowledge graph and retrieve content from IPFS

  • getCyberlink: Retrieve content from IPFS by CID

Related MCP server: knowledgeplane

Setup

  1. Install dependencies:

    npm install

  2. Build the project:

    npm run build

  3. Configure environment variables:

    # Required for all operations
export CYBER_RPC_URL="https://rpc.bostrom.cybernode.ai"
export CYBER_GATEWAY="https://gateway.ipfs.cybernode.ai"

# Optional - only needed for sendCyberlink tool
export CYBER_MNEMONIC="your twelve word mnemonic phrase here"

  4. Run the server:

    npm start

Usage with Claude Desktop

Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "cyb": {
      "command": "node",
      "args": ["/path/to/cyb-mcp/dist/index.js"],
      "env": {
        "CYBER_RPC_URL": "https://rpc.bostrom.cybernode.ai",
        "CYBER_GATEWAY": "https://gateway.ipfs.cybernode.ai"
      }
    }
  }
}

For sendCyberlink functionality, add mnemonic:

{
  "mcpServers": {
    "cyb": {
      "command": "node",
      "args": ["/path/to/cyb-mcp/dist/index.js"],
      "env": {
        "CYBER_MNEMONIC": "your twelve word mnemonic phrase here",
        "CYBER_RPC_URL": "https://rpc.bostrom.cybernode.ai",
        "CYBER_GATEWAY": "https://gateway.ipfs.cybernode.ai"
      }
    }
  }
}

Tools

sendCyberlink

Creates a cyberlink between two pieces of content. Requires mnemonic to be configured.

Parameters:

  • from: Source CID or text content

  • to: Target CID or text content

  • fee: Optional transaction fee object

Note: This tool will return an error if no mnemonic is provided in the configuration.

searchQuery

Searches the Cyber knowledge graph. No mnemonic required.

Parameters:

  • query: Search query (CID or text)

  • page: Page number for pagination (default: 0)

  • retrieveContent: Whether to fetch content from IPFS (default: false)

  • limit: Max results to retrieve content for (default: 5)

Returns:

  • Array of content items in the response

  • Each search result as a separate item

  • Supports both text and image content when retrieveContent is true

  • Images are automatically detected and returned as base64-encoded data

getCyberlink

Retrieves content from IPFS by CID through the Cyber gateway. No mnemonic required.

Parameters:

  • cid: IPFS CID to retrieve content for

Features:

  • Automatic image detection based on MIME type and content headers

  • Returns images as base64-encoded data with proper MCP image content type

  • Returns text content as formatted text

  • Supports PNG, JPEG, GIF, WebP, and SVG images

Usage Modes

The MCP server supports two usage modes:

Read-Only Mode (No Mnemonic)

  • Available tools: searchQuery, getCyberlink

  • Perfect for exploring and retrieving content from the Cyber network

  • No wallet or signing capabilities

Full Mode (With Mnemonic)

  • Available tools: sendCyberlink, searchQuery, getCyberlink

  • Includes wallet for creating cyberlinks and signing transactions

  • Requires mnemonic phrase for wallet access

Security

The mnemonic is stored in environment variables. Keep your mnemonic secure and never commit it to version control.

Links

  • Main Project: cyb.ai - The superintelligence for the decentralized web

  • Documentation: cyber.page - Philosophy of Great Web

Available Tools

3 tools
searchQueryB

Search the Cyber knowledge graph and optionally retrieve content from IPFS

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query (CID or text)
pageNoPage number for pagination (default: 0)
retrieveContentNoWhether to retrieve actual content from IPFS gateway (default: false)
limitNoMaximum number of results to retrieve content for (default: 5)

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 the full burden of behavioral disclosure. It mentions searching and optional content retrieval but lacks details on permissions, rate limits, error handling, or what the search results entail (e.g., format, scope). For a tool with potential complexity in graph searching and IPFS integration, this is insufficient.

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 core purpose and optional feature. It wastes no words and is appropriately sized for the tool's functionality, earning full marks for conciseness.

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 annotations and no output schema, the description is minimal but covers the basic action. It doesn't explain return values or handle the complexity of graph searching and IPFS retrieval adequately. However, it's complete enough for a simple search tool, though gaps in behavioral details keep it at an average score.

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 description coverage is 100%, so the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying that 'query' can be a CID or text (hinted in schema) and that content retrieval is optional. This meets the baseline for high schema coverage without extra value.

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: 'Search the Cyber knowledge graph and optionally retrieve content from IPFS.' It specifies the verb ('Search') and resource ('Cyber knowledge graph'), with an additional capability ('retrieve content from IPFS'). However, it doesn't explicitly differentiate from sibling tools like 'getCyberlink' or 'sendCyberlink', which might involve similar graph operations, so it falls short of a perfect score.

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 'getCyberlink' or 'sendCyberlink'. It mentions an optional action ('retrieve content from IPFS') but doesn't clarify scenarios where this is preferred or when other tools might be more appropriate, leaving the agent without usage context.

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 updates
    • First observedgetCyberlink
    • First observedsearchQuery
    • First observedsendCyberlink
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.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: getCyberlink retrieves content from IPFS, searchQuery searches the knowledge graph and optionally retrieves content, and sendCyberlink creates links between CIDs. There is no overlap in functionality, making tool selection straightforward for an agent.

Naming Consistency4/5

The tools follow a consistent verb_noun pattern (getCyberlink, searchQuery, sendCyberlink) with camelCase naming throughout. However, 'searchQuery' uses 'Query' as the noun, which is slightly less descriptive than the others, but overall the naming is highly consistent and predictable.

Tool Count5/5

With 3 tools, this server is well-scoped for its purpose of interacting with the Cyber network and IPFS. Each tool serves a distinct and essential function (retrieval, search, and linking), and there are no extraneous tools, making the count appropriate and efficient.

Completeness4/5

The toolset covers core operations for the Cyber/IPFS domain: retrieving content, searching the knowledge graph, and creating cyberlinks. Minor gaps might include operations like deleting or updating cyberlinks, but the provided tools enable key workflows without significant dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers