A
licenseA
qualityB
maintenanceStartup engineering acceleration signals for VC investors. Tracks commit velocity, contributor growth, and repo expansion across 20 sectors via public GitHub data. No API key required.
8
159 npm
6
MIT
Upstar
by dev.upstar
Server Details
Rising GitHub repos per topic, ranked by star velocity, plus repos spotted early. Free, read-only.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A3.6/5.0
Scored across 9 tools
Disambiguation4/5
Most tools target distinct resources (get_repo, list_topics, list_collections, get_collection, search), but four tools — emerging, trending, topic_ranking, and spotted_early — all return leaderboards of rising repositories. The descriptions do carefully separate them by rule (small-and-accelerating vs. cross-topic velocity vs. single-topic ranked with paging vs. doubled-since-first-ranked), so an attentive agent can choose correctly, though misselection is plausible at a glance.
Naming Consistency3/5
The set mixes verb_noun names (get_repo, get_collection, list_topics, list_collections) with bare page-style names (emerging, trending, spotted_early) and a noun_noun form (topic_ranking). Each name is readable and evocative of the site page it mirrors, but there is no single predictable pattern an agent can generalize from.
Tool Count5/5
Nine tools is well within the ideal 3-15 range and each maps to a distinct page or entity on the Upstar site (trending, topics, collections, repo pages, search, emerging, spotted early). No tool feels redundant or like filler.
Completeness4/5
For a read-only rankings site, coverage is strong: global and per-topic rankings, collections with newcomers, repo detail with 12-week history, topic listing, and search. Minor gaps remain — search covers repositories and topics but not collections, and there is no direct way to fetch a repository's longer history or an arbitrary collection-topic intersection beyond what emerging/topic_ranking offer.
Available Tools
9 toolsemergingEmerging repositoriesARead-onlyIdempotentInspect
Small GitHub repositories (under 1,000 stars a week ago, at least 30 days old) gaining stars at least twice as fast as in a usual week, by that ratio; optionally in one topic. The same list as Upstar's Emerging page (or the topic's Emerging tab).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| limit | No | how many repositories, 1 to 50 (10 by default) | |
| topic | No | only this topic's emerging repositories (a slug from list_topics); all topics when empty | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
| offset | No | how many places of the ranking to pass over, for the next page (next_offset of the previous answer); 0 by default, at most the number of repositories ranked |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| repos | Yes | |
| topic | No | |
| ranked | Yes | how many repositories are emerging (in the topic, when one is given) |
| source | Yes | the source to cite when using these figures |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| next_offset | No | the offset of the next page; absent on the last one |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this to be a safe, idempotent, closed read, so the description is not obligated to restate that. Instead it adds the substantive behavioral fact the annotations cannot: the eligibility thresholds and the ratio-based ordering, which explain why qualifying repos appear and others do not. Pagination and expansion behavior are documented in the schema rather than the description, which is a reasonable division.
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, with the qualifying criteria front-loaded and the web-page equivalence second. The parenthetical thresholds are dense but every clause carries selection-relevant information, and there is no filler or repetition of name/title.
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 an output schema present the description need not explain return values, and annotations cover the safety profile, so the remaining burden is defining what the list contains. It does that precisely, including the ordering dimension that makes offset paging meaningful. A brief note on when this differs from the trending sibling would close the last gap.
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 explains lang, limit, topic, detail, and offset thoroughly, including next_offset semantics. The description adds only that topic filtering is optional and that ranking is by growth ratio, which is marginal value beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.
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?
The description gives an exact definition of the resource: small GitHub repos (under 1,000 stars a week ago, at least 30 days old) whose star growth this week is at least 2x their usual weekly rate, ranked by that ratio. It also names the exact web surface it mirrors (Upstar's Emerging page or a topic's Emerging tab), which tells an agent the contents are a curated ranking rather than a raw star-gain list. It never names a sibling such as trending or spotted_early, so differentiation is inferred from the criteria rather than stated.
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?
"optionally in one topic" implies the topic-scoped use case, and the "Upstar's Emerging page" reference hints at when the list is appropriate. There is no explicit guidance on when to choose this over trending, topic_ranking, or spotted_early, and no stated exclusions (for example, that large repos will not appear here).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_collectionA collection's rankingBRead-onlyIdempotentInspect
A collection's ranking (score = momentum and health with the collection's weights) and its rising newcomers under 90 days old: the same lists as the collection's page on Upstar.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| limit | No | how many ranked repositories, 1 to 50 (10 by default); newcomers come apart, 10 at most | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
| offset | No | how many places of the ranking to pass over, for the next page (next_offset of the previous answer); 0 by default, at most the number of repositories ranked | |
| collection | Yes | the collection's slug, from list_collections |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| repos | Yes | |
| source | Yes | the source to cite when using these figures |
| newcomers | Yes | rising repositories under 90 days old, on the first page only |
| collection | Yes | |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| next_offset | No | the offset of the next page; absent on the last one |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's contribution is the domain context: the score is momentum plus health weighted by the collection, and newcomers are under 90 days old. It omits any mention of pagination behavior (offset/next_offset) or the separate cap of 10 newcomers, both of which matter for calling it correctly.
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?
One front-loaded sentence that leads with the primary output and parenthetically defines the score. Dense but every clause carries information; the only slight drag is the trailing Upstar-page analogy, which is useful orientation rather than 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?
With an output schema present, the description needn't document return shapes, and annotations carry the safety semantics. What remains is the conceptual framing of the two lists and the scoring model, which the description supplies; the only residual gap, pagination, is fully specified in the schema.
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 explains lang, limit, detail, offset, and collection in detail. The description adds only indirect meaning — the 90-day newcomers window and the scoring formula — and nothing about how limit splits between ranked repos and newcomers or how detail changes output. Baseline 3 is appropriate.
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?
The description names the resource (a collection's ranking) and states exactly what comes back: the scored ranking plus rising newcomers under 90 days old, framed as 'the same lists as the collection's page on Upstar.' It is clear enough to distinguish from topic_ranking or trending, though it never names those siblings explicitly and the verb is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no exclusion of alternatives. The reader must infer that a collection slug (from list_collections, stated only in the schema) is a prerequisite, and nothing says why to pick this over topic_ranking, trending, or emerging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_repoA repository's factsARead-onlyIdempotentInspect
One GitHub repository as Upstar sees it, the same facts as its Upstar page: stars and gains, its usual week, its star total week by week over 12 weeks, its topics and ranks, when Upstar spotted it, its latest release, license, activity and collections. Answers for every repository with an Upstar page, kept-out ones included; blocked ones have none.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| repo | Yes | the repository: owner/name, or its GitHub or Upstar address | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| repo | Yes | |
| source | Yes | the source to cite when using these figures |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the description only needs to add the non-obvious caveats — and it does: the result set is limited to repositories with an Upstar page, kept-out repositories are still covered, and blocked repositories yield nothing. That negative-space disclosure is exactly what an agent needs before calling.
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?
Purpose is front-loaded in the first clause, followed by the returned-fact inventory and then the coverage caveat. The fact enumeration is long but each item tells the agent something about the payload; only mild redundancy with the existing output schema.
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?
An output schema exists, so return shape needn't be spelled out, and annotations cover the safety profile; combined with the coverage/precondition sentence, an agent has what it needs to decide and call correctly. The only gap is the absence of explicit routing to sibling tools.
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%, with enums documented for lang and detail, so the schema carries parameter meaning on its own. The description adds no mapping between the enumerated facts and the detail levels, leaving that entirely to the schema — acceptable but no added value.
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 single specific resource ('One GitHub repository as Upstar sees it') and enumerates the fact families returned (stars/gains, 12-week history, topics and ranks, spotted date, release, license, activity, collections). It does not explicitly contrast itself with siblings like search, trending, or emerging, so an agent must infer the boundary, but the resource scope is unmistakable.
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 closing sentence gives a real precondition: it answers for every repository with an Upstar page, including kept-out ones, while blocked ones return nothing. That is useful eligibility context, but there is no explicit when-to-use-this vs use-search-or-trending guidance and no pointer to a sibling for repositories lacking an Upstar page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_collectionsList Upstar's collectionsARead-onlyIdempotentInspect
Upstar's collections: open-source tools that do one job, or alternatives to one product, each ranked by momentum and health. Use a slug with get_collection.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | tooling (open-source tools for one job) or alternatives (open-source alternatives to one product); both when empty | |
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| count | Yes | how many collections this answer lists |
| source | Yes | the source to cite when using these figures |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| collections | Yes | |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world access, so the description does not need to restate safety. It adds domain context by explaining that collections are ranked by momentum and health, but it does not add operational details such as pagination, auth, or rate limits beyond what annotations provide.
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 tight sentences: the first defines the collection domain and ranking, and the second gives a routing instruction to get_collection. There is no filler, and the resource definition is front-loaded.
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 an output schema, complete input-schema descriptions, and rich annotations, the description does not need to explain return values or safety behavior. It gives enough domain and routing context for an agent to understand what collections are and how they relate to get_collection, though it could be slightly more explicit that this tool lists collections.
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%, and each parameter already has enum values and detailed descriptions, including kind, lang, and detail. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
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?
The description defines the resource clearly as Upstar's collections, distinguishing tooling collections from alternatives, and it routes the agent to get_collection for slug-based lookup. It never explicitly says 'list' or 'return collections', so the action is implicit rather than stated as a specific verb plus resource.
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 names get_collection as the alternative when a slug is already known, giving useful context for choosing between listing and retrieving a single collection. It does not discuss when to use other siblings like search or list_topics, but for this tool's scope the routing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_topicsList Upstar's topicsARead-onlyIdempotentInspect
Lists the topics Upstar ranks GitHub repositories in (emulation, self-hosted, Rust, MCP…): slug, name, category, description and how many repositories rank in each this week. Use a slug with topic_ranking or emerging.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
| category | No | only this category's topics (a category slug from an earlier answer) |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| count | Yes | how many topics this answer lists (all of Upstar's topics, or a category's) |
| source | Yes | the source to cite when using these figures |
| topics | Yes | |
| categories | No | the categories (full detail) |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low, but the description still adds meaningful behavior: counts are scoped to 'this week', implying a rolling weekly snapshot rather than an all-time total. It also names the returned fields, which helps even though an output schema exists.
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, zero padding: the first defines the resource and its payload, the second states the downstream use. The most important fact (what this tool returns) is front-loaded.
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?
No required parameters, full schema coverage, an output schema for return values, and rich annotations leave little for the description to carry. What it does carry — the resource identity, the weekly count scoping, and the slug handoff — is exactly what structured fields cannot express.
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 compact/verbose and English/French parameters are already documented and a baseline of 3 applies. The description goes beyond that by explaining the functional role of the slug output — that it is the key consumed by topic_ranking and emerging — which the schema cannot convey.
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 gives a specific verb and resource ('Lists the topics Upstar ranks GitHub repositories in') and immediately grounds it with examples plus the exact fields returned (category, name, category, description, repository counts). A reader can distinguish it from sibling list tools like list_collections or get_repo without opening a schema.
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?
It states a concrete follow-up path: 'Use a slug with topic_ranking or emerging,' which tells the agent this tool is the discovery step for two specific siblings. It does not explain when to prefer it over list_collections or when the listing is unnecessary, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch UpstarARead-onlyIdempotentInspect
Upstar's search, the same as the site's search bar: topics by whole words (a name, slug, GitHub tag, language or keyword equal to the query, then every word of it in the topic's name, category or description) and every repository with an Upstar page (by name, description, GitHub topics and language; kept-out ones included, blocked ones apart); plain matching, no AI. Repositories: exact name first, then the most stars gained this week.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| limit | No | how many repositories, 1 to 50 (10 by default) | |
| query | Yes | words to look for: a repository's name or owner/name, a word of its description, a GitHub topic, a language or a topic's name | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| query | Yes | |
| repos | Yes | the first matching repositories, best match first (exact name, then name, description, GitHub topic, language; then stars gained this week): the same as the site's search bar |
| source | Yes | the source to cite when using these figures |
| topics | Yes | topics matching the query by whole words, strongest first: slug, name, GitHub tag, language or keyword equal to it; then name and tags; then category; then description; the same as the site's search bar |
| matches | Yes | how many repositories the search finds in all |
| left_out | No | matching repositories the search does not return: blocked by Upstar, so without a page |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, closed-world safety profile, so the description earns credit for adding real search semantics: whole-word matching, no AI, inclusion of kept-out repositories, blocked ones separated out, and result ordering. It stops short of describing pagination or how blocked results are surfaced in the response.
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 dense sentences, front-loaded with the topics scope and then repositories, with ordering rules last. Parenthetical asides are compact and every clause carries information; nothing is wasted despite the length.
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?
An output schema exists, so return values need no explanation, and the description covers what is searched, matching rules, and ordering. The one gap is guidance on choosing this tool over the ranking siblings, which matters given eight related tools.
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 the schema already documents all four parameters, including the lang and limit defaults and the detail enum's full vs compact payloads. The description adds no parameter-level detail beyond the schema, so baseline 3 applies.
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 dual resource scope: it searches topics by whole-word matching and every repository with an Upstar page, and it explicitly excludes AI matching ("plain matching, no AI"). It also says how results are ordered (exact name first, then weekly star gains), which distinguishes it from ranking siblings like trending or topic_ranking.
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 positions the tool as "the same as the site's search bar," giving implied usage, and it names what is included versus excluded (kept-out included, blocked apart). However, it never states when to prefer this over siblings such as trending, emerging, spotted_early, or topic_ranking, nor 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.
spotted_earlySpotted early by UpstarBRead-onlyIdempotentInspect
Repositories whose stars at least doubled since Upstar first ranked them in a topic, at any rank: when, in which topic and at which rank it first ranked them, their stars then and now. Most grown first: the same list as Upstar's Spotted early page.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| limit | No | how many repositories, 1 to 50 (10 by default) | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| repos | Yes | |
| source | Yes | the source to cite when using these figures |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that — the result is ordered by most growth first — but says nothing about pagination, time windows, or how 'first ranked' is determined. Adequate but thin against a low annotation bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core rule is front-loaded, but the phrasing is tangled: 'at any rank: when, in which topic and at which rank it first ranked them' repeats rank and is hard to parse as return fields. The trailing fragment 'Most grown first: the same list as Upstar's Spotted early page' splits ordering and provenance awkwardly.
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?
An output schema exists, so return shape need not be spelled out, and the description correctly covers the selection rule and sort order. What is missing for a discovery tool surrounded by eight siblings is where it fits — no stated relationship to emerging, trending or topic_ranking, and no note on the default 10-item limit's implications.
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%, and the schema already explains lang, limit and the compact/full detail levels in more depth than the description does. The description adds no parameter meaning at all, so the baseline 3 applies.
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?
The description names the specific resource and its selection rule: repositories whose stars at least doubled since Upstar first ranked them in a topic. That is a real verb-plus-resource statement an agent can act on, but it never contrasts the set with siblings like emerging or trending, so differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance and no alternative named. The closing clause 'the same list as Upstar's Spotted early page' describes provenance/ordering rather than telling an agent when this tool beats emerging, trending or topic_ranking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
topic_rankingA topic's rankingARead-onlyIdempotentInspect
Ranks a topic's GitHub repositories by star velocity (stars gained ÷ √stars before) over the last 24 hours, 7 days or 30 days, with the stars each gained: the same list as the topic's page on Upstar. Page with offset (next_offset).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| limit | No | how many repositories, 1 to 50 (10 by default) | |
| topic | Yes | the topic's slug, from list_topics or search (rust, self-hosted, emulation…) | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
| offset | No | how many places of the ranking to pass over, for the next page (next_offset of the previous answer); 0 by default, at most the number of repositories ranked | |
| period | No | day (last 24 hours), week (last 7 days, the default) or month (last 30 days) | week |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| repos | Yes | |
| topic | Yes | |
| period | Yes | |
| ranked | Yes | how many repositories rank in the topic over the period |
| source | Yes | the source to cite when using these figures |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| next_offset | No | the offset of the next page; absent on the last one |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the ranking formula, the fact that gains are included, that the result mirrors the Upstar topic page, and that paging continues through next_offset. It does not discuss what happens for an unknown or empty topic, which is the main remaining gap.
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 core action and metric are front-loaded, and every clause carries information about scope, metric or paging. The colon-and-clause construction ('with the stars each gained: the same list as...') is slightly tangled and one sentence is asked to do a lot, but there is no filler.
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 a 6-parameter schema at full description coverage, rich annotations and an output schema, the description only needs to establish purpose, metric and paging, and it does all three. The notable omission is behavior for a topic slug that returns no ranked repositories.
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 limit, offset, period, detail, lang and topic are all already documented in the schema, making a 3 the baseline. The description adds a modest amount: it defines what the ranking metric is and explicitly ties the offset parameter to next_offset from the previous answer. Otherwise the period and paging semantics are restated rather than extended.
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?
The description gives a specific verb (ranks), a specific resource (a topic's GitHub repositories), and even the exact metric (stars gained divided by the square root of prior stars) plus the supported time windows. Scope is pinned down further by 'the same list as the topic's page on Upstar'. It never names the sibling tools (trending, emerging, spotted_early), so differentiation is implied by the topic-scoped framing rather than stated.
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 only implied: an agent can infer this is the tool for a single topic's ranked repository list, and the trailing 'Page with offset (next_offset)' gives a concrete paging instruction. There is no explicit when-to-use versus trending/emerging/search, and no statement about prerequisites such as the topic already existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trendingTrending on GitHubARead-onlyIdempotentInspect
The fastest-rising GitHub repositories across every topic Upstar tracks, by star velocity or by stars gained, over 24 hours, 7 days or 30 days; new_only keeps repositories created in the last 7 days. The same list as Upstar's Trending page.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | language of the names, descriptions and links Upstar writes: en (default at /mcp) or fr (default at /fr/mcp); repository descriptions stay as their authors wrote them | |
| sort | No | velocity (stars gained relative to size, the default) or gained (most stars gained, so large repositories show) | velocity |
| limit | No | how many repositories, 1 to 50 (10 by default) | |
| detail | No | compact (the default): each repository's rank, name, description, language, stars, gains and Upstar page; full adds its creation day, health level, topics with their ranks and GitHub address, list_topics its categories, and get_repo its 12-week history, GitHub topics, activity counts and every period's ranks | compact |
| offset | No | how many places of the ranking to pass over, for the next page (next_offset of the previous answer); 0 by default, at most the number of repositories ranked | |
| period | No | day (last 24 hours), week (last 7 days, the default) or month (last 30 days); new_only is always the week | week |
| new_only | No | only repositories created in the last 7 days, by stars gained this week |
Output Schema
| Name | Required | Description |
|---|---|---|
| lang | Yes | language of names and descriptions written by Upstar (en or fr) |
| repos | Yes | |
| period | Yes | |
| ranked | Yes | how many repositories this ranking holds |
| source | Yes | the source to cite when using these figures |
| method_url | Yes | Upstar's page explaining how stars are counted and repositories ranked |
| next_offset | No | the offset of the next page; absent on the last one |
| data_updated_at | Yes | when Upstar last rebuilt its rankings from GitHub's data (UTC, RFC 3339): every figure is as of then |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and side-effect questions are covered. The description adds useful context beyond that — the default window framing, the new_only restriction to repos created in the last 7 days, and the equivalence to Upstar's Trending page — but says nothing about result volume, pagination via next_offset, or the tie between new_only and the week period beyond what the schema already states.
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?
It is a single dense sentence that front-loads the resource and scope before the option enumeration, with no filler clauses. It is slightly run-on with the semicolon-joined new_only clause, but every clause carries information, so trimming would cost content rather than noise.
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 an output schema present, the description need not explain return values, and annotations cover the safety profile; what remains needed is purpose, scope, and default behavior, all of which are present. The one real gap for a tool sitting among eight similarly themed siblings is the absence of any routing cue distinguishing it from emerging, spotted_early, or topic_ranking.
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 every parameter including lang, sort, period, limit, offset, detail and new_only is already documented in the schema with defaults and enums. The description only restates the sort and period choices in prose ('by star velocity or by stars gained, over 24 hours, 7 days or 30 days') and adds no syntax, format, or edge-case meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
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?
The description names a specific resource (fastest-rising GitHub repositories across every topic Upstar tracks) and enumerates the ranking dimensions and time windows, which is more than a restatement of the name 'trending'. It falls short of a 5 because the sibling set contains closely related discovery tools (emerging, spotted_early, topic_ranking) and the description never contrasts itself with them, so an agent cannot tell from this text alone which rising-repo tool to pick.
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 only implied: the phrasing suggests this is the general broad-topic trending list, versus the niche concepts implied by siblings like emerging and spotted_early, but no explicit when-to-use, when-not-to-use, or alternative-naming sentence is present. There are also no preconditions given (none needed, since all 7 parameters are optional).
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.
2 tool updates
- Changed
get_repo1 field changed- changed
Output schema / properties / repo / properties / spotted / anyOfPrevious value: -[ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "growth": { - "description": "how many times its stars grew since", - "type": "string" - }, - "rank_when_spotted": { - "description": "its rank in that topic's weekly ranking then, any rank; absent when not kept (before November 2026)", - "type": "integer" - }, - "spotted_in": { - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "name": { - "type": "string" - }, - "rank_this_week": { - "type": "integer" - }, - "slug": { - "type": "string" - }, - "url": { - "type": "string" - } - }, - "required": [ - "slug", - "name", - "url" - ], - "type": "object" - } - ], - "description": "the topic it was first ranked in" - }, - "spotted_on": { - "type": "string" - }, - "stars_when_spotted": { - "type": "integer" - } - }, - "required": [ - "spotted_on", - "stars_when_spotted", - "growth" - ], - "type": "object" - } -]New value: +[ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "growth": { + "description": "how many times its stars grew since", + "type": "string" + }, + "rank_when_spotted": { + "description": "its rank in that topic's weekly ranking then, any rank; absent when not kept (before November 2026) or the repo has left that topic", + "type": "integer" + }, + "spotted_in": { + "anyOf": [ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "rank_this_week": { + "type": "integer" + }, + "slug": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "name", + "url" + ], + "type": "object" + } + ], + "description": "the topic it was first ranked in; absent when the repo has left that topic" + }, + "spotted_on": { + "type": "string" + }, + "stars_when_spotted": { + "type": "integer" + } + }, + "required": [ + "spotted_on", + "stars_when_spotted", + "growth" + ], + "type": "object" + } +]
- Changed
spotted_early1 field changed- changed
Output schema / properties / repos / anyOfPrevious value: -[ - { - "type": "null" - }, - { - "items": { - "additionalProperties": false, - "properties": { - "created_on": { - "description": "creation day (YYYY-MM-DD; full detail)", - "type": "string" - }, - "description": { - "description": "the repository's GitHub description, as its authors wrote it", - "type": "string" - }, - "full_name": { - "description": "owner/name as GitHub writes it", - "type": "string" - }, - "github_url": { - "description": "full detail", - "type": "string" - }, - "health": { - "description": "Upstar's health level: healthy, mixed, low, new or archived (full detail; empty when not assessed)", - "type": "string" - }, - "language": { - "type": "string" - }, - "new": { - "description": "created in the last 30 days", - "type": "boolean" - }, - "rank": { - "description": "its rank in this list (a topic ranking keeps the topic's own ranks)", - "type": "integer" - }, - "rank_when_spotted": { - "description": "its rank in that topic's weekly ranking then, any rank; absent when not kept (before November 2026)", - "type": "integer" - }, - "spotted_in": { - "additionalProperties": false, - "description": "the topic it was first ranked in", - "properties": { - "name": { - "type": "string" - }, - "rank_this_week": { - "type": "integer" - }, - "slug": { - "type": "string" - }, - "url": { - "type": "string" - } - }, - "required": [ - "slug", - "name", - "url" - ], - "type": "object" - }, - "spotted_on": { - "description": "the day Upstar first ranked it (YYYY-MM-DD)", - "type": "string" - }, - "stars": { - "description": "GitHub's star count as Upstar last read it", - "type": "integer" - }, - "stars_gained": { - "additionalProperties": false, - "properties": { - "last_24h": { - "type": "integer" - }, - "last_30d": { - "type": "integer" - }, - "last_7d": { - "type": "integer" - } - }, - "required": [ - "last_24h", - "last_7d", - "last_30d" - ], - "type": "object" - }, - "stars_when_spotted": { - "type": "integer" - }, - "topics": { - "anyOf": [ - { - "type": "null" - }, - { - "items": { - "additionalProperties": false, - "properties": { - "name": { - "type": "string" - }, - "rank_this_week": { - "type": "integer" - }, - "slug": { - "type": "string" - }, - "url": { - "type": "string" - } - }, - "required": [ - "slug", - "name", - "url" - ], - "type": "object" - }, - "type": "array" - } - ], - "description": "its topics with its rank there this week (full detail)" - }, - "url": { - "description": "the repository's page on Upstar", - "type": "string" - } - }, - "required": [ - "full_name", - "stars", - "stars_gained", - "url", - "spotted_on", - "spotted_in", - "stars_when_spotted" - ], - "type": "object" - }, - "type": "array" - } -]New value: +[ + { + "type": "null" + }, + { + "items": { + "additionalProperties": false, + "properties": { + "created_on": { + "description": "creation day (YYYY-MM-DD; full detail)", + "type": "string" + }, + "description": { + "description": "the repository's GitHub description, as its authors wrote it", + "type": "string" + }, + "full_name": { + "description": "owner/name as GitHub writes it", + "type": "string" + }, + "github_url": { + "description": "full detail", + "type": "string" + }, + "health": { + "description": "Upstar's health level: healthy, mixed, low, new or archived (full detail; empty when not assessed)", + "type": "string" + }, + "language": { + "type": "string" + }, + "new": { + "description": "created in the last 30 days", + "type": "boolean" + }, + "rank": { + "description": "its rank in this list (a topic ranking keeps the topic's own ranks)", + "type": "integer" + }, + "rank_when_spotted": { + "description": "its rank in that topic's weekly ranking then, any rank; absent when not kept (before November 2026) or the repo has left that topic", + "type": "integer" + }, + "spotted_in": { + "anyOf": [ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "rank_this_week": { + "type": "integer" + }, + "slug": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "name", + "url" + ], + "type": "object" + } + ], + "description": "the topic it was first ranked in; absent when the repo has left that topic" + }, + "spotted_on": { + "description": "the day Upstar first ranked it (YYYY-MM-DD)", + "type": "string" + }, + "stars": { + "description": "GitHub's star count as Upstar last read it", + "type": "integer" + }, + "stars_gained": { + "additionalProperties": false, + "properties": { + "last_24h": { + "type": "integer" + }, + "last_30d": { + "type": "integer" + }, + "last_7d": { + "type": "integer" + } + }, + "required": [ + "last_24h", + "last_7d", + "last_30d" + ], + "type": "object" + }, + "stars_when_spotted": { + "type": "integer" + }, + "topics": { + "anyOf": [ + { + "type": "null" + }, + { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "rank_this_week": { + "type": "integer" + }, + "slug": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "name", + "url" + ], + "type": "object" + }, + "type": "array" + } + ], + "description": "its topics with its rank there this week (full detail)" + }, + "url": { + "description": "the repository's page on Upstar", + "type": "string" + } + }, + "required": [ + "full_name", + "stars", + "stars_gained", + "url", + "spotted_on", + "stars_when_spotted" + ], + "type": "object" + }, + "type": "array" + } +]
2 tool updates
- Changed
get_repo1 field changed- changed
Output schema / properties / repo / properties / spotted / anyOfPrevious value: -[ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "growth": { - "description": "how many times its stars grew since", - "type": "string" - }, - "spotted_on": { - "type": "string" - }, - "stars_when_spotted": { - "type": "integer" - } - }, - "required": [ - "spotted_on", - "stars_when_spotted", - "growth" - ], - "type": "object" - } -]New value: +[ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "growth": { + "description": "how many times its stars grew since", + "type": "string" + }, + "rank_when_spotted": { + "description": "its rank in that topic's weekly ranking then, any rank; absent when not kept (before November 2026)", + "type": "integer" + }, + "spotted_in": { + "anyOf": [ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "rank_this_week": { + "type": "integer" + }, + "slug": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "name", + "url" + ], + "type": "object" + } + ], + "description": "the topic it was first ranked in" + }, + "spotted_on": { + "type": "string" + }, + "stars_when_spotted": { + "type": "integer" + } + }, + "required": [ + "spotted_on", + "stars_when_spotted", + "growth" + ], + "type": "object" + } +]
- Changed
spotted_early1 field changed- changed
Output schema / properties / repos / anyOfPrevious value: -[ - { - "type": "null" - }, - { - "items": { - "additionalProperties": false, - "properties": { - "created_on": { - "description": "creation day (YYYY-MM-DD; full detail)", - "type": "string" - }, - "description": { - "description": "the repository's GitHub description, as its authors wrote it", - "type": "string" - }, - "full_name": { - "description": "owner/name as GitHub writes it", - "type": "string" - }, - "github_url": { - "description": "full detail", - "type": "string" - }, - "health": { - "description": "Upstar's health level: healthy, mixed, low, new or archived (full detail; empty when not assessed)", - "type": "string" - }, - "language": { - "type": "string" - }, - "new": { - "description": "created in the last 30 days", - "type": "boolean" - }, - "rank": { - "description": "its rank in this list (a topic ranking keeps the topic's own ranks)", - "type": "integer" - }, - "spotted_in": { - "additionalProperties": false, - "description": "the topic it was first ranked in", - "properties": { - "name": { - "type": "string" - }, - "rank_this_week": { - "type": "integer" - }, - "slug": { - "type": "string" - }, - "url": { - "type": "string" - } - }, - "required": [ - "slug", - "name", - "url" - ], - "type": "object" - }, - "spotted_on": { - "description": "the day Upstar first ranked it (YYYY-MM-DD)", - "type": "string" - }, - "stars": { - "description": "GitHub's star count as Upstar last read it", - "type": "integer" - }, - "stars_gained": { - "additionalProperties": false, - "properties": { - "last_24h": { - "type": "integer" - }, - "last_30d": { - "type": "integer" - }, - "last_7d": { - "type": "integer" - } - }, - "required": [ - "last_24h", - "last_7d", - "last_30d" - ], - "type": "object" - }, - "stars_when_spotted": { - "type": "integer" - }, - "topics": { - "anyOf": [ - { - "type": "null" - }, - { - "items": { - "additionalProperties": false, - "properties": { - "name": { - "type": "string" - }, - "rank_this_week": { - "type": "integer" - }, - "slug": { - "type": "string" - }, - "url": { - "type": "string" - } - }, - "required": [ - "slug", - "name", - "url" - ], - "type": "object" - }, - "type": "array" - } - ], - "description": "its topics with its rank there this week (full detail)" - }, - "url": { - "description": "the repository's page on Upstar", - "type": "string" - } - }, - "required": [ - "full_name", - "stars", - "stars_gained", - "url", - "spotted_on", - "spotted_in", - "stars_when_spotted" - ], - "type": "object" - }, - "type": "array" - } -]New value: +[ + { + "type": "null" + }, + { + "items": { + "additionalProperties": false, + "properties": { + "created_on": { + "description": "creation day (YYYY-MM-DD; full detail)", + "type": "string" + }, + "description": { + "description": "the repository's GitHub description, as its authors wrote it", + "type": "string" + }, + "full_name": { + "description": "owner/name as GitHub writes it", + "type": "string" + }, + "github_url": { + "description": "full detail", + "type": "string" + }, + "health": { + "description": "Upstar's health level: healthy, mixed, low, new or archived (full detail; empty when not assessed)", + "type": "string" + }, + "language": { + "type": "string" + }, + "new": { + "description": "created in the last 30 days", + "type": "boolean" + }, + "rank": { + "description": "its rank in this list (a topic ranking keeps the topic's own ranks)", + "type": "integer" + }, + "rank_when_spotted": { + "description": "its rank in that topic's weekly ranking then, any rank; absent when not kept (before November 2026)", + "type": "integer" + }, + "spotted_in": { + "additionalProperties": false, + "description": "the topic it was first ranked in", + "properties": { + "name": { + "type": "string" + }, + "rank_this_week": { + "type": "integer" + }, + "slug": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "name", + "url" + ], + "type": "object" + }, + "spotted_on": { + "description": "the day Upstar first ranked it (YYYY-MM-DD)", + "type": "string" + }, + "stars": { + "description": "GitHub's star count as Upstar last read it", + "type": "integer" + }, + "stars_gained": { + "additionalProperties": false, + "properties": { + "last_24h": { + "type": "integer" + }, + "last_30d": { + "type": "integer" + }, + "last_7d": { + "type": "integer" + } + }, + "required": [ + "last_24h", + "last_7d", + "last_30d" + ], + "type": "object" + }, + "stars_when_spotted": { + "type": "integer" + }, + "topics": { + "anyOf": [ + { + "type": "null" + }, + { + "items": { + "additionalProperties": false, + "properties": { + "name": { + "type": "string" + }, + "rank_this_week": { + "type": "integer" + }, + "slug": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "name", + "url" + ], + "type": "object" + }, + "type": "array" + } + ], + "description": "its topics with its rank there this week (full detail)" + }, + "url": { + "description": "the repository's page on Upstar", + "type": "string" + } + }, + "required": [ + "full_name", + "stars", + "stars_gained", + "url", + "spotted_on", + "spotted_in", + "stars_when_spotted" + ], + "type": "object" + }, + "type": "array" + } +]
5 tool updates
- Changed
emerging1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
- Changed
get_collection1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
- Changed
search2 fields changed- changed
Output schema / properties / left_out / anyOfPrevious value: -[ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } -]New value: +[ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "blocked": { + "description": "blocked by Upstar's moderation", + "type": "integer" + }, + "count": { + "type": "integer" + } + }, + "required": [ + "count" + ], + "type": "object" + } +] - changed
Output schema / properties / left_out / descriptionPrevious value: -"matching repositories the search does not return: blocked, or kept out by Upstar's review"New value: +"matching repositories the search does not return: blocked by Upstar, so without a page"
- Changed
topic_ranking1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
- Changed
trending1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
5 tool updates
- Changed
emerging1 field changed- added
Output schema / properties / left_outAdded value: +{ + "anyOf": [ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "blocked": { + "description": "blocked by Upstar's moderation", + "type": "integer" + }, + "count": { + "type": "integer" + }, + "kept_out_by_review": { + "description": "reviewed, and not featured by Upstar", + "type": "integer" + }, + "no_page": { + "description": "without an Upstar page this hour", + "type": "integer" + }, + "out_of_place": { + "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", + "type": "integer" + }, + "waiting_for_review": { + "description": "held until Upstar reviews their star growth or their content", + "type": "integer" + } + }, + "required": [ + "count" + ], + "type": "object" + } + ], + "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" +}
- Changed
get_collection1 field changed- added
Output schema / properties / left_outAdded value: +{ + "anyOf": [ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "blocked": { + "description": "blocked by Upstar's moderation", + "type": "integer" + }, + "count": { + "type": "integer" + }, + "kept_out_by_review": { + "description": "reviewed, and not featured by Upstar", + "type": "integer" + }, + "no_page": { + "description": "without an Upstar page this hour", + "type": "integer" + }, + "out_of_place": { + "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", + "type": "integer" + }, + "waiting_for_review": { + "description": "held until Upstar reviews their star growth or their content", + "type": "integer" + } + }, + "required": [ + "count" + ], + "type": "object" + } + ], + "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" +}
- Changed
search2 fields changed- changed
Output schema / properties / left_out / anyOfPrevious value: -[ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } -]New value: +[ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "blocked": { + "description": "blocked by Upstar's moderation", + "type": "integer" + }, + "count": { + "type": "integer" + }, + "kept_out_by_review": { + "description": "reviewed, and not featured by Upstar", + "type": "integer" + }, + "no_page": { + "description": "without an Upstar page this hour", + "type": "integer" + }, + "out_of_place": { + "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", + "type": "integer" + }, + "waiting_for_review": { + "description": "held until Upstar reviews their star growth or their content", + "type": "integer" + } + }, + "required": [ + "count" + ], + "type": "object" + } +] - changed
Output schema / properties / left_out / descriptionPrevious value: -"matching repositories the search does not return: blocked by Upstar, so without a page"New value: +"matching repositories the search does not return: blocked, or kept out by Upstar's review"
- Changed
topic_ranking1 field changed- added
Output schema / properties / left_outAdded value: +{ + "anyOf": [ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "blocked": { + "description": "blocked by Upstar's moderation", + "type": "integer" + }, + "count": { + "type": "integer" + }, + "kept_out_by_review": { + "description": "reviewed, and not featured by Upstar", + "type": "integer" + }, + "no_page": { + "description": "without an Upstar page this hour", + "type": "integer" + }, + "out_of_place": { + "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", + "type": "integer" + }, + "waiting_for_review": { + "description": "held until Upstar reviews their star growth or their content", + "type": "integer" + } + }, + "required": [ + "count" + ], + "type": "object" + } + ], + "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" +}
- Changed
trending1 field changed- added
Output schema / properties / left_outAdded value: +{ + "anyOf": [ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "blocked": { + "description": "blocked by Upstar's moderation", + "type": "integer" + }, + "count": { + "type": "integer" + }, + "kept_out_by_review": { + "description": "reviewed, and not featured by Upstar", + "type": "integer" + }, + "no_page": { + "description": "without an Upstar page this hour", + "type": "integer" + }, + "out_of_place": { + "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", + "type": "integer" + }, + "waiting_for_review": { + "description": "held until Upstar reviews their star growth or their content", + "type": "integer" + } + }, + "required": [ + "count" + ], + "type": "object" + } + ], + "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" +}
5 tool updates
- Changed
emerging1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
- Changed
get_collection1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
- Changed
search2 fields changed- changed
Output schema / properties / left_out / anyOfPrevious value: -[ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } -]New value: +[ + { + "type": "null" + }, + { + "additionalProperties": false, + "properties": { + "blocked": { + "description": "blocked by Upstar's moderation", + "type": "integer" + }, + "count": { + "type": "integer" + } + }, + "required": [ + "count" + ], + "type": "object" + } +] - changed
Output schema / properties / left_out / descriptionPrevious value: -"matching repositories the search does not return: blocked, or kept out by Upstar's review"New value: +"matching repositories the search does not return: blocked by Upstar, so without a page"
- Changed
topic_ranking1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
- Changed
trending1 field changed- removed
Output schema / properties / left_outRemoved value: -{ - "anyOf": [ - { - "type": "null" - }, - { - "additionalProperties": false, - "properties": { - "blocked": { - "description": "blocked by Upstar's moderation", - "type": "integer" - }, - "count": { - "type": "integer" - }, - "kept_out_by_review": { - "description": "reviewed, and not featured by Upstar", - "type": "integer" - }, - "no_page": { - "description": "without an Upstar page this hour", - "type": "integer" - }, - "out_of_place": { - "description": "judged out of place in this topic, or doubtful there, by Upstar's topic review (for a list across topics: in every one of their topics)", - "type": "integer" - }, - "waiting_for_review": { - "description": "held until Upstar reviews their star growth or their content", - "type": "integer" - } - }, - "required": [ - "count" - ], - "type": "object" - } - ], - "description": "the repositories of this stretch of the ranking Upstar does not show, by reason: the ranks this answer skips" -}
9 tool updates
- First observed
emerging - First observed
get_collection - First observed
get_repo - First observed
list_collections - First observed
list_topics - First observed
search - First observed
spotted_early - First observed
topic_ranking - First observed
trending
Related MCP Connectors
Read-only GitHub trending data: top repos by stars gained today, this week or this month.
GitHub hot-repo leaderboards: snapshots, movers, rank history. Read-only JSON, hourly batches.
Rising GitHub repos with fake stars filtered out: search, trending, repo pages, alternatives.
The posts rising fastest right now on Hacker News, GitHub, Product Hunt and more, for any topic.
Related MCP Servers
- AlicenseAqualityDmaintenanceAnalyzes and compares GitHub repositories, tracks star growth, and offers AI-powered README optimization to help grow open-source projects.5MIT
- AlicenseAqualityCmaintenanceEnables AI builders to discover trending open-source projects for a given task by ranking repos based on GitHub momentum, npm/PyPI growth, and Hacker News buzz, with tools to recommend, search, assess health, and compare repositories.4MIT
- AlicenseAqualityDmaintenanceProvides GitHub data analysis for repositories, developers, and organizations, enabling insights into open source ecosystems through API calls and natural language queries.514MIT
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.