AI Team OS

Overview Schema Source Related Servers Discussions Admin

ecosystem_search

Query the project's ecosystem_repo_profiles archive to find repos by stars, language, tags, or recency. Returns compact profiles with optional filters for category, status, and deep review needs.

Instructions

Query the project's ecosystem_repo_profiles archive.

Default response is a COMPACT projection (marked by view="compact" + hint — it is a trimmed view, NOT missing fields): each profile row keeps repo/stars/lang/status + summary. Full profile of a single repo: ecosystem_repo_get(repo_full_name); full rows here: fields="all".

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sort`	No	stars (default) / recency (pushed_at desc) / relevance (relevance_score desc).	stars
`tags`	No	Tag name list, semantic capability filter.
`limit`	No	Max results (default 30, server max 200).
`topic`	No	Topic keyword filter (JSON field LIKE match).
`fields`	No	"compact" (default, trimmed projection) / "all" (full rows).	compact
`offset`	No	Pagination offset.
`keyword`	No	Keyword match (name / description / summary / repo_full_name / description_excerpt).
`category`	No	Category filter (agent-framework / mcp-server / memory-system / skill-system / tooling).
`language`	No	Programming language filter (e.g. Python / TypeScript).
`max_stars`	No	Maximum star count (0 = no limit).
`min_stars`	No	Minimum star count.
`project_id`	No	Restrict the search to one project's archive. Empty (default) resolves the project from the current session — only pass it to read another project's archive on purpose.
`is_archived`	No	True/False to filter archived repos; None = no filter.
`facet_counts`	No	When True, response includes facet_counts (category/language/archived).
`pushed_after`	No	ISO datetime — only repos with pushed_at >= this. Empty = no filter.
`tag_match_mode`	No	"all" (AND) / "any" (OR). Default all.	all
`needs_deep_review`	No	True/False filter; None = no filter.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.11.2Aug 3, 2026

addedInput schema / properties / fields

Added value: +{
+  "default": "compact",
+  "description": "\"compact\" (default, trimmed projection) / \"all\" (full rows).",
+  "type": "string"
+}

addedInput schema / properties / project_id / description

Added value: +"Restrict the search to one project's archive. Empty (default)\nresolves the project from the current session — only pass it to read\nanother project's archive on purpose."

First observedv1.9.0Jul 14, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses one non-obvious behavior: the default response is a trimmed 'compact' projection that is marked by a hint and is NOT missing data — this prevents a real misinterpretation. Beyond that it says nothing about permissions, result limits (200 cap lives only in the schema), or ordering guarantees.

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?

Three short sentences with zero filler, and the important fact — that the default view is compact, not incomplete — is front-loaded. Slightly denser punctuation than ideal, but every clause earns its place.

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?

For a 17-parameter tool with an output schema, the description correctly avoids explaining return values, and its compact-projection warning is well-targeted. However, it leaves the main selection question unanswered: which ecosystem search entry point to use when. Adequate, but with a clear gap given the tool's position in a large ecosystem tool family.

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% across all 17 parameters, so the schema already documents sort, tags, limit, pagination, stars, and lifecycle filters. The description only restates `fields` behavior ("compact" vs "all"), adding no syntax or edge-case semantics beyond what the schema text already provides. 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?

States a specific verb+resource ('Query the project's ecosystem_repo_profiles archive') and names the sibling ecosystem_repo_get(repo_full_name) for single-repo lookups. It does not differentiate from the other search siblings (ecosystem_search_by_capability, unified_search, ecosystem_summary_top_n), so sibling separation is only partial.

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?

It does route one case explicitly (use ecosystem_repo_get for a full single repo, fields="all" for full rows here), which is genuinely useful. But there is no guidance on when to prefer this tool over ecosystem_search_by_capability or unified_search, which is the more likely ambiguity given ~100 siblings.

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

Deploy Server