SuperAPI AI Directory

dragon-knowledge-search

Agents & models

View repository

Updated 10-15 23:26

About this skill

Dragon Knowledge Base Intelligent Search

What problem does this skill solve

In the company's internal development tasks, a lot of key context (architecture, API fields, deployment processes, internal library usage, business rules) exists only in the private knowledge base Dragon and cannot be found on the public internet. By default, Claude will not proactively look it up, so answers can only rely on general knowledge and guesswork, and the results often do not fit the company's actual situation.

This skill makes Claude proactively call the dragon-knowledges exposed by the MCP KnowledgePlugin__knowledge_base_search tool when it determines that "the user is doing internal work," bringing internal context into the answer.

When to trigger retrieval

If any one of the signals below is hit, it is worth searching once.

Trigger signals

  1. Referential signals — the user uses modifiers such as "our," "the company's," "this project's," "internal," "production," etc. to modify the subject
    • "How does our order service handle timeouts"
    • "What is the authentication field of the company's internal gateway"
    • "What is the release process for this project"
  1. Proper noun signals — clear appearances of non-public system names, service names, project code names, internal domain names (such as *.didainternal.com) or abbreviations. Judgment criterion: this term yields no reasonable results when put into Google, or in the context of the dida company it points to a specific internal system.

    • "How to integrate with Dragon-Open-API"
    • "Token refresh mechanism of the internal IAM service"

    dida internal system name quick reference table(seeing any one of them strongly suggests triggering a search):

    Category System Main function
    Account permissions LionKing Account and permission management (functional permissions, data permissions); also takes over third-party platforms
    AI-driven organizational operating system Phoenix Positioned as the enterprise's digital hub, integrating knowledge, talent, collaboration, processes, and security governance, supporting human-machine collaboration and multi-agent collaboration
    AI intelligent platform Dragon Not only a multi-model AI conversation platform, but also an intelligent operations hub, integrating AI capabilities, knowledge management, and business process automation to help enterprises reduce costs and increase efficiency, improve customer experience, and accumulate knowledge assets
    Workflow orchestration Beaver Visual workflow orchestration platform, where users can independently create, debug, publish, and monitor workflows through a drag-and-drop designer
    Business front end Shopping Hotel booking platform for downstream customers (ToB)
    Business front end EBooking Hotel management system + room inventory entry (for upstream suppliers)
    Price and inventory Wolf / Wolf 2.0 Room type price adjustment, CSA online/offline management
    Customer management AngryBirds / CRM Customer relationship management (customer information, sales follow-up, opportunity management)
    Data analysis Analysis / Whale / Whale 2.0 Data analysis system
    Operations Admin Backend management
    Operations Marketing Marketing-related
    Business systems Tiger / Bingo Business systems
    BDS Kangaroo BDS usage
    Finance Finance Financial systems (third-party payment integration, transaction calculation)
    Content Content (content system) Maintain hotel static information, data format mapping
    Deployment and operations Dolphin Deployment, configuration, monitoring (including the dolphin-cms configuration center)
    Monitoring Grafana Monitoring system (dida internal Grafana instance)
    API gateway API channel system Receives Client API requests and calls supplier systems
    API gateway API supplier system (Supplier Service / SS) Accesses upstream Suppliers and returns room type information
    Customer service Customer service system Handles abnormal orders
    In-house switches Penguin / Panda / AutoLine / FalconService / f-operating / f-supplier / f-analysis / f-order / f-policy / f-profit / f-monitor / EBookingBookingAPI In-house services for automatic system switches and process orchestration
    Office environment Wuying / Wuying Alibaba Cloud workspace (used by all employees)

    Note: some names in the table (Tiger, Bingo, Kangaroo, Penguin, Panda, Whale, Dolphin, AngryBirds, Grafana, etc.) are common words on their own, butas long as they appear in an internal development/operations context(followed by verbs or scenario words such as "system"/"launch"/"API"/"configuration"/"permissions"/"canary"/"environment"), they are regarded as strong signals. Although Grafana is an open-source tool, in the context of dida users it basically refers to the internal instance; similarly, Dolphin here refers to the company's deployment system, not the open-source Dolphin Scheduler.

  2. Business/process signals — asking about business rules, product logic, approval flows, alert thresholds, or the meaning of error codes. Such content cannot be found on the public internet.

    • "What is the refund approval process?"
    • "What is the P0 alert threshold?"
  3. API/field signals — asking about the meaning of a certain API field, error code, or callback structure, and the field name is not a standard naming convention in open-source frameworks.

    • "What does status=99 mean in the callback?"
    • "What values can the bizType field of the order placement API have?"
  4. Operations/configuration signals — asking about release processes, canary strategies, configuration items, monitoring configurations, or environment variables, and clearly tied to a specific environment.

    • "How do I configure canary release?" (in an internal context)
    • "What is the collectionId for the test environment?"
  5. Implicit signals — the user is working under an internal code repository (the path contains a company project name, such as Dragon-MCP-Test1), and the code being asked about involves custom middleware, in-house SDKs, or imports that do not look open-source.

Scenarios where it should not be triggered

These are more reliably looked up on the public internet; forcibly searching the internal knowledge base will only waste time and dilute answer quality:

  • General language/framework questions: Python list usage, React hooks principles, Go channel syntax
  • Standard usage of well-known open-source libraries: Spring Boot configuration, Express middleware, MySQL index syntax
  • Pure code style issues: renaming, formatting, extracting functions
  • Algorithms, data structures, mathematics
  • Chit-chat, confirmation questions, polite responses

Boundary judgment

When unsure, lean toward looking it up. one KnowledgePlugin__knowledge_base_search call is cheap; missing a lookup that leads to a wrong or overly vague answer is expensive. If you find yourself asking "could this have some special internal definition?", the answer is most likely yes—so look it up.

How to call

Tell the user first

The user prefers the "say something first, then retrieve" style; don't call silently. Before calling, state your intent in one sentence, for example:

  • "Let me first check the Dragon knowledge base to see if there's any relevant material."
  • "This looks like it involves internal conventions; let me search the knowledge base."
  • "Let me first look up the definition of XXX in the knowledge base."

Reason: let the user know this answer is based on internal materials, so they can trace and judge it.

Calling the tool

Tool name:KnowledgePlugin__knowledge_base_search Only parameter:query(string)

The tool's parameter description states it clearly—"it is recommended to use a complete, explicit question sentence." So don't pass a pile of keywords; pass acomplete question sentence that a human can understand。

How to write the query

Example 1:

  • User's original words: "What does the order callback field status=99 mean"
  • ✅ Good query: "What is the business meaning when the status field value is 99 in the order service callback"
  • ❌ Bad query: "status 99" (too few keywords, poor retrieval matching)

Example 2:

  • User's original words: "How do I configure canary release for this gateway"
  • ✅ Good query: "How to configure a canary release strategy for the internal API gateway"
  • ❌ Bad query: "gateway canary"

Example 3:

  • User's original words: "release process"
  • ✅ Good query: "This project's release and deployment process and operating steps"
  • ❌ Bad query: "release process" (missing subject, retrieval semantics vague)

Look up multiple sub-questions separately

If the user's question contains multiple independent sub-questions (for example, asking about both "field meaning" and "call rate limit" at the same time), call multiple times, one complete question each time. This works much better than cramming all the keywords into one retrieval.

Multi-round retrieval

If the first result isn't enough, search another round based on internal terms that appear in the returned content. For example, if the knowledge base returns a mention of some internal component name but doesn't explain it clearly, ask again using that component name. Don't give up just because the first result isn't ideal.

How to integrate retrieval results into the answer

  • Direct coverage: the retrieval result directly answers the question—cite the key content and indicate "from the Dragon knowledge base" so the user can trace it.
  • Partial coverage: the result covers only part of it—clearly separate "what the knowledge base says" from "general knowledge/reasonable inference";do not package general guesses as internal materials。
  • Not found: explicitly tell the user "no content related to XXX was found in the knowledge base", then answer using general knowledge—don't fail silently and let the user think it was found.
  • Do not fabricate sources: Keep answers and retrieval results traceable; if uncertain, say you are uncertain.

Example

Example 1: Strong signal, trigger directly

User: I'm writing the callback handling for the order service and need to know the meaning of each status value

Claude: "Let me first check the Dragon knowledge base for the definition of the order callback fields." → Call KnowledgePlugin__knowledge_base_search, query="the business meaning of each value of the status field in the order service callback" → Organize the answer based on the returned results and indicate the source

Example 2: General question, do not trigger

User: Write a list deduplication in Python that preserves order

Claude: Provide the code directly, do not call the knowledge base (this is a general programming question, public knowledge is sufficient).

Example 3: Implicit signal, trigger

User: Help me add a callback handler in d:/downloads/Dragon-MCP-Test1/order_service.py add a callback handler in

Claude: The path contains an internal project name, and it is a task like "add a handler" that is strongly related to project conventions. "Let me first check the Dragon knowledge base for the handler writing conventions in this project." → Call retrieval query="the implementation specifications and interface conventions for the order service callback handler in this project" → Then write the code

Example 4: Multiple sub-questions, query separately

User: What is the authentication mechanism of this internal gateway? Also, how do I configure the QPS limit?

Claude: "This involves two questions about internal conventions; I'll check them separately." → First query="the authentication mechanism and token verification process of the internal API gateway" → Second query="the QPS rate limiting configuration method of the internal API gateway" → Answer by combining the two results

Example 5: Boundary scenario, lean toward querying

User: Write a retry decorator

Claude: On its own this is a general question, but the user is working in an internal project directory. "Let me first check whether the Dragon knowledge base has a unified internal retry specification—if so, write according to the specification." → Call query="the unified retry mechanism specifications and best practices of this project or the company" → If found, write according to the specification; if not found, provide a general implementation and explain "the knowledge base did not find a unified specification, so it is implemented in a general way"

Debugging and failure handling

  • If dragon-knowledges MCP is unavailable (connection failure/timeout), tell the user "the knowledge base is currently inaccessible, so I will answer using general knowledge first," then answer as usual—do not refuse the task just because MCP is down.
  • If the retrieval results are completely irrelevant (noise), try again with a more specific query; do not directly discard the entire retrieval.
  • If the user explicitly says "no need to check the knowledge base" or "answer directly," follow the user's intent and skip it this time.