fossick-mcp

by Lipdog

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation5/5
Each tool has a distinct purpose: find_symbol finds definitions, get_file reads files, list_tags lists releases, repo_tree shows directory structure, search_code searches code, search_packages queries package registries, and search_repos discovers repositories. No overlap in functionality.
Naming Consistency5/5
All tool names follow the verb_noun pattern with snake_case: find_symbol, get_file, list_tags, repo_tree, search_code, search_packages, search_repos. The naming is uniform and predictable.
Tool Count5/5
With 7 tools, the set is well-scoped for a code exploration server. It covers the core tasks of finding, reading, searching, and browsing code and repositories without being bloated or sparse.
Completeness4/5
The tool surface is largely complete for read-only exploration: symbol lookup, file reading, directory browsing, tag listing, and three types of search (code, packages, repos). Missing are operations like viewing commit history or blaming, which are secondary to the server's focus.
Average 4.6/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly/ idempotent behavior. Description adds key behavioral details: truncation of files over 500 lines, line range slicing, and match filtering with context lines. No contradictions with annotations.
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 primary purpose and features, then usage guidance. Every sentence carries essential information with no redundancy.
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?
With 7 parameters and no output schema, description adequately covers core functionality, truncation, match filtering, and usage context. Could be slightly more detailed on response structure (e.g., metadata), but sufficient for an agent.
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 100% so baseline is 3. Description adds value by explaining how parameters work together (e.g., truncation avoidance via range/match) and mentions line numbers in output, which is not in 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?
Clearly states 'Read file content from one file in a GitHub repository', specifying verb and resource. Distinguishes from siblings by advising to use after search_code, find_symbol, or repo_tree, making its unique role explicit.
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?
Provides explicit context for when to use ('after locating a file via search_code, find_symbol, or repo_tree') and mentions truncation behavior that guides usage. Lacks explicit 'do not use' scenarios, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds depth control, glob filtering, size option, and noise directory filtering, which are behavioral traits beyond annotations.
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 the main purpose, no filler. 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?
No output schema, but description implies the return type (file tree). Purpose and features are well covered. Could mention output format briefly, but not necessary given tool 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?
Schema coverage is 100%, so baseline is 3. Description mentions depth, pattern, and show_sizes but not repo or ref. It adds context about noise filtering, which is behavioral, not parameter-specific. Adequate but not exceptional.
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 'View the file tree of a GitHub repository or subdirectory' with specific features (recursive, depth control, glob filtering, file sizes). It also distinguishes itself by suggesting use before get_file to understand project layout.
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 project layout and discover key files before reading them with get_file,' providing clear context. However, it does not explicitly exclude other use cases or mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by confirming no GitHub API usage, no rate limits, and detailing return types (PyPI: exact match with specific fields; npm: multiple results with links). No contradictions.
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 two sentences, front-loaded with the most critical clarification (not GitHub). Every sentence provides essential information with no redundancy or filler.
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?
Given the tool's low complexity (3 params, simple read-only behavior) and no output schema, the description fully explains what to expect for both ecosystems and suggests chaining. It is complete for an agent to decide when and how to invoke it.
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 100%, so baseline is 3. The description adds meaning by explaining that 'limit' only applies to npm and PyPI returns an exact match regardless of limit, which goes beyond the schema's description. It also implies the 'ecosystem' parameter selects behavior.
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 packages on PyPI or npm, explicitly excludes GitHub, and distinguishes itself from siblings like search_repos. It specifies the exact verb 'search' and the resource 'packages', and details the different behaviors for each ecosystem.
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: for looking up package metadata and versions, and suggests chaining with search_repos. It also clarifies what it does not do (GitHub API, rate limits). Although it doesn't explicitly state when not to use, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds extensive behavioral details: how the tool queries GitHub's code-search index, parallel-fetches candidate files, parses with tree-sitter, ranks results (type-declaring kinds first), and provides response format (absolute line numbers, context lines). It also covers language-specific behavior and fallback mechanisms.
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 relatively long but well-structured with clear sections, bullet points, and a 'How it works' explanation. While every sentence adds value, it could be slightly more concise without losing essential information. The front-loading of the core purpose is good.
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?
Given the tool's complexity (symbol definition across repos, AST parsing, ranking), the description is highly complete. It covers use cases, limitations, fallback behavior, and response format. Even without an output schema, the description explains what results include (line numbers, context lines), making it sufficient for an agent to understand the tool's full behavior.
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%, so baseline is 3. The description does not add new parameter-level details beyond what the schema already provides (e.g., the 'name' parameter is described in schema as 'Symbol name' and description doesn't elaborate further). However, the description sets overall context for parameters like 'repo' and 'language' by explaining when to use them.
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 'find where a symbol is defined', uses specific verb 'find' and resource 'symbol definition', and contrasts with sibling tools like search_code for usage patterns. It clearly distinguishes its purpose from other 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?
The description provides explicit guidance on when to use this tool ('best for distinctive symbol names') and when not ('NOT for generic names'), with concrete alternatives such as using search_code with disambiguating keywords. It also specifies limitations for generic names and call-sites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral details: that repository-level qualifiers silently match literal content (giving wrong results), and that convenience params are appended as qualifiers automatically. This significantly aids safe usage.
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 well-structured, starting with purpose, then features, use cases, and warnings. It is fairly concise given the amount of information, though slightly longer than minimalist. Every sentence adds value, but it could be slightly more streamlined.
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?
Despite no output schema, the description covers query syntax, scoping, convenience params, unsupported qualifiers, and pagination parameters. It distinguishes from siblings and provides complete guidance for effective use, making it contextually rich.
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%, so the schema already documents all 7 parameters adequately. The description adds minor context about automatic appending of repo/language/path as qualifiers, but does not substantially augment parameter meaning 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 that this tool searches for code across all of GitHub or narrowed scopes, and distinguishes from sibling tool find_symbol by specifying what it is NOT for (finding symbol definitions). The verb 'search' and resource 'code' are explicit.
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?
Provides explicit use cases (finding usage patterns, discovering library users, locating examples) and clear when-not-to-use with alternative named (find_symbol). Also warns about unsupported repository-level qualifiers and directs to search_repos for popularity-filtered discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only, idempotent, non-destructive. The description adds behavioral details: default mode returns lightweight tags with commit SHAs, release mode returns full release objects with title, body, date, assets. No contradiction.
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?
Four sentences, no fluff. Front-loaded with purpose, then mode explanation, then usage examples. Every sentence adds value.
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?
Given the simple listing nature, complete coverage of modes and outputs. No output schema needed because the description explicitly states return types for both modes. Integrates well with sibling tools.
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 covers all parameters (100%). The description adds context for the 'releases' parameter by explaining mode difference and shows how outputs integrate with sibling tools, enhancing understanding 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?
The description clearly states 'List tags or releases for one repository' with a specific verb and resource. It distinguishes the two modes (default vs releases) and implies differentiation from siblings by mentioning how to use the output with get_file and repo_tree.
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 explicit use cases: checking freshness, finding version, picking release. It does not explicitly state when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description details the ranking algorithm (composite relevance, star tiebreak), multi-query merging, and potential pitfalls (substring matching, noisy topic tags). This fully discloses behavior.
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?
Well-structured with clear sections and examples, but slightly verbose. Could trim some repetition in use-case examples while retaining all necessary 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?
Given no output schema, the description lists return fields and explains ranking behavior. It covers all parameters and provides complete guidance for effective use, making it highly self-contained.
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?
Schema coverage is 100%, but the description adds significant value: explains query vs queries interaction, provides query examples, warns about unsupported qualifiers, and gives usage advice for language, archived, and stars filters.
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's purpose: 'Discover GitHub repositories' for finding maintained, coherent repos. It distinguishes from siblings like search_code, get_file, and search_packages by specifying what the tool is NOT for.
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?
The description provides extensive guidance on when to use (e.g., 'find reference implementations', 'prior art', 'gem hunting') and when not to use (e.g., 'searching code inside repos'). It includes specific examples and tips like using queries parameter and avoiding file qualifiers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fossick-mcp MCP server](https://glama.ai/mcp/servers/Lipdog/fossick-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Lipdog/fossick-mcp)

Score Badge

Copy to your README.md:

[![fossick-mcp MCP server](https://glama.ai/mcp/servers/Lipdog/fossick-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Lipdog/fossick-mcp)

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/Lipdog/fossick-mcp'

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