Which integrations are available for this server?

Provides tools for searching and retrieving algorithm implementations from the TheAlgorithms organization on GitHub across multiple programming languages.

How do I use io.github.mcande21/thealgorithms-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., "@io.github.mcande21/thealgorithms-mcp search dijkstra algorithm in python" 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.

io.github.mcande21/thealgorithms-mcp

by mcande21

Overview Schema Related Servers Score Discussions

Python

Remote

thealgorithms-mcp

mcp-name: io.github.mcande21/thealgorithms-mcp

An MCP server for querying the TheAlgorithms org across every language repo — search algorithm implementations and fetch any one with its in-file examples.

Languages are auto-discovered from the org (not a hardcoded list): a repo is indexed when it publishes a parseable DIRECTORY.md — currently 24 languages (Python, Java, C++, JavaScript, Rust, C, TypeScript, PHP, Dart, Kotlin, Ruby, R, Scala, Swift, Julia, Haskell, MATLAB, Zig, Fortran, Nim, Clojure, F#, Jule, aarch64-assembly). Repos without a DIRECTORY.md (Go, C#, Lua, Solidity, …) are reported by list_languages with their exclusion reason — no silent gaps.

Hybrid design: each repo's DIRECTORY.md index is cached locally (ETag + TTL); file contents are fetched on demand from raw.githubusercontent.com. The org/language manifest is auto-discovered via the GitHub API and cached 7 days. No token required (set GITHUB_TOKEN to raise the rate limit). See DESIGN.md.

Tools

Tool	Purpose
`list_languages()`	Indexed languages (+ counts, aliases) and excluded repos with reasons
`list_categories(language='python')`	Categories with entry counts for a language
`search_algorithms(query, language='python', category?, limit=10)`	Ranked `{name, category, path, score}`
`get_category(category, language='python')`	Every algorithm in a category
`get_algorithm(path, language='python', include_source=True)`	Source + extracted examples
`compare(name, languages?, min_score=90, limit_per_language=1)`	Real matches across languages + `missing_in`
`suggest(prefix, language='python', limit=10)`	Trie-backed name autocomplete (`dij` → Dijkstra)

language accepts names or aliases (cpp/c++, js, ts, …). Typical flow: search_algorithms("dijkstra", language="rust") → get_algorithm("src/graph/dijkstra.rs", language="rust"). Examples are extracted where the language has an in-file convention (Python doctests, Rust doc-tests); other languages return source plus a note.

Related MCP server: Zoekt MCP Server

Install

From PyPI (recommended):

{ "thealgorithms": { "command": "uvx", "args": ["thealgorithms-mcp"] } }

From GitHub:

{ "thealgorithms": {
    "command": "uvx",
    "args": ["--from", "git+https://github.com/mcande21/thealgorithms-mcp", "thealgorithms-mcp"] } }

From a local checkout (development):

uv sync
uv run thealgorithms-mcp          # serves over stdio

Add any of the above to ~/.normandy-generic/mcp.json (or your MCP client config).

Verify

uv run python scripts/verify_stdio.py                 # multi-language contract over stdio
uv run python scripts/verify_language.py rust         # one language, end-to-end

The harness spawns the server over stdio and asserts every tool against the live org, including binary-search fetch across ≥8 languages and cross-language compare().

Available Tools

7 tools

compareA

Find the same algorithm across languages — returns only REAL matches.

A per-language search scores 100-200 for a genuine match and well below for "nearest unrelated thing", so results are filtered to score >= min_score (default 90). Languages with no real match are listed in missing_in, so you can see at a glance which languages implement an algorithm and which don't. languages defaults to all indexed; pass a subset to narrow.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes
`languages`	No
`min_score`	No
`limit_per_language`	No

TDQS

A4.5/5.0

Behavior4/5

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

Despite no annotations, the description reveals internal scoring mechanism (100-200 for real match, filtered by min_score) and output structure (missing_in). It does not mention any side effects or prerequisites.

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 concise, well-structured, and free of extraneous information. It starts with the core purpose, then provides necessary detail in subsequent sentences.

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?

The description adequately covers behavior for a 4-parameter tool without output schema, though limit_per_language could be more explicitly defined. Overall, it gives sufficient context for proper invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining the meaning and defaults of all parameters: name, languages (defaults to all), min_score (default 90), and limit_per_language (default 1).

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 states the specific verb 'Find' and resource 'the same algorithm across languages', clearly distinguishing it from sibling tools like search_algorithms (which searches for algorithms) and list_languages (which lists languages).

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 explains the intended use case: comparing an algorithm across languages. It details the scoring filter and default behavior, but lacks explicit when-not-to-use or alternative tool references.

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

get_algorithmA

Fetch one algorithm by language + repo-relative path (e.g. path='sorts/merge_sort.py').

Returns {language, path, github_url, description, examples, line_count, source?}. Examples are extracted where the language has an in-file convention (Python doctests, Rust doc-tests), otherwise empty with a note. Set include_source=False for a cheap peek.

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`language`	No	python
`include_source`	No

TDQS

A3.9/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It explains that examples may be empty with a note if no inline convention exists, and mentions performance trade-off with include_source. However, it does not explicitly state it's read-only or discuss permissions/rate limits.

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 two sentences and relatively concise, though the second sentence is somewhat lengthy. It front-loads the main action and adds relevant detail without fluff.

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, the description lists return fields and notes potential emptiness of examples. It covers parameter usage tips and return variability, but could mention valid language values or error conditions for a fetch with missing path.

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 0%, so description must explain parameters. It explains path with example and include_source with usage tip, but the language parameter is only implied via 'by language' and not explicitly described with valid values or format.

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 fetches one algorithm by language and repo-relative path, with an example path. It distinguishes from sibling tools like list_languages or search_algorithms by focusing on a single fetch operation.

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 provides a usage tip (set include_source=false for cheap peek) but does not explicitly contrast when to use this tool vs. search_algorithms or list_categories. It implies usage for specific path lookup but lacks exclusion criteria.

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

get_categoryA

List every algorithm in one category (for a language) as {name, path}.

ParametersJSON Schema

Name	Required	Description	Default
`category`	Yes
`language`	No		python

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It discloses the output format ({name, path}) but does not mention ordering, pagination, or other behavioral traits. Adequate but minimal.

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?

Single sentence, no filler, front-loaded with key information. Every word adds value.

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 2 params, no enums, and presence of output schema, the description covers the core function but lacks mention of prerequisites (e.g., need to know categories) or error handling. Adequate for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description only mentions 'for a language' but does not explain the category parameter or default language behavior. It adds some context but fails to compensate for missing schema descriptions.

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 lists every algorithm in a category (for a language) as {name, path}. This is specific and distinguishes from sibling tools like list_languages and search_algorithms.

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 to list all algorithms in a category/language, but does not explicitly state when to use this vs alternatives like search_algorithms or list_categories.

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

list_categoriesA

List the algorithm categories with entry counts for a language (default: python).

ParametersJSON Schema

Name	Required	Description	Default
`language`	No		python

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

The description discloses the core behavior (listing categories with counts) and the language parameter. With no annotations, it doesn't add extra context like read-only nature, performance, or response structure, but for a simple list operation this is adequate.

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 concise sentence that conveys all necessary information without redundancy. It is efficiently structured.

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 simplicity (one optional parameter, a list operation, and an output schema present), the description is complete enough. It covers what the tool does and the parameter's purpose.

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?

The parameter 'language' has no description in the schema (0% coverage), but the description clarifies its role and default value. This adds meaningful context beyond the schema.

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 ('list'), the resource ('algorithm categories'), the additional detail ('with entry counts'), and the parameter ('for a language'). It distinguishes from siblings like 'list_languages' and 'get_category' by specifying that it returns categories with counts.

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 provides clear context on when to use this tool: when you need a list of algorithm categories along with entry counts, optionally filtered by language. However, it does not explicitly mention when not to use it or name alternative tools.

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

list_languagesA

List indexed languages (auto-discovered from the TheAlgorithms org) and excluded repos.

Returns {languages: [{language, repo, count, aliases}], excluded: [{repo, reason}]}. Use a returned language (or any alias) with the other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

Describes output shape and source, but does not explicitly state read-only nature or any side effects. Without annotations, more transparency would be beneficial.

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 front-loaded sentences plus a clear return format block. Every sentence adds value, no wasted words.

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?

Covers what the tool does, output shape, and usage hint. Lacks mention of pagination or limits, but acceptable for a simple list 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, schema coverage 100%. Description adds value by explaining output structure and usage beyond schema.

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?

Clear verb 'List' with specific resource 'indexed languages' and context 'auto-discovered from the TheAlgorithms org'. Differentiates from sibling list_categories.

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?

Says to use returned language with other tools, which is helpful. Does not explicitly contrast with list_categories or other alternatives.

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

search_algorithmsA

Search one language's algorithms by name/topic. Returns ranked {name, category, path, score}.

Feed a returned path (with the same language) to get_algorithm. language defaults to python and accepts aliases (cpp, js, ts, c++, ...). See list_languages.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`category`	No
`language`	No	python

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It describes the search behavior, return format (ranked results with fields), and chaining mechanism. Missing details on rate limits or edge cases, but sufficient for a search tool.

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?

Three concise sentences covering purpose, output, and usage hints. No redundant information, every sentence adds value.

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 4 parameters and existing output schema, description covers key behavioral aspects (search, result structure, chaining). Minor gaps on limit and category, but overall complete for a tool with output schema.

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?

Schema coverage is 0%, yet description adds meaning: explains query as search term, language defaults/aliases, and path usage. Does not detail limit or category, but provides enough context for typical use.

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 explicitly states it searches algorithms by name/topic and returns ranked results with specific fields. It distinguishes from siblings like list_languages and get_algorithm by specifying search functionality and chaining.

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 provides clear usage context: search algorithms by query, default language, aliases, and chaining with get_algorithm. However, it does not explicitly state when not to use this tool (e.g., for listing categories) but implies it via sibling references.

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

suggestA

Autocomplete algorithm names by prefix (Trie-backed typeahead).

Matches the start of the name or any word: 'dij' -> Dijkstra, 'search' -> Binary Search. Returns up to limit {name, category, path}. Fast O(prefix-length) lookup.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`prefix`	Yes
`language`	No	python

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses performance (O(prefix-length)) and return structure ({name, category, path}) but does not mention safety, idempotency, or side effects. Given the tool's nature, this is sufficient.

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?

Three sentences with no waste. First sentence states purpose and implementation, second gives examples, third states return format and performance. Front-loaded and efficient.

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 existing output schema (not shown) and no annotations, description covers purpose, behavior, performance, and return fields. Missing explanation of language parameter and explicit differentiation from search_algorithms, but overall complete.

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 0%, so description compensates partially. It explains prefix matching rules and limit cap, but does not describe the language parameter at all. Language defaults to 'python' but its effect is unclear.

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 uses specific verb 'Autocomplete' and resource 'algorithm names by prefix'. It distinguishes from siblings like search_algorithms by focusing on prefix matching and typeahead. Examples clarify the intent.

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 provides clear context for when to use (prefix-based autocomplete) and gives concrete examples. However, it does not explicitly exclude usage or mention alternatives like search_algorithms for full-text search.

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.

7 tool updatesv0.3.1Jul 30, 2026
- First observedcompare
- First observedget_algorithm
- First observedget_category
- First observedlist_categories
- First observedlist_languages
- First observedsearch_algorithms
- First observedsuggest

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool serves a distinct purpose: listing languages, listing categories, searching algorithms, getting category contents, fetching algorithm details, cross-language comparison, and autocomplete. No functional overlap.

Naming Consistency4/5

Most tools follow a verb_noun pattern (list_languages, get_algorithm, etc.). 'compare' is a single verb without a noun, creating a minor inconsistency, but the meaning is clear.

Tool Count5/5

Seven tools is well-scoped for an algorithms exploration server. Each tool adds distinct value without redundancy or bloat.

Completeness4/5

The toolset covers browsing (languages, categories), searching, fetching details, and cross-language comparison. Missing an endpoint to list all algorithms across languages, but the existing tools enable a coherent workflow.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

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

gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
mcpOAuth
com.bullpenstrategygroup.rotunda
An MCP server that provides congressional transcripts
Government Data Search Open Data
2

Related MCP Servers

Code Context MCP Server
Vector Databases Version Control Search
fkesheh
A
license
Not graded
quality
D
maintenance
An MCP server that provides semantic search over local git repositories, enabling users to clone repositories, process branches, and search code through vectorized code chunks.
Updated 10 months ago (2025-11-13 14:04 UTC)
25
MIT
Zoekt MCP Server
Code Analysis Search
najva-ai
A
license
Not graded
quality
D
maintenance
An MCP server that provides code search capabilities for AI tools and LLMs using Zoekt, allowing for searching across codebases with advanced query syntax and content fetching.
Updated 9 months ago (2025-11-25 10:07 UTC)
22
MIT
Repo Docs MCP
Developer Tools Documentation Access Version Control
pepperfm
A
license
Not graded
quality
D
maintenance
A generic MCP server that exposes local repository checkouts, allowing users to search and read code and documentation through natural language. It supports multiple instances, enabling seamless interaction with various codebases via configurable tool prefixes and URI schemes.
Updated 6 months ago (2026-02-27 10:40 UTC)
2,013
MIT
@codesift/mcp
Developer Tools Code Analysis Search
rutvikchandla3
A
license
Not graded
quality
B
maintenance
MCP server for local-first lexical code search, providing tools for searching code, finding symbols, and reading chunks from indexed repositories.
Updated 2 months ago (2026-06-26 13:19 UTC)
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/mcande21/thealgorithms-mcp'

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