A
licenseA
qualityC
maintenanceSearch and discover 3,500+ AI tools, MCP servers, and Claude Skills with community ratings. Find the best tools by category, compatibility, and real user reviews.
3
64 npm
MIT
Skill of Skills
Server Details
Quality-ranked, cross-platform directory of AI coding skills, plugins and MCP servers.
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
- Uptime
- 100.0% over 47 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- the911fund/skill-of-skills
- GitHub Stars
- 11
TDQS
A4.2/5.0
Scored across 6 tools
Disambiguation5/5
Each tool has a distinct purpose: search, retrieve single profile, compare multiple, browse collections, list collections, and demand analytics. No two tools overlap in functionality; an agent can easily select the right one for the task.
Naming Consistency4/5
Five of six tools follow the verb_noun pattern (compare_tools, get_collection, get_skill, list_collections, search_skills). Only demand_pulse deviates, being a noun phrase rather than verb_noun, creating a minor inconsistency.
Tool Count5/5
Six tools is well-scoped for a directory service: search, details, comparison, collection browsing, collection listing, and demand stats. Each tool adds distinct value without redundancy or bloat.
Completeness5/5
The surface fully covers the read-only directory use case: full-text search, curated collections, individual profiles, side-by-side comparison, and demand trends. No obvious missing operations for the stated purpose.
Available Tools
6 toolscompare_toolsCompare toolsARead-onlyIdempotentInspect
Side-by-side quality profiles for 2–5 tools by slug. Same fields as get_skill; ordering follows the request, not rank.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| compared | Yes | |
| not_found | No |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's burden is lower. It adds a meaningful behavior: ordering follows the request rather than rank, which clarifies output ordering. But it does not disclose potential limitations, error handling, or rate limits. Given the annotations cover safety and idempotency, a 3 is appropriate – the description adds some context but not rich behavioral detail.
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 sentences with zero redundancy. The primary purpose is front-loaded, and the secondary ordering detail is appended. Every word contributes meaning. This is exemplary conciseness.
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?
The tool is simple: one parameter, output schema exists, and annotations cover safety. The description covers purpose, ordering, and references get_skill for consistency. It lacks explicit guidance on when to use it over siblings, but that's partially covered in usage guidelines. For a read-only comparison tool, this is nearly complete – the only minor gap is an explicit statement of use cases vs. alternatives.
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 0%, so the description must compensate. It does clarify that the array parameter 'slugs' refers to tool slugs and that 2–5 are expected, aligning with schema's minItems/maxItems. However, it doesn't explain the pattern or maxLength constraints (though these are in the schema). Since there's only one parameter and the description gives the essential semantics, a 3 is reasonable – it adds value but not exhaustive detail.
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 clearly states the tool's purpose: producing side-by-side quality profiles for 2–5 tools by slug. It distinguishes itself from the sibling get_skill by explicitly noting 'Same fields as get_skill', implying a comparison vs. single retrieval. The verb 'compare' and resource 'tools' are specific and unambiguous.
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 implies usage context: when you need to compare multiple tools, use this; when you need a single tool's profile, use get_skill (referenced). However, it doesn't explicitly state 'when not to use' or mention alternatives like search_skills. The ordering note ('follows the request, not rank') is a useful behavioral cue but doesn't address selection conditions fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
demand_pulseDemand pulseARead-onlyIdempotentInspect
Public, k-anonymous demand signal from the directory: trending searches, most-saved and most-installed tools. Aggregates only — sourced from ≥5 distinct anonymous sessions per entry.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| most_saved | Yes | |
| most_installed | Yes | |
| trending_searches | Yes | |
| total_interactions | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: the k-anonymity guarantee (≥5 distinct anonymous sessions per entry) and the 'Aggregates only' privacy constraint, which are important behavioral traits not visible in the schema.
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 no waste. The first sentence states the core purpose and data types; the second adds the critical privacy/aggregation constraint. Every word earns its place.
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?
For a parameterless, read-only tool with an output schema present, the description is complete. It explains what the tool returns, the privacy model, and the aggregation source. The output schema presumably details the response structure, so the description doesn't need to.
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?
The tool has 0 parameters, so there is no parameter semantics to document. The description compensates by explaining what the output represents (trending searches, most-saved, most-installed) and the aggregation guarantee, which is the closest thing to parameter semantics for a parameterless tool.
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 clearly identifies the tool as a public, k-anonymous demand signal from the directory, listing the specific data types it provides (trending searches, most-saved, most-installed tools). It distinguishes itself from sibling tools like search_skills or get_skill by emphasizing aggregated, anonymous demand data rather than individual tool details or collections.
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 implies this is for retrieving aggregate demand signals, and the 'Public' label plus 'Aggregates only' clarifies when it's appropriate. It doesn't explicitly name alternatives or state when not to use it, but the context signals (0 params, read-only) and sibling names make the use case clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_collectionGet collectionARead-onlyIdempotentInspect
Quality-ranked tools inside one curated collection. Critical-risk tools are excluded by default (risk_filter); every result carries risk_level and risk_reasons.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| limit | No | ||
| risk_filter | No | Risk gate: exclude_critical omits critical risk (default); exclude_high omits high and critical risk; none omits no risk levels | exclude_critical |
| include_high_risk | No | Deprecated alias for risk_filter=none |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| results | Yes | |
| collection | Yes | |
| total_in_collection | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the default risk_filter behavior (excluding critical risk) and that every result carries risk_level and risk_reasons. This goes beyond annotations without contradicting them.
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 a single, dense sentence that front-loads the core purpose (curated, quality-ranked collection) and then the key behavior (risk filtering). No wasted words; every phrase adds value.
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?
Given the output schema exists (so return values are defined), annotations cover safety, and the description explains the critical risk_filter behavior, the definition is nearly complete. It doesn't mention pagination or sorting, but limit is in the schema. The only gap is not explicitly routing to siblings, but that's covered by usage guidelines and overall context is sufficient.
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 50% (risk_filter and include_high_risk have descriptions, slug and limit do not). The description explicitly mentions risk_filter and its default behavior, partially compensating. Slug is an enum with clear values and limit has min/max in the schema, so they are self-explanatory. The description adds some value but does not fully cover all parameters.
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 clearly states the tool returns a curated, quality-ranked collection of tools, and explicitly mentions the risk filtering default and the presence of risk_level/risk_reasons fields. This distinguishes it from siblings like search_skills (searching) and list_collections (listing all collections), making the purpose unambiguous.
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 implies when to use it (when you want a curated, quality-ranked set of tools from a collection) but does not explicitly state alternatives or exclusions. The sibling list suggests potential confusion, but no direct 'use this instead of X' guidance is provided. It's adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_skillGet skill profileARead-onlyIdempotentInspect
Full quality profile for one tool by slug (slugs come from search_skills / get_collection): score breakdown, structural signals, risk level and reasons, platforms, repo link. Direct lookups return any active tool regardless of risk — the risk assessment is part of the answer, not a filter here.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| slug | Yes | |
| tier | Yes | |
| type | Yes | |
| forks | Yes | |
| stars | Yes | |
| scores | Yes | |
| license | Yes | |
| category | Yes | |
| repo_url | Yes | |
| platforms | Yes | |
| risk_level | Yes | |
| updated_at | Yes | |
| description | Yes | |
| is_official | Yes | |
| profile_url | Yes | |
| risk_reasons | Yes | |
| discovered_at | Yes | |
| quality_score | Yes | |
| readme_length | Yes | |
| release_count | Yes | |
| last_commit_at | Yes | |
| composite_score | Yes | |
| latest_release_at | Yes | |
| structural_signals | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral nuance: it states that risk assessment is part of the answer, not a filter, and that any active tool is returned. This goes beyond the annotations and clarifies a potentially surprising behavior. No contradiction with annotations.
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 sentences with zero fluff. The primary purpose is front-loaded, and the behavioral nuance about risk filtering is placed second. Every sentence earns its place, and the structure is optimal for quick parsing by an agent.
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?
For a single-parameter lookup tool, the description is complete. It lists exactly what the profile includes (score breakdown, structural signals, risk level and reasons, platforms, repo link) and clarifies the risk-filtering behavior. The agent has everything needed to call the tool correctly and interpret the response.
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?
The schema only describes the slug parameter with a pattern, but the description adds crucial meaning: slugs come from search_skills / get_collection. This compensates for the 0% schema description coverage by telling the agent exactly how to obtain a valid slug value, making the parameter semantics much clearer than the schema alone.
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 clearly states the verb (get), the resource (full quality profile for one tool), and the identifying key (by slug). It also distinguishes this tool from siblings by noting that slugs come from search_skills / get_collection, making its purpose unmistakable.
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 provides explicit context on when to use this tool: after obtaining a slug from search_skills or get_collection. It also clarifies that direct lookups return any active tool regardless of risk, which helps an agent decide when this tool is appropriate. However, it doesn't explicitly state when not to use it or name alternative tools for different use cases, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_collectionsList collectionsARead-onlyIdempotentInspect
The curated buyer-intent collections (e.g. mcp-servers, testing-qa, browser-automation). Use get_collection for the ranked tools inside one.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| collections | Yes |
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds context that the collections are curated and buyer-intent oriented, but does not describe return shape, ordering, or pagination behavior. Since the annotations carry the behavioral burden, a middle score is appropriate.
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 sentences with no filler. It front-loads the core subject, provides concrete examples, and immediately routes to the relevant sibling tool. Every sentence earns its place.
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?
For a zero-parameter, read-only list operation with a full output schema and robust annotations, the description is complete. It indicates what is returned, gives representative values, and distinguishes this tool from the closely related sibling. Nothing material is missing.
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?
The tool has zero parameters)Skip; with no parameters and 100% schema coverage, the description need not explain parameter behavior. It still adds value by naming example collections, which helps an agent understand the domain, so a 4 is reasonable.
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 title and description together clearly identify the tool as listing curated buyer-intent collections, with concrete examples of what those collections are. It explicitly distinguishes itself from get_collection, which returns the ranked tools inside a single collection, so an agent can tell them apart immediately.
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 provides clear routing by saying to use get_collection when the agent needs the ranked tools inside a specific collection. It implies the proper use case for this tool, though it does not enumerate exclusions beyond that one sibling. This is adequate but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_skillsSearch skillsARead-onlyIdempotentInspect
Full-text search over the Skill of Skills directory (AI coding skills, plugins, MCP servers across Claude Code, Cursor, Codex, Windsurf, Cline). Results are ranked by the quality-first composite score, not popularity; when no tool matches every term, the closest partial matches are returned instead (match_mode: "any"), most relevant first. Critical-risk tools are excluded by default (risk_filter); every result carries risk_level and risk_reasons. Scores are evidence, not endorsements.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | What capability you need, e.g. "postgres migrations" | |
| min_tier | No | Quality floor: curated ≥120, promising ≥80, experimental ≥40 | experimental |
| platform | No | Restrict to one client platform | |
| risk_filter | No | Risk gate: exclude_critical omits critical risk (default); exclude_high omits high and critical risk; none omits no risk levels | exclude_critical |
| include_high_risk | No | Deprecated alias for risk_filter=none |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| query | Yes | |
| results | Yes | |
| match_mode | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds valuable behavioral detail: ranking by composite score instead of popularity, partial-match fallback (match_mode: 'any'), default risk filtering, and that results carry risk_level and risk_reasons. This goes beyond the annotations without contradicting them.
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 three sentences, front-loaded with the primary purpose, then detailing ranking and matching behavior, then risk filtering. No redundant phrases; every sentence contributes to understanding the tool's behavior and output.
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?
Given the tool has an output schema and rich annotations, the description covers the essential behavioral aspects: ranking logic, matching mode, risk filtering, and result attributes. It omits minor details like pagination or response format, but these are not critical for the agent to invoke the tool correctly.
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 high (83%), so the baseline is 3. The description adds context around risk_filter and the ranking behavior that affects query handling, but it does not provide per-parameter meaning beyond what the schema already offers (e.g., limit and min_tier are left to the schema). It adds modest value but does not fully compensate for any missing schema descriptions.
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 clearly states a specific verb ('full-text search') and a specific resource (the Skill of Skills directory), and even names the covered platforms and categories. However, it does not explicitly differentiate from sibling tools like get_skill or list_collections, so an agent might not immediately know when to prefer this over a more targeted retrieval tool.
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 implies the tool is for searching when you need to find skills by capability, but it does not explicitly state when to use it versus alternatives such as get_skill (for a specific skill) or compare_tools. No exclusions or alternative routing are provided.
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.
6 tool updates
- Changed
compare_tools2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "compared": { + "items": { + "additionalProperties": false, + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "composite_score": { + "type": "number" + }, + "description": { + "type": "string" + }, + "discovered_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "forks": { + "type": "number" + }, + "is_official": { + "type": "boolean" + }, + "last_commit_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "latest_release_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "license": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "platforms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "profile_url": { + "type": "string" + }, + "quality_score": { + "type": "number" + }, + "readme_length": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "release_count": { + "type": "number" + }, + "repo_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "risk_level": { + "type": "string" + }, + "risk_reasons": { + "items": { + "type": "string" + }, + "type": "array" + }, + "scores": { + "additionalProperties": false, + "properties": { + "composite": { + "type": "number" + }, + "github": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "quality": { + "type": "number" + }, + "recency": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "social": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "star_velocity_30d": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "trending": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "quality", + "composite", + "github", + "social", + "recency", + "trending", + "star_velocity_30d" + ], + "type": "object" + }, + "slug": { + "type": "string" + }, + "stars": { + "type": "number" + }, + "structural_signals": { + "additionalProperties": false, + "properties": { + "config_files": { + "type": "boolean" + }, + "examples": { + "type": "boolean" + }, + "gotchas": { + "type": "boolean" + }, + "progressive_disclosure": { + "type": "boolean" + }, + "scripts": { + "type": "boolean" + }, + "skill_md": { + "type": "boolean" + }, + "verification": { + "type": "boolean" + } + }, + "required": [ + "skill_md", + "examples", + "gotchas", + "verification", + "scripts", + "progressive_disclosure", + "config_files" + ], + "type": "object" + }, + "tier": { + "enum": [ + "curated", + "promising", + "experimental", + "review_required" + ], + "type": "string" + }, + "type": { + "type": "string" + }, + "updated_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "name", + "slug", + "tier", + "quality_score", + "composite_score", + "risk_level", + "risk_reasons", + "type", + "category", + "platforms", + "description", + "repo_url", + "profile_url", + "stars", + "is_official", + "last_commit_at", + "license", + "forks", + "scores", + "structural_signals", + "readme_length", + "release_count", + "latest_release_at", + "discovered_at", + "updated_at" + ], + "type": "object" + }, + "type": "array" + }, + "not_found": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "compared" + ], + "type": "object" +}
- Changed
demand_pulse2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "most_installed": { + "items": { + "additionalProperties": false, + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "sessions": { + "type": "number" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "name", + "slug", + "category", + "sessions" + ], + "type": "object" + }, + "type": "array" + }, + "most_saved": { + "items": { + "additionalProperties": false, + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "sessions": { + "type": "number" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "name", + "slug", + "category", + "sessions" + ], + "type": "object" + }, + "type": "array" + }, + "total_interactions": { + "type": "number" + }, + "trending_searches": { + "items": { + "additionalProperties": false, + "properties": { + "query": { + "type": "string" + }, + "sessions": { + "type": "number" + } + }, + "required": [ + "query", + "sessions" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "total_interactions", + "trending_searches", + "most_saved", + "most_installed" + ], + "type": "object" +}
- Changed
get_collection2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "collection": { + "additionalProperties": false, + "properties": { + "slug": { + "type": "string" + }, + "tagline": { + "type": "string" + }, + "title": { + "type": "string" + } + }, + "required": [ + "slug", + "title", + "tagline" + ], + "type": "object" + }, + "count": { + "type": "number" + }, + "results": { + "items": { + "additionalProperties": false, + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "composite_score": { + "type": "number" + }, + "description": { + "type": "string" + }, + "is_official": { + "type": "boolean" + }, + "last_commit_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "platforms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "profile_url": { + "type": "string" + }, + "quality_score": { + "type": "number" + }, + "repo_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "risk_level": { + "type": "string" + }, + "risk_reasons": { + "items": { + "type": "string" + }, + "type": "array" + }, + "slug": { + "type": "string" + }, + "stars": { + "type": "number" + }, + "tier": { + "enum": [ + "curated", + "promising", + "experimental", + "review_required" + ], + "type": "string" + }, + "type": { + "type": "string" + } + }, + "required": [ + "name", + "slug", + "tier", + "quality_score", + "composite_score", + "risk_level", + "risk_reasons", + "type", + "category", + "platforms", + "description", + "repo_url", + "profile_url", + "stars", + "is_official", + "last_commit_at" + ], + "type": "object" + }, + "type": "array" + }, + "total_in_collection": { + "type": "number" + } + }, + "required": [ + "collection", + "total_in_collection", + "count", + "results" + ], + "type": "object" +}
- Changed
get_skill2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "composite_score": { + "type": "number" + }, + "description": { + "type": "string" + }, + "discovered_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "forks": { + "type": "number" + }, + "is_official": { + "type": "boolean" + }, + "last_commit_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "latest_release_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "license": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "platforms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "profile_url": { + "type": "string" + }, + "quality_score": { + "type": "number" + }, + "readme_length": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "release_count": { + "type": "number" + }, + "repo_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "risk_level": { + "type": "string" + }, + "risk_reasons": { + "items": { + "type": "string" + }, + "type": "array" + }, + "scores": { + "additionalProperties": false, + "properties": { + "composite": { + "type": "number" + }, + "github": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "quality": { + "type": "number" + }, + "recency": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "social": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "star_velocity_30d": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + }, + "trending": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "quality", + "composite", + "github", + "social", + "recency", + "trending", + "star_velocity_30d" + ], + "type": "object" + }, + "slug": { + "type": "string" + }, + "stars": { + "type": "number" + }, + "structural_signals": { + "additionalProperties": false, + "properties": { + "config_files": { + "type": "boolean" + }, + "examples": { + "type": "boolean" + }, + "gotchas": { + "type": "boolean" + }, + "progressive_disclosure": { + "type": "boolean" + }, + "scripts": { + "type": "boolean" + }, + "skill_md": { + "type": "boolean" + }, + "verification": { + "type": "boolean" + } + }, + "required": [ + "skill_md", + "examples", + "gotchas", + "verification", + "scripts", + "progressive_disclosure", + "config_files" + ], + "type": "object" + }, + "tier": { + "enum": [ + "curated", + "promising", + "experimental", + "review_required" + ], + "type": "string" + }, + "type": { + "type": "string" + }, + "updated_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "name", + "slug", + "tier", + "quality_score", + "composite_score", + "risk_level", + "risk_reasons", + "type", + "category", + "platforms", + "description", + "repo_url", + "profile_url", + "stars", + "is_official", + "last_commit_at", + "license", + "forks", + "scores", + "structural_signals", + "readme_length", + "release_count", + "latest_release_at", + "discovered_at", + "updated_at" + ], + "type": "object" +}
- Changed
list_collections2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "collections": { + "items": { + "additionalProperties": false, + "properties": { + "slug": { + "type": "string" + }, + "tagline": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "slug", + "title", + "tagline", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "collections" + ], + "type": "object" +}
- Changed
search_skills2 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "count": { + "type": "number" + }, + "match_mode": { + "enum": [ + "all", + "any" + ], + "type": "string" + }, + "query": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": false, + "properties": { + "category": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "composite_score": { + "type": "number" + }, + "description": { + "type": "string" + }, + "is_official": { + "type": "boolean" + }, + "last_commit_at": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "name": { + "type": "string" + }, + "platforms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "profile_url": { + "type": "string" + }, + "quality_score": { + "type": "number" + }, + "repo_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "risk_level": { + "type": "string" + }, + "risk_reasons": { + "items": { + "type": "string" + }, + "type": "array" + }, + "slug": { + "type": "string" + }, + "stars": { + "type": "number" + }, + "tier": { + "enum": [ + "curated", + "promising", + "experimental", + "review_required" + ], + "type": "string" + }, + "type": { + "type": "string" + } + }, + "required": [ + "name", + "slug", + "tier", + "quality_score", + "composite_score", + "risk_level", + "risk_reasons", + "type", + "category", + "platforms", + "description", + "repo_url", + "profile_url", + "stars", + "is_official", + "last_commit_at" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "query", + "count", + "match_mode", + "results" + ], + "type": "object" +}
2 tool updates
- Changed
get_collection3 fields changed- removed
Input schema / properties / include_high_risk / defaultRemoved value: -false - added
Input schema / properties / include_high_risk / descriptionAdded value: +"Deprecated alias for risk_filter=none" - added
Input schema / properties / risk_filterAdded value: +{ + "default": "exclude_critical", + "description": "Risk gate: exclude_critical omits critical risk (default); exclude_high omits high and critical risk; none omits no risk levels", + "enum": [ + "exclude_critical", + "exclude_high", + "none" + ], + "type": "string" +}
- Changed
search_skills3 fields changed- removed
Input schema / properties / include_high_risk / defaultRemoved value: -false - changed
Input schema / properties / include_high_risk / descriptionPrevious value: -"Also return tools assessed high/critical risk (off by default)"New value: +"Deprecated alias for risk_filter=none" - added
Input schema / properties / risk_filterAdded value: +{ + "default": "exclude_critical", + "description": "Risk gate: exclude_critical omits critical risk (default); exclude_high omits high and critical risk; none omits no risk levels", + "enum": [ + "exclude_critical", + "exclude_high", + "none" + ], + "type": "string" +}
6 tool updates
- First observed
compare_tools - First observed
demand_pulse - First observed
get_collection - First observed
get_skill - First observed
list_collections - First observed
search_skills
Related MCP Connectors
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Search and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
One AI endpoint to search and call 22k+ MCP servers; 50+ hosted tools work instantly, no key.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI agents to search a directory of 13,870+ MCP servers, 4,384+ agent skills, and plugins from Remote OpenClaw, returning install commands directly.357 npm6MIT
- AlicenseNot gradedqualityDmaintenanceA powerful MCP server that brings the skills.sh ecosystem directly to your AI agents, enabling effortless discovery, installation, and management of skills.1MIT
- AlicenseAqualityDmaintenanceMCP server for discovering and installing AI agent skills from Loaditout. Search 20,000+ security-gradedMCP servers, check A/B/C/F grades, get install configs, and browse trending skills and curated packs.2145 npm1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.