Skip to main content
Glama
enesjakozh
antoncoding

BrianKnows MCP Server

by antoncoding
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

BrianKnows MCP 服务器

铁匠徽章

将 Claude 连接到 BrianKnows 的区块链知识库的模型上下文协议 (MCP) 服务器。

MCP 是什么？🤔

模型上下文协议 (MCP) 让 Claude Desktop 等 AI 助手以安全的方式连接到外部工具和数据源，同时保持用户的控制权。

Related MCP server: GOAT MCP Server

这个服务器是做什么的？🚀

BrianKnows MCP 服务器提供三个主要工具：

  1. Ping 工具：检查 BrianKnows API 服务器是否响应

  2. 搜索工具：查询 BrianKnows 知识引擎中的区块链和 DeFi 信息

  3. 代理工具：与 BrianKnows 代理讨论 DeFi 协议

支持的知识库包括：

  • 公共知识框（默认）

  • circle_kb、lido_kb、Polygon_kb、taiko_kb

  • near_kb、clave_kb、starknet_kb、consensys_kb

服务器会保留您最近 5 次搜索的缓存以供快速参考。

先决条件📋

配置⚙️

将其添加到您的 Claude Desktop 配置文件（可通过开发人员设置访问）：

{
  "mcpServers": {
    "brianknows": {
      "command": "npx",
      "args": ["mcp-brianknows"],
      "env": {
        "BRIAN_API_KEY": "your-api-key-here"
      }
    }
  }
}

将your-api-key-here替换为您实际的 BrianKnows API 密钥。

使用示例🎯

Can you check if the BrianKnows API is online?

Use BrianKnows to search for information about Ethereum's Layer 2 solutions.

Ask the BrianKnows agent to explain how Uniswap V3 works.

特色✨

  • 多个知识库：获取不同区块链协议的专业知识

  • 缓存搜索：快速访问您最近的 5 次搜索

  • 错误处理：用户友好的错误消息

  • 类型安全：完整的 TypeScript 实现

致谢🙏

Available Tools

3 tools
agentC

Chat with Brian agent

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYesUser prompt or question
addressNoUser blockchain address (required for blockchain operations)
chainIdNoBlockchain chain ID
kbIdNoKnowledge box ID to use (default: public-knowledge-box)

TDQS

C2/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. 'Chat with Brian agent' suggests an interactive conversation, but it doesn't disclose whether this is a read-only operation, what authentication might be required, rate limits, or what kind of responses to expect. The description provides minimal behavioral context.

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

Conciseness2/5

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

While technically concise with just three words, this is under-specification rather than effective conciseness. The description doesn't earn its place by providing meaningful information - it's too brief to be helpful. A single sentence with actual content would be more appropriate.

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 tool with 4 parameters, no annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, what 'Brian agent' refers to, or how this differs from standard chat interactions. The description fails to compensate for the lack of structured metadata.

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 100% description coverage, so all parameters are documented in the structured schema. The description adds no additional parameter semantics beyond what's already in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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?

The description 'Chat with Brian agent' is a tautology that essentially restates the tool name 'agent' without specifying what the tool actually does. It doesn't distinguish this tool from its siblings (ping, search) and provides no specific verb+resource combination that clarifies the tool's function.

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

Usage Guidelines1/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 its siblings (ping, search) or any alternatives. There's no mention of appropriate contexts, prerequisites, or exclusions for using this tool.

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

pingA

Check if the Brian API server is alive

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/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 behavioral trait of checking server liveness, which is useful context, but does not mention response format, timeout behavior, or error handling. For a zero-parameter tool with no annotations, this is adequate but leaves gaps in operational details.

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 directly states the tool's function with zero waste. It is front-loaded and appropriately sized for a simple tool, making it easy to understand without unnecessary elaboration.

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?

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for its purpose. It clearly defines what the tool does, though it could benefit from slight elaboration on expected outcomes or usage scenarios to enhance agent decision-making.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description does not need to add parameter semantics, as there are no parameters to document, and it appropriately focuses on the tool's purpose without redundant information.

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 specific action ('Check if') and target resource ('Brian API server is alive'), distinguishing it from siblings like 'agent' and 'search' by focusing on health/availability testing rather than data operations. It uses precise language that conveys the exact function without ambiguity.

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

Usage Guidelines4/5

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

The description implies usage context (verifying server status), but does not explicitly state when to use this tool versus alternatives or provide exclusions. It suggests a diagnostic purpose, which gives clear context, but lacks explicit guidance on scenarios like pre-operation checks or troubleshooting steps.

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 observedagent
    • First observedping
    • First observedsearch
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

C2.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: 'agent' is for chatting with an AI agent, 'ping' is for health checking the API server, and 'search' is for querying a knowledge engine. The descriptions make it easy to differentiate these functions, eliminating any risk of misselection.

Naming Consistency3/5

The naming is mixed in style: 'agent' and 'ping' are simple verbs, while 'search' is a verb that could fit a pattern, but there is no consistent verb_noun structure or uniform convention. However, the names are readable and straightforward, avoiding chaotic or confusing formats.

Tool Count3/5

With only 3 tools, the count feels thin for a server named 'BrianKnows MCP Server', which suggests a broader knowledge or interaction domain. While the tools cover basic operations (chat, health check, search), it may lack depth for more complex workflows, making it borderline in scope.

Completeness2/5

The tool surface has significant gaps for a knowledge-oriented server: there is no way to create, update, or manage knowledge entries, and the 'agent' tool lacks clarity on its capabilities beyond chatting. This incompleteness could lead to agent failures when trying to perform comprehensive tasks in the domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches