Skip to main content
Glama
Sign In
charleswei118

web2mcp

by charleswei118
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

GitHub: search_repos

github_search_repos
Read-only

Search public GitHub repositories by query when the exact repo is unknown. Use GitHub qualifiers to filter results and return matching repos with stars, language, and URL.

Instructions

[github] Find public GitHub repositories matching a query. Use this when you don't know the exact repo; use github_repo when you already have owner and name. Supports GitHub qualifiers like 'mcp language:rust stars:>100'. Returns up to limit repos (full_name, description, stars, language, url, updated_at). Unauthenticated calls share a low rate limit.

Input Schema

NameRequiredDescriptionDefault
sortNoSort order: most stars, most recently updated, or most forksstars
limitNoMax repositories to return (1-30)
queryYesSearch text with optional GitHub qualifiers, e.g. 'mcp server language:typescript'

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.2.1
    • addedInput schema / properties / limit / description
      Added value: +"Max repositories to return (1-30)"
    • addedInput schema / properties / query / description
      Added value: +"Search text with optional GitHub qualifiers, e.g. 'mcp server language:typescript'"
    • addedInput schema / properties / sort / description
      Added value: +"Sort order: most stars, most recently updated, or most forks"
  2. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses qualifier syntax support, the exact returned fields (full_name, description, stars, language, url, updated_at), the limit bound, and a rate-limit caveat for unauthenticated calls. This is exactly the operational context annotations cannot carry.

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 short sentences, front-loaded with purpose and routing, then capabilities, then return shape, then the rate-limit caveat. Every sentence carries distinct information with no repetition of the name or title.

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?

There is no output schema, and the description compensates by enumerating the returned fields. Combined with routing guidance and the rate-limit warning, an agent has everything needed to call it correctly.

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 the baseline is 3; the description earns an uplift by explaining that the query string accepts GitHub search qualifiers and giving a concrete example with stars:>100, which the schema only hints at.

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?

States a specific verb and resource ("Find public GitHub repositories matching a query") and immediately contrasts with the sibling github_repo. An agent can distinguish it from every other sibling without reading the schema.

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 gives the when-to-use rule ("when you don't know the exact repo") and names the alternative (github_repo) with the condition that selects it. Nothing is left to inference.

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

Deploy Server

Other Tools