check_before_building
Searches GitHub, npm, and other registries for existing projects and competing products before you scaffold a new project, preventing redundant work.
Instructions
Run this BEFORE scaffolding a new project or a substantial new module. Searches GitHub, npm, GitLab, Show HN, optional Tavily web search, Python repositories when relevant, and one ecosystem registry for Rust, Ruby, PHP, or JVM projects. Returns both reusable projects and products the proposal would compete with, plus complete retrieval evidence. The calling agent (you) remains responsible for semantic relevance judgment and must follow the returned scoring instructions. REQUIRES you to supply keywords yourself (see its field description) — do not guess this tool can extract good search terms on its own; generic terms like 'mcp'/'agent'/'server' will bury results in noise.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| queries | No | Optional high-quality intent inferred semantically by the calling agent: category names what this is, outcome says what it accomplishes, synonyms supplies distinct terminology maintainers or product makers may use, constraints supplies up to 8 must-have properties, priorities supplies up to 4 ordered preferences, and artifactType says whether the desired result is an application, hosted service, CLI, or library. Older callers may omit these optional fields; the server will infer conservative fallbacks. | |
| keywords | Yes | REQUIRED: 3-4 precise search terms YOU infer from the description, using your own understanding of what the user actually means — do this especially when the description is vague, informal, or from a non-native speaker. Pick the concrete domain noun a maintainer would actually put in their README, not a generic category word: e.g. for 'thing that checks my code doesn't have secret keys by mistake' prefer ["git", "secrets", "detect", "leak"] over ["secret", "scanner", "detect", "git"] — 'scanner' is broad enough to pull in unrelated security-tool listicles, while 'leak'/'secrets' matches how gitleaks/trufflehog actually describe themselves. Avoid generic tooling-ecosystem words (mcp, agent, server, tool, app) unless the description has nothing more specific — they return noise (awesome-lists, unrelated MCP servers) rather than real competitors. Critically, favor the word a maintainer would use to describe WHAT THE TOOL IS over the word describing the USER'S PROBLEM: a real 'pretty JSON in the terminal' tool likely calls itself a 'viewer' or 'processor', not a 'pretty-printer'/'colorizer'; a real static-site link checker likely says it validates 'rendered HTML', not 'static site alt-text'. If your first guess doesn't match, mentally simulate the README of the tool you're picturing and pull words straight from that sentence. | |
| description | Yes | Plain-language description of the project/module about to be built — what it does, not how. The more specific, the better the match quality. |