Skip to main content
Glama
BrainDAO

MCP-IQWiki

by BrainDAO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

📚 IQ Wiki MCP Server

npm version License: MIT

📖 Overview

The IQ Wiki MCP Server enables AI agents to interact with IQ.wiki, a blockchain-powered encyclopedia for crypto and DeFi knowledge. This server provides comprehensive access to wiki data, user contributions, and activity tracking.

By implementing the Model Context Protocol (MCP), this server allows Large Language Models (LLMs) to discover wiki articles, search for knowledge, and track user wiki activities directly through their context window, bridging the gap between AI and decentralized knowledge.

Related MCP server: Wikipedia MCP Server

✨ Features

  • Wiki Access: Retrieve detailed information about any wiki article on IQ.wiki by ID.

  • User Contributions: Track wikis created or edited by specific users based on their Ethereum address.

  • Activity Tracking: Monitor detailed wiki activities (creations and edits) with optional time filtering.

  • Search: Search for wiki articles using natural language queries.

📦 Installation

🚀 Using npx (Recommended)

To use this server without installing it globally:

npx @iqai/mcp-iqwiki

📦 Using pnpm dlx

pnpm dlx @iqai/mcp-iqwiki

🔧 Build from Source

git clone https://github.com/IQAIcom/mcp-iqwiki.git
cd mcp-iqwiki
pnpm install
pnpm run build

⚡ Running with an MCP Client

Add the following configuration to your MCP client settings (e.g., claude_desktop_config.json).

📋 Minimal Configuration

{
  "mcpServers": {
    "iq-wiki": {
      "command": "npx",
      "args": ["-y", "@iqai/mcp-iqwiki"]
    }
  }
}

⚙️ Advanced Configuration (Local Build)

{
  "mcpServers": {
    "iq-wiki": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-iqwiki/dist/index.js"]
    }
  }
}

💡 Usage Examples

🔍 Wiki Discovery

  • "Get the wiki article for Bitcoin"

  • "Search for wikis about DeFi protocols"

  • "Find information about Ethereum"

👤 User Contributions

  • "What wikis has 0x8AF7a19a26d8FBC48dEfB35AEfb15Ec8c407f889 created?"

  • "Show wikis edited by this user in the last 24 hours"

  • "Get all wiki activities for this Ethereum address"

📊 Activity Tracking

  • "List recent wiki creations by user 0x..."

  • "Show wiki edits in the last hour"

  • "Track user wiki contributions over time"

🛠️ MCP Tools

GET_USER_CREATED_WIKIS

Get wikis created by a specific user on IQ.wiki

Parameter

Type

Required

Description

id

string

✅

The Ethereum address of the user

timeFrameSeconds

number

Optional time frame in seconds to filter results

GET_USER_EDITED_WIKIS

Get wikis edited by a specific user on IQ.wiki

Parameter

Type

Required

Description

id

string

✅

The Ethereum address of the user

timeFrameSeconds

number

Optional time frame in seconds to filter results

GET_USER_WIKI_ACTIVITIES

Get wiki activities (creations or edits) for a specific user on IQ.wiki

Parameter

Type

Required

Description

id

string

✅

The Ethereum address of the user

activityType

string

Type of activity: CREATED or UPDATED

timeFrameSeconds

number

Optional time frame in seconds to filter results

GET_WIKI

Get details about a specific wiki from IQ.wiki by ID

Parameter

Type

Required

Description

id

string

✅

The ID of the wiki to retrieve

SEARCH_WIKI

Search for a wiki from IQ.wiki by query

Parameter

Type

Required

Description

query

string

✅

The query to search for

👨‍💻 Development

🏗️ Build Project

pnpm run build

👁️ Development Mode (Watch)

pnpm run watch

✅ Linting & Formatting

pnpm run lint
pnpm run format

🧪 Testing

pnpm test

📁 Project Structure

  • src/tools/: Individual tool definitions

  • src/services/: API client and business logic

  • src/lib/: Shared utilities

  • src/index.ts: Server entry point

📚 Resources

⚠️ Disclaimer

This tool interacts with IQ.wiki blockchain data. Users should verify all information independently. Wiki content is community-contributed and may change over time.

📄 License

MIT

Available Tools

5 tools
GET_USER_CREATED_WIKISB

Get wikis created by a specific user on IQ.wiki

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe Ethereum address of the user
timeFrameSecondsNoOptional time frame in seconds to filter results

TDQS

B3.1/5.0
Behavior2/5

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

The description does not disclose any behavioral traits such as being read-only, potential rate limits, or data freshness. Since annotations are absent, the description should provide more transparency beyond the basic action.

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 a single, front-loaded sentence with no wasted words. However, it could be slightly more informative without increasing length significantly.

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 lack of an output schema, the description does not hint at the return format or any limitations. For a read tool, this leaves gaps in the agent's understanding.

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% (both parameters have descriptions), so the baseline is 3. The description adds no additional meaning beyond the schema, which already documents 'id' as an Ethereum address and 'timeFrameSeconds' as an optional filter.

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 ('Get') and the resource ('wikis created by a specific user on IQ.wiki'), distinguishing it from sibling tools like GET_USER_EDITED_WIKIS by specifying 'created'.

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 such as GET_USER_EDITED_WIKIS or GET_USER_WIKI_ACTIVITIES. The usage context is only implied by the name.

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

GET_USER_EDITED_WIKISC

Get wikis edited by a specific user on IQ.wiki

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe Ethereum address of the user
timeFrameSecondsNoOptional time frame in seconds to filter results

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states a basic operation without mentioning permissions, rate limits, pagination, ordering, or empty results—missing critical context for a read 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?

The description is a single concise sentence with no unnecessary words. However, it lacks structure such as bullet points or sections that could aid readability.

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?

With only 2 parameters and no output schema, the description should explain return values and behavior (e.g., what data is returned, how timeFrameSeconds affects results). It fails to do so, leaving the agent under-informed.

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 describes both parameters (id as Ethereum address, timeFrameSeconds as optional filter) with 100% coverage. The description adds no additional meaning beyond the schema, so baseline score 3 is appropriate.

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 action ('Get') and resource ('wikis edited by a specific user on IQ.wiki'), distinguishing from siblings like GET_USER_CREATED_WIKIS. However, it does not explicitly differentiate from other user-related 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 is provided on when to use this tool versus alternatives (e.g., GET_USER_CREATED_WIKIS or GET_USER_WIKI_ACTIVITIES). The agent must infer usage from tool names alone.

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

GET_USER_WIKI_ACTIVITIESA

Get wiki activities (creations or edits) for a specific user on IQ.wiki

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe Ethereum address of the user
activityTypeNoType of activity: CREATED or UPDATED
timeFrameSecondsNoOptional time frame in seconds to filter results

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, and the description only states the basic operation without disclosing any behavioral traits such as read-only nature, authentication requirements, or response format.

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 that is front-loaded with the verb and context, making it efficient and easy to parse.

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?

While the parameters are clear, the description lacks information about the response format, pagination, or how the timeFrameSeconds parameter affects results, given the absence of an output schema or annotations.

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 already provides full descriptions for all three parameters (100% coverage), so the description adds no additional semantics beyond restating the tool's purpose.

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 retrieves wiki activities (creations or edits) for a specific user on IQ.wiki, distinguishing it from sibling tools that focus on only one type of activity.

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 fetching both creation and edit activities, but it does not explicitly compare with sibling tools or state 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.

GET_WIKIA

Get details about a specific wiki from IQ.wiki by ID

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the wiki to retrieve

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 bears full responsibility for behavioral disclosure. It only states 'get details' without explaining what details are returned, error conditions, or access requirements. This is minimal and insufficient for a transparent description.

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 that immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary words or 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 single parameter and absence of output schema, the description is basic but adequate. However, it does not explain what 'details' the response contains or how to interpret the output, leaving some ambiguity.

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 provides 100% coverage with a description for the 'id' parameter. The tool description reinforces that the ID is used for retrieval but adds no extra semantic value (e.g., format, source). 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 'Get details about a specific wiki from IQ.wiki by ID,' specifying the verb, resource, scope, and source. It effectively distinguishes itself from sibling tools focused on user-specific wikis (e.g., GET_USER_CREATED_WIKIS) by indicating direct retrieval by ID.

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 use when a specific wiki ID is known, but it lacks explicit guidance on when to use this tool versus alternatives like SEARCH_WIKI. No 'when not to use' or prerequisites are mentioned, making it acceptable but not proactive.

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

SEARCH_WIKIB

Search for a wiki from IQ.wiki by query

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe query to search for

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as output format, pagination, rate limits, or prerequisites. The bare description does not add value beyond the parameter schema.

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 very short and front-loaded with the purpose. Every word is necessary, though it could be slightly expanded without losing conciseness.

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?

For a search tool with no output schema and no annotations, the description is incomplete. It does not explain result format, limit, or how to interpret results, which is crucial for an agent to use the tool 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% and the parameter 'query' already has a description. The description does not add additional meaning beyond what the schema provides, so baseline 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 (Search), resource (wiki from IQ.wiki), and method (by query). It distinguishes from sibling tools like GET_WIKI which likely retrieves a specific wiki.

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 vs alternatives like GET_WIKI or user-specific wikis. The description does not provide any context for usage.

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. 5 tool updatesv1.0.0
    • First observedGET_USER_CREATED_WIKIS
    • First observedGET_USER_EDITED_WIKIS
    • First observedGET_USER_WIKI_ACTIVITIES
    • First observedGET_WIKI
    • First observedSEARCH_WIKI
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

A3.5/5.0

Scored across 5 tools

Disambiguation4/5

Most tools are distinct: search, get by ID, and user-specific queries. However, GET_USER_WIKI_ACTIVITIES overlaps with GET_USER_CREATED_WIKIS and GET_USER_EDITED_WIKIS, potentially causing confusion.

Naming Consistency5/5

All tool names follow a consistent pattern: uppercase snake_case with GET_ prefix (e.g., GET_USER_CREATED_WIKIS). No mixing of conventions.

Tool Count5/5

5 tools is appropriate for a focused wik.iq MCP server, covering essential read operations without being excessive.

Completeness4/5

The set covers basic read operations (search, get by ID, user wikis) but lacks write capabilities (create, update, delete) and a list-all function. Minor gaps for a read-only server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Wikipedia MCP Server

    Rudra-ravi
    A
    license
    B
    quality
    B
    maintenance
    A Model Context Protocol server that retrieves information from Wikipedia to provide context to LLMs, allowing users to search articles, get summaries, full content, sections, and links from Wikipedia.
    22
    2,952 PyPI
    295
    MIT

  • RL-MCP

    rlefko
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides AI models with structured access to external data and services, acting as a bridge between AI assistants and applications, databases, and APIs in a standardized, secure way.
    2
    -

  • Azure DevOps Wiki MCP Server

    uright
    A
    license
    A
    quality
    C
    maintenance
    A Model Context Protocol server that enables AI agents to interact with Azure DevOps wikis, providing capabilities for content search, page management, and hierarchical structure navigation.
    5
    5 npm
    MIT