How do I use Cortex MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cortex MCP search for error handling patterns" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Cortex MCP

by BasharAmso

Overview Schema Related Servers Score Discussions

TypeScript

Cortex MCP

npm version License: MIT

A knowledge delivery engine that ships with a built-in library of 728 agents, skills, patterns, and examples across 26 domains — and serves them on-demand to any MCP-compatible AI tool.

Instead of every project loading its own framework files into context (wasting 90%+ of the token budget), Cortex MCP is installed once and feeds the right knowledge to any project that needs it.

Setup

Two steps. Copy-paste each line into your terminal.

Step 1 — Install it:

npm install -g cortex-mcp-server

Don't have Node.js? Download it from nodejs.org (pick the LTS version). Then come back and run the line above.

Step 2 — Connect it to your AI tool:

claude mcp add -s user cortex -- cortex-mcp-server

Restart Claude Code. Done.

Open Cursor
Go to Settings (gear icon) > MCP
Click Add new MCP server
Name: cortex | Command: cortex-mcp-server

Or paste this into ~/.cursor/mcp.json if you prefer:

{
  "mcpServers": {
    "cortex": {
      "command": "cortex-mcp-server"
    }
  }
}

Open Windsurf
Go to Settings > MCP Servers
Add a new server with command: cortex-mcp-server

These tools support MCP via a JSON config file. Add Cortex to your MCP config:

{
  "mcpServers": {
    "cortex": {
      "command": "cortex-mcp-server"
    }
  }
}

Check your tool's docs for the config file location.

Cortex MCP uses stdio transport. Any tool that can launch an MCP server via command line works:

Command: cortex-mcp-server
Transport: stdio
No API keys or config required

If your tool asks for a server URL instead of a command, it expects HTTP transport which Cortex doesn't support (by design — stdio is more secure).

That's it. Now just work normally. Your AI tool will pull knowledge from the library when it needs it. You can also ask directly:

"Search for error handling patterns"
"Find the authentication skill"
"Show me how to set up Stripe payments"
"What agents are available?"

Related MCP server: SkillHub MCP

How It Works

flowchart TB
    User["You (any AI tool)"]

    subgraph Client["Your AI Tool (any MCP client)"]
        Bashi["Bashi (Standalone or Lite)"]
        Claude["Claude Code"]
        Cursor["Cursor"]
        Windsurf["Windsurf"]
        Others["Cline · Continue · Zed\nCopilot · Codex · any MCP client"]
    end

    MCP{"Cortex MCP\nconnected?"}

    subgraph Cortex["Cortex MCP — Knowledge Library"]
        Fragments["728 Fragments"]
        Pillars["26 Domain Pillars"]
    end

    NoMCP["Works without Cortex\n(no knowledge grounding)"]

    User --> Client
    Client --> MCP
    MCP -->|Yes| Cortex
    MCP -.->|No| NoMCP
    Fragments --- Pillars

    style Client fill:#e8f4fd,stroke:#2196f3,color:#000
    style Cortex fill:#e8f5e9,stroke:#4caf50,color:#000
    style MCP fill:#fff3e0,stroke:#ff9800,color:#000
    style NoMCP fill:#e0e0e0,stroke:#666,stroke-dasharray: 5 5,color:#000

Your AI tool calls search_knowledge and get_fragment via MCP. Cortex returns the right knowledge for the task. Your project repos stay lightweight.

Fragments load on demand. If you're building a game, Cortex only serves game-dev patterns when you ask for them. Salon booking examples never touch your context window unless you search for them. Use the budget parameter on search_knowledge to control how much context each search returns — the default keeps responses lean, increase it when you need deeper reference material.

For the full architecture, see docs/ARCHITECTURE.md.

What's inside

resources/
├── agents/      10 agent definitions
├── skills/     443 skill procedures
├── patterns/   225 reusable patterns
└── examples/    50 code examples

For Skill Authors

Skills define what to do. Cortex provides what to know.

Any skill -- in Claude Code, Cursor, Copilot, or custom agents -- can call Cortex mid-execution to ground its output in validated patterns:

search_knowledge("auth patterns", category="patterns") -- find relevant knowledge
get_fragment("PAT-0042") -- pull the full pattern into context
Apply the pattern alongside the skill's own procedure

Your skills get smarter without getting longer. The knowledge stays in Cortex, versioned and searchable, instead of duplicated across every skill file.

Bashi v3.2.0 includes three reference implementations: backend-dev, security-audit, and ai-feature each have a ## Knowledge Enhancement (MCP mode) section showing this pattern in practice.

What's in the Library

Category	Count	Examples
Agents	10	Builder, Reviewer, Architect, Product Manager, Designer, Fixer, Deployer
Skills	443	CRM, Lead Scoring, Market Sizing, LinkedIn Strategy, Salon Booking, Restaurant POS, Code Review, Debugging, Game Physics, Level Design, E-Commerce, IoT, Healthcare, Finance, Education
Patterns	225	Error Handling, API Design, Circuit Breaker, Saga, Cart State, Checkout Recovery, Appointment Booking, POS Architecture, CRM Data Model, Inventory Tracking, Achievement System
Examples	50	Phaser Game, ECS, Product Catalog, Checkout, API Gateway, Circuit Breaker, MVP Landing Page, A/B Testing, CRM Pipeline, Salon Booking, Online Course, IoT Dashboard, Competitor Analysis, Prayer Times, Go Server, Web Scraper, Kanban Board, and more

Every fragment includes synonyms for natural language matching. Ask "how do I add logins" and it finds the authentication pattern. Ask "my app is slow" and it finds the performance skill. Ask "how do I grow on LinkedIn" and it finds the LinkedIn strategy skill.

26 Knowledge Pillars

Pillar	Fragments	What's Covered
Software Dev	78	Error handling, APIs, testing, security, DevOps, CI/CD
Framework Core	31	Agents, orchestration, quality review, deployment
Frontend	30	React, state management, testing, performance, i18n, security
UX Design	30	Usability testing, design systems, accessibility, prototyping
Architecture	30	API gateways, message queues, caching, serverless, GraphQL
App Polish	30	Loading states, animations, keyboard shortcuts, feature flags
E-Commerce	30	Product catalogs, checkout, shipping, subscriptions, fraud prevention
Game Dev	30	Physics, audio, level design, multiplayer, procedural generation
Education	30	Course platforms, flashcards, grading, adaptive learning, AI tutoring
Coding Literacy	30	Reading code, code review, debugging, understanding abstractions
Business Automation	30	Salon booking, POS systems, invoicing, scheduling, loyalty programs
Sales	30	CRM, lead scoring, pipeline management, cold outreach, forecasting
Market Research	30	Competitor analysis, market sizing, surveys, trend analysis
Personal Brand	30	LinkedIn, newsletters, podcasting, speaking, community building
Product Business	30	MVP strategy, pricing, A/B testing, metrics, churn prevention
Content Creation	30	Writing, copywriting, YouTube, newsletters, AI-assisted creation
Platform	30	SwiftUI, Compose, Flutter, Vue, Svelte, Angular, Next.js
Health	15	Telehealth, FHIR, mental health apps, wearables, medication tracking
Finance	15	Personal finance, banking APIs, portfolios, tax engines, billing
Collaboration	15	Wikis, project management, video conferencing, team chat
Religious	15	Prayer times, scripture readers, donations, devotionals, sermons
IoT	15	Edge computing, MQTT, dashboards, smart home, industrial IoT
Developer Growth	15	Technical writing, open source, career growth, interview prep
Language	15	Java, C#, Swift, Kotlin, PHP, Ruby, concurrency patterns
Automation	15	Web scraping, browser automation, data pipelines, chatbots
Domain-Specific	15	Legal tech, construction, agriculture, logistics, event management

Features

728 built-in fragments across 26 domains — agents, skills, patterns, and code examples
Pillar filtering — filter by domain (e.g., game-dev, ecommerce, sales, coding-literacy)
Synonym matching — finds fragments even when you use informal language
Three-tier search — quick cache (~2ms), pre-built index (~5-10ms), fuzzy fallback (~15-20ms)
Token budgeting — respects context limits with four output modes
Zero-result recovery — suggests alternatives when nothing matches exactly
Stack detection — detect_project tool identifies your stack and suggests relevant searches
Works with any MCP client — Claude Code, Cursor, Windsurf, and others
Zero cost — no cloud, no API keys, runs locally

MCP Tools

Tool	Description
`search_knowledge`	Natural language search with mode, budget, and category filters
`get_fragment`	Retrieve a fragment by ID with dependency and related notes
`browse_library`	Browse all fragments or filter by category
`list_categories`	List categories and fragment counts
`detect_project`	Detect your project's stack and get suggested searches
`search_metrics`	View diagnostic search metrics (tier rates, zero-results, top fragments)

Output Modes

Mode	What you get	Use when
`index`	IDs and names only	Quick overview
`minimal`	JSON metadata + URIs	Default — good balance
`catalog`	Full metadata, no content	Browsing before loading
`full`	Complete markdown content	Ready to use

Configuration (optional)

Create cortex.config.json in your project root if you want to customize:

{
  "customDirectories": ["./my-knowledge"],
  "matching": {
    "maxResults": 10,
    "defaultMode": "minimal",
    "defaultBudget": 4000
  }
}

Defaults work out of the box. Most users don't need a config file.

Writing Your Own Fragments

See docs/FRAGMENT-AUTHORING-GUIDE.md for the complete guide.

Quick version: create a markdown file with YAML frontmatter in any configured directory:

---
id: SKL-CUSTOM-001
name: My Custom Skill
category: skills
tags: [my-tag, another-tag]
capabilities: [what-it-can-do]
useWhen:
  - when to use this skill
synonyms: ["informal way to ask for it", "another way to ask"]
estimatedTokens: 500
lastUpdated: "2026-03-29"
difficulty: intermediate
relatedFragments: []
dependencies: []
---

# My Custom Skill

Content here...

Development

npm install         # Install dependencies
npm run dev         # Dev mode (hot reload)
npm run build       # Build
npm run build-index # Rebuild search indexes
npm test            # Run tests
npm run typecheck   # Type check

Troubleshooting

"command not found" after install? Close and reopen your terminal. If it still doesn't work, try npx cortex-mcp-server instead.

Not seeing results? Restart your AI tool after adding the MCP config. Changes only take effect on restart.

Wrong fragments returned? Try broader search terms. Use browse_library to see everything available.

Contributing

See CONTRIBUTING.md for how to set up locally, submit fragments, and open pull requests.

About

Built by Bashar Amso. I got tired of loading the same framework files into every project and burning through my token budget before asking my first question. Cortex MCP fixes that.

Part of the Bashi ecosystem.

Acknowledgments

This library was built by researching patterns from hundreds of open-source projects, technical documentation, and community best practices. We're grateful to the open-source community whose shared knowledge made this possible.

License

MIT

Available Tools

6 tools

browse_libraryA

List all available knowledge fragments, optionally filtered by category (skills, patterns, agents, examples) or domain pillar (e.g. game-dev, ecommerce). Use to discover what knowledge exists before searching.

ParametersJSON Schema

Name	Required	Description	Default
`pillar`	No	Filter to a specific pillar/domain (e.g., 'game-dev', 'ecommerce', 'architecture')
`category`	No	Category to browse, or 'all' for everything (default: all)

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It correctly implies a read operation but does not disclose pagination, response format, or any rate limits. Adequate but not rich.

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?

Two sentences front-load the core action and optionality, with zero redundancy. Every sentence serves a purpose.

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?

For a simple list tool with 2 optional params and no output schema, the description is complete enough to guide an agent. It explains purpose, filters, and use case. Could hint at return format but acceptable.

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% for both parameters. Description adds example values (e.g., 'game-dev', 'skills') but does not significantly extend beyond what the schema's description already provides. Baseline 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?

Description uses specific verb 'List' and resource 'knowledge fragments', with clear optional filters for category and pillar. It distinguishes from siblings like search_knowledge by positioning itself as a discovery tool.

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?

Explicitly states 'Use to discover what knowledge exists before searching', implying when to use it (discovery) and hinting at the alternative search_knowledge for targeted queries. Could be more explicit about when not to use.

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

detect_projectA

Analyze a list of project root filenames to detect the tech stack and suggest relevant knowledge searches. Use at project start to auto-scope knowledge to the right domains.

ParametersJSON Schema

Name	Required	Description	Default
`files`	Yes	List of filenames in the project root (e.g., package.json, requirements.txt, Cargo.toml)

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries burden. It states analysis and suggestion of searches but omits details like output format or side effects, leaving some ambiguity.

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?

Two focused sentences with zero fluff: first explains function, second gives usage context. Excellent structure.

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?

Adequately covers purpose and input for a simple tool. No output schema, but description implies suggestion result; slight gap in explaining return value format.

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% with a descriptive parameter. The tool description reinforces usage but adds no new semantic detail beyond the schema's description.

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 detects tech stack from project filenames and suggests knowledge searches, distinct from sibling tools like search_knowledge or browse_library.

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?

Explicitly says to use at project start for auto-scoping, which provides clear context. However, no exclusions or alternatives mentioned, though siblings are distinct.

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

get_fragmentA

Retrieve the full content of a specific knowledge fragment by ID (e.g. SKL-0001, PAT-0042). Use after search_knowledge returns relevant results and you need the complete procedure, pattern, or example.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Fragment ID (e.g., SKL-0001, AGT-0003)

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description must cover behavioral traits. It describes a read operation (retrieve full content) with no destructive side effects. A simple get-by-ID operation is well explained, though it does not mention error handling or permission needs.

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?

Two concise sentences: first states purpose and method, second gives usage context. No unnecessary details, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers what it does, how to use it, and its relation to siblings. No gaps given the tool's simplicity.

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?

Only one parameter 'id' with schema already providing description and examples. The description adds no new semantic information beyond the schema, so baseline score of 3 applies due to 100% schema coverage.

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 verb 'retrieve', the resource 'knowledge fragment', and the method 'by ID'. Examples of IDs are provided, and it distinguishes from sibling search tools.

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

Usage Guidelines5/5

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

Explicitly tells to use after search_knowledge returns results, providing clear when-to-use guidance and what the tool offers (complete procedure, pattern, or example).

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

list_categoriesA

Show all categories and domain pillars with fragment counts. Use to understand library coverage and available filtering options.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description must bear the burden. It describes output (categories and fragment counts) but does not discuss side effects, read-only nature, or other behavioral aspects. Adequate but not detailed.

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?

Two sentences, front-loaded with action, no wasted words. Every part earns its place.

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 no output schema and no parameters, the description adequately covers what the tool does and its purpose. Lacks details like pagination, but that is acceptable for a simple enumeration tool.

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?

No parameters, baseline 4. The description adds meaning beyond the empty schema by explaining what the tool returns, fulfilling its role.

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 shows categories and domain pillars with fragment counts, which specifies the action and resource. It distinguishes from siblings like search or get, but does not explicitly differentiate.

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?

Explicitly suggests using it to understand library coverage and filtering options, providing clear context. No exclusions or alternatives are mentioned, but the guidance is sufficient.

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

search_knowledgeA

Search 735 knowledge fragments across 26 domains for validated patterns, skill procedures, and implementation examples. Use before writing code, designing architecture, or reviewing work to ground your approach in battle-tested practices.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Output detail level (default: minimal)
`query`	Yes	Natural language search query
`budget`	No	Token budget limit (default: 4000)
`pillar`	No	Filter to a specific pillar/domain (e.g., 'game-dev', 'ecommerce', 'architecture')
`category`	No	Filter to a specific category

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description must cover behavioral aspects. It mentions scope (735 fragments, 26 domains) and content types, but lacks details on output format, pagination, or side effects. Adequate but not thorough.

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?

Two well-structured sentences. First sentence defines the action and scope; second provides usage context. No wasted words, front-loaded with key 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?

Provides overall context about the knowledge base and when to use. Missing details on output structure (e.g., result format, pagination) and default parameter values. Adequate but could be more complete for a tool with 5 parameters and no output schema.

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 covers 100% of parameters with descriptions. The description does not add additional meaning to parameters; it only provides context for the knowledge base content. Baseline is 3 due to high schema coverage.

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 it searches a knowledge base of 735 fragments across 26 domains for patterns, procedures, and examples. It differentiates from sibling tools like get_fragment and browse_library by focusing on search.

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?

Explicitly recommends use before coding, designing architecture, or reviewing work. However, it does not mention when not to use or suggest sibling alternatives like browse_library for exploration.

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

search_metricsA

View diagnostic search metrics: query counts, tier resolution rates, zero-result frequency, and top-10 most retrieved fragments. Use to understand search quality and inform optimization decisions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It describes tool as 'view' (read-only) and lists outputs, but does not disclose performance, data freshness, or any limitations. Adequate but not thorough.

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?

Two sentences, front-loaded with action and details, then usage guidance. No unnecessary words; every sentence earns its place.

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?

No output schema or annotations. Description covers metrics and purpose but omits time range of data, criteria for top-10, and output structure. Adequate for a simple tool but leaves gaps.

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?

No parameters defined; schema has zero properties. Baseline for 0 params is 4. Description adds no param info, which is acceptable.

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?

Description clearly states it views diagnostic search metrics and lists specific data types (query counts, tier resolution rates, zero-result frequency, top-10 fragments). Differentiates from sibling tools like search_knowledge and browse_library.

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?

Explicitly says 'Use to understand search quality and inform optimization decisions', providing clear context. Lacks explicit when-not-to-use or alternatives, but the context is strong enough.

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. Dates show when Glama detected each change.

6 tool updatesv0.6.1Jul 24, 2026
- First observedbrowse_library
- First observeddetect_project
- First observedget_fragment
- First observedlist_categories
- First observedsearch_knowledge
- First observedsearch_metrics

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool serves a unique, clearly defined purpose: search, retrieval, browsing, project detection, category listing, and metrics. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent 'verb_noun' pattern (e.g., search_knowledge, get_fragment), making the API predictable and easy to learn.

Tool Count5/5

With 6 tools, the server is well-scoped for a knowledge management service. Each tool is essential, covering discovery, retrieval, and analysis without bloat or deficiency.

Completeness5/5

The tool surface covers the full knowledge workflow: project detection, library browsing, searching, fragment retrieval, category overview, and search analytics. No obvious gaps exist for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

SkillDBOAuth
io.github.devchad-cmd
A registry of 5,900+ peer-authored skills any MCP agent can search and load on demand.
Agent Orchestration Search
2
mcpOAuth
ai.zine
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
Knowledge & Memory RAG Systems Autonomous Agents
2
skills-hub A
io.github.tinh2
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
Autonomous Agents AI & Machine Learning Search
42
lorg-mcp-server A
io.github.LorgAI
Shared, peer-validated knowledge archive for AI agents — search, contribute, and validate via MCP
Knowledge & Memory Search
2624

Related MCP Servers

Librarian
Knowledge & Memory Search RAG Systems
arcadeai-labs
A
license
Not graded
quality
A
maintenance
Provides AI agents with persistent knowledge storage, enabling them to store, search, and retrieve text, documents, and files using semantic and keyword search via MCP tools.
Updated a month ago (2026-07-28 12:51 UTC)
32
Apache 2.0
SkillHub MCP
Search Developer Tools
artuntan
A
license
A
quality
C
maintenance
Enables AI assistants to search, discover, and get recommendations from 20,000+ skills, tools, agents, rules, and MCP servers.
Updated 2 months ago (2026-07-15 20:00 UTC)
5
26
1
MIT
Skill7
Developer Tools AI & Machine Learning Knowledge & Memory
Abderraouf-yt
A
license
A
quality
D
maintenance
Provides 634+ curated production-ready AI skills for any MCP-compatible client, covering areas like security, frontend, backend, infrastructure, AI/ML, and architecture. Enables AI agents to access best practices, patterns, and solutions across multiple domains.
Updated 7 months ago (2026-02-07 10:40 UTC)
6
12
1
MIT
context-book
Knowledge & Memory Search
aditya201551
A
license
Not graded
quality
D
maintenance
Provides AI agents with a persistent, searchable knowledge library via MCP tools, allowing them to create books, manage pages, perform semantic search, and retrieve usage guides.
Updated 3 months ago (2026-06-06 16:43 UTC)
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/BasharAmso/cortex-mcp'

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