Skip to main content
Glama
Sign In
MyWebSearch

MyWebSearch

by wtznicy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

fetchGithubContent

Read-onlyIdempotent

Retrieve GitHub or Gitee content by URL—including README, source files with line ranges, issues, PRs, commits, and releases—without cloning the repository.

Instructions

Fetch GitHub/Gitee by URL: README, source file (/blob/, with lines), tree, issue, PR, commit, compare, or releases (releaseLimit for recent N). Example: https://github.com/o/r/blob/main/src/index.ts — ref can be branch/tag/commit; not a repo clone.

Input Schema

NameRequiredDescriptionDefault
urlYes
linesNoOptional source-file line range, 1-based inclusive (e.g. "120-180"). Only valid for /blob/ URLs; URL hash #L120-L180 also works.
releaseLimitNoOptional number of releases to return for /releases URLs (1-30, default 10).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +{}
  2. Changed1 schema field changedv1.3.12
    • addedInput schema / properties / releaseLimit
      Added value: +{
+  "description": "Optional number of releases to return for /releases URLs (1-30, default 10).",
+  "maximum": 30,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Addedv1.3.10

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real context: which URL path shapes are recognized, that ref may be branch/tag/commit, and that lines apply only to /blob/ URLs. It stays silent on authentication needs for private repos, rate limits, and failure behavior (e.g., what happens on a non-matching URL pattern).

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?

Dense but front-loaded — the artifact list comes first, then the example, then the two caveats. Every clause carries information; the only mild cost is that cramming the URL-type list, example, ref semantics, and clone exclusion into one sentence makes it slightly hard to scan.

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 exists, so the description carries the burden of explaining what comes back, and it only implies it ("with lines" suggests line-numbered source). For a multi-mode reader spanning eight different URL types, it should say more about the shape of results and about private-repo authentication before an agent can call it confidently in all modes.

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 67%, and the undocumented parameter is url itself. The description compensates well: it gives a concrete example URL, enumerates the path patterns the tool accepts, and explains that ref can be a branch, tag, or commit. It also reinforces the /blob/-only constraint on lines, adding cross-parameter meaning the schema only states in isolation.

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?

Names a specific verb (fetch) and resource (GitHub/Gitee URL content) and enumerates the supported content kinds: README, source file at /blob/, tree, issue, PR, commit, compare, releases. It also rules out one adjacent capability ("not a repo clone"), though it never names the sibling fetchWebContent or search to sharpen the boundary.

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?

Usage is implied rather than stated: you supply a GitHub/Gitee URL and the tool resolves the corresponding artifact. The one explicit exclusion ("not a repo clone") helps, but there is no guidance on when to prefer fetchWebContent, search, or queryDocs, and no mention of prerequisites such as private-repo auth.

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