Search and fetch AI agents, skills, prompts and MCP connectors from the Spark marketplace.
Scored across 6 tools
Most tools target clearly distinct purposes: search_assets (text query), list_popular (browse), list_categories (taxonomy), report_outcome (feedback). The only real overlap is get_asset vs get_asset_content, but descriptions explicitly contrast 'details' against 'raw content/acquisition', so an agent can choose correctly.
All six names follow a clean verb_noun snake_case pattern (get_asset, get_asset_content, list_categories, list_popular, report_outcome, search_assets). No mixed conventions or stray naming styles.
Six tools is well-scoped for a marketplace server: discovery (search, popular, categories), retrieval (get_asset, get_asset_content) and feedback (report_outcome). Each tool earns its place with no redundant surface.
The consumer-side lifecycle is largely covered: find, inspect, fetch, and report outcomes on assets. Gaps remain around purchasing paid assets and any publishing/listing-management operations, though the descriptions imply purchase happens outside this server.
Get full details of a Spark asset by its slug — description, metadata, outcome reports, bundled files and the URL on spark.entire.vc.
For when a known slug needs inspection before acquisition. Returns Markdown details, which may include embedded content; get_asset_content obtains the raw content and a receipt. Public catalog lookup, no login or download recorded. Missing or unavailable slugs return a not-found message.
For example, get_asset(slug='vb-seo-expert').
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact asset slug from a search result or Spark URL, e.g. 'vb-seo-expert'; not a URL or asset ID. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/closed-world, but the description adds real behavioral context beyond them: no login required, no download recorded, missing or unavailable slugs return a not-found message, and the Markdown response may contain embedded content. That last point is a genuine caveat an agent would not learn from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded paragraphs: purpose first, then when-to-use plus the sibling alternative, then a concrete example. Slight redundancy between the title, the opening verb phrase, and the trailing example, but nothing wasteful enough to obscure the signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 not be explained, yet the description still flags the Markdown format and embedded-content possibility. With one fully documented parameter, safety annotations, and failure behavior described, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the slug description already says 'exact asset slug… not a URL or asset ID'. The description repeats the slug concept and adds a usage example, but contributes no additional semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get full details of a Spark asset by its slug') and enumerates exactly what is returned: description, metadata, outcome reports, bundled files, and the spark.entire.vc URL. It is clearly separable from the sibling get_asset_content, which it names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly scopes usage ('For when a known slug needs inspection before acquisition') and routes the alternative case to get_asset_content for raw content and a receipt. It also states the access precondition — public catalog lookup, no login — so the agent knows no auth setup is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw content of a Spark asset (prompt text, skill instructions, agent config) — the actual text to apply, not just a description of it.
For when a known asset's content is needed for application; get_asset provides details without acquisition. Each successful fetch records a download/acquisition; repeated calls create new receipts and content may change after updates. Free content needs no login. Paid content requires a Spark API key (X-API-Key) or Bearer token and prior purchase or ownership; this tool makes no purchase. Returns content and an application_id for report_outcome, or a not-found/access message. Content may be a source link rather than embedded text.
For example, get_asset_content(slug='vb-seo-expert').
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact asset slug from a search result or Spark URL, e.g. 'vb-seo-expert'; not a URL or asset ID. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that every fetch records a download/acquisition (explaining why readOnlyHint=false and idempotentHint=false), that repeated calls create new receipts, and that content can change after updates. It also specifies auth requirements (free needs no login; paid needs X-API-Key or Bearer token plus prior purchase), states that no purchase is made, describes the return shape, and warns that content may be a source link rather than embedded text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then layers usage, side effects, and auth in scannable paragraphs, ending with an example. Each sentence carries information, though the auth/purchase passage is dense enough that it could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with full schema coverage and an output schema, nothing an agent needs to call it correctly is missing: purpose, sibling routing, side effects, auth prerequisites, and the application_id handoff to report_outcome are all present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the single slug parameter, including what it is not ('not a URL or asset ID'). The description only adds a concrete sample call, which is helpful but adds little semantic meaning beyond the structured field, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — retrieving the raw content (prompt text, skill instructions, agent config) of a Spark asset — and explicitly distinguishes the payload ('the actual text to apply, not just a description of it'). It also contrasts with the sibling get_asset, so an agent can tell the two apart without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the selection condition directly ('For when a known asset's content is needed for application') and names the alternative with its differing behavior ('get_asset provides details without acquisition'). This is exactly the when-to-use-this-vs-sibling guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available categories (domains and AI tags) in the Spark marketplace.
For when domain filter values or taxonomy are needed; search_assets returns assets rather than categories. Takes no parameters. Returns Markdown lists of AI tag names/slugs and domain names/slugs grouped by parent category; domain slugs are accepted by search_assets' domain filter. AI tags are not a search_assets filter. Public catalog lookup, no login or download recorded.
For example, list_categories().
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds non-obvious context ('Public catalog lookup, no login or download recorded'), confirming no auth or side effects. It could not add much more without redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then guidance, then return/auth details. Slightly verbose in restating return formats already implied by the output schema, but each sentence carries usable information and none is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, when-to-use, alternatives, sibling interactions, auth/side-effect posture, and return shape. With an output schema present, the description's remaining redundancy is harmless and the agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The description confirms 'Takes no parameters,' matching the empty schema, leaving nothing ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List available categories (domains and AI tags) in the Spark marketplace') and explicitly distinguishes itself from search_assets. An agent can identify the tool's scope 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the triggering condition ('when domain filter values or taxonomy are needed') and the alternative ('search_assets returns assets rather than categories'), plus the downstream usage rule that domain slugs feed search_assets' domain filter while AI tags do not. Explicit when-to-use and routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most popular Spark assets by download count, optionally filtered by type.
For when browsing without a text query; search_assets finds text matches. Returns numbered summaries with outcomes, price, tags and URLs, or 'No assets found.' Downloads measure acquisitions, not successful applications or ratings. Public catalog lookup, no login or download recorded.
For example, list_popular(type='skill', limit=5).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional asset type: agent, skill, prompt, prompt_chain, mcp_connector or bundle; omitted means all types. | |
| limit | No | Maximum results; clamped to 1-20, default 10. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and idempotency are covered. The description adds genuinely non-obvious context beyond that: downloads measure acquisitions rather than successful applications or ratings, and no login or download is recorded. It stops short of describing pagination or ordering ties, which keeps it at 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then routing, then return format and caveats, then example. Every sentence carries information, though the return-value sentence partially duplicates a schema that already exists, making it slightly longer than strictly needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only, idempotent list tool with full schema coverage and an output schema, the description covers purpose, alternative, semantic caveats on the popularity metric, and the empty-result case. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both params (type, limit) including enum values and the 1-20 clamp are already documented. The description only restates 'optionally filtered by type' and adds a sample call, which adds little beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the most popular Spark assets by download count') with an explicit optional scope ('filtered by type'). It also names the sibling search_assets and the distinction between browsing and text matching, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'For when browsing without a text query; search_assets finds text matches' gives both the when-to-use condition and the alternative tool. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records the result of applying a fetched Spark asset: applied as is, changed, broke, or not applicable. For when the outcome is known and an application_id from get_asset_content is available, rather than a star rating. Mismatched user/session receipts are rejected; asset owners cannot report on their own assets. Submitting the same application_id updates the report. Authenticated reports count, but team reports do not affect rankings; anonymous reports are unverified. Returns a saved/updated confirmation, or a validation/receipt error.
Fields task, note, changed_what, failed_at, expected, got are published on the asset's public page on spark.entire.vc, visible to any visitor. Do not include client data, private paths, keys, emails or URLs with tokens. Your identity is never shown on that page.
Example: report_outcome(application_id='', result='applied_as_is', task='add a rate limiter').
| Name | Required | Description | Default |
|---|---|---|---|
| got | No | Required for not_applicable: what the asset actually does (≤ 200 characters); ignored for other results. | |
| note | No | Optional extra context (≤ 300 characters); published on the asset page. | |
| task | Yes | Required nonempty task attempted, one phrase (≤ 200 characters); published on the asset page. | |
| model | No | Optional model name; trimmed to 100 characters. Shown, never ranked. | |
| result | Yes | applied_as_is: applied without edits, task solved. applied_with_changes: had to edit it, then solved (requires changed_what). broke: tried to apply and it failed (requires failed_at). not_applicable: read it and did not apply, it does something else (requires expected and got). | |
| expected | No | Required for not_applicable: what was sought (≤ 200 characters); ignored for other results. | |
| failed_at | No | Required for broke: failed step, tool or command and error class (≤ 200 characters); ignored for other results. | |
| changed_what | No | Required for applied_with_changes: what changed (≤ 200 characters); ignored for other results. | |
| application_id | Yes | The application_id at the end of the get_asset_content response. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, and the description reinforces idempotency ('Submitting the same application_id updates the report') plus surfaces non-obvious traits: receipt mismatch rejection, owner self-report ban, ranking behavior for authenticated vs team vs anonymous reports, and a privacy warning about publicly published fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and usage before the rules, and each sentence carries substantive facts (eligibility, ranking semantics, privacy). It is dense and long, but little of it is filler; a small amount of tightening would help readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 not be spelled out, yet the description still signals outcomes ('saved/updated confirmation, or a validation/receipt error'). Combined with usage conditions and privacy constraints, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100% and carries the conditional requirements, but the description adds genuine value with the note that task/note/changed_what/failed_at/expected/got are published to a public page and a concrete example call showing the typical three-field invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Records the result of applying a fetched Spark asset') and enumerates the four outcome values, so the agent knows exactly what domain this acts on. It is clearly distinct from read-oriented siblings like get_asset, get_asset_content, and search_assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly scopes usage: 'For when the outcome is known and an application_id from get_asset_content is available, rather than a star rating.' This names both the precondition and the alternative action, and the description further states eligibility rules (mismatched receipts rejected, owners cannot self-report).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Spark AI assets marketplace for agents, skills, prompts, prompt chains, MCP connectors and bundles.
For when a text query is available but the slug is not known; get_asset describes a known slug. Returns numbered summaries with type, downloads, outcomes, price, tags and URL, or a no-results message. No login required; no acquisition is made. Unmatched nonempty queries may be recorded as unmet catalog needs. A nonempty job ranks text matches by task fit, even with a non-combo sort.
For example, search_assets(query='rate limiting', job='add a rate limiter', limit=5).
| Name | Required | Description | Default |
|---|---|---|---|
| job | No | Optional task, e.g. 'review Python code'; a nonempty value enables job-based ranking regardless of sort. | |
| sort | No | combo (default): quality, ratings and outcomes; popular: downloads; newest: creation date; rating: average rating. Invalid values fall back to combo; job enables ranking for any sort. | combo |
| type | No | Optional asset type: agent, skill, prompt, prompt_chain, mcp_connector or bundle; omitted means all types. | |
| limit | No | Maximum results; clamped to 1-50, default 10. | |
| query | Yes | Text matched against titles and descriptions, e.g. 'rate limiting'; empty text browses the catalog. | |
| domain | No | Optional domain slug from list_categories, e.g. 'development'; omitted means all domains. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/closed-world, and the description adds genuinely new behavior: what the response contains (numbered summaries with type, downloads, outcomes, price, tags, URL), the no-results message, and the side effect that unmatched nonempty queries may be recorded as unmet catalog needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then when-to-use, then return shape, then an example — every sentence carries information. Slightly long at four paragraphs for a search tool, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the definition need not explain return values, yet it still summarizes them alongside the usage rule, side effects, and an example invocation. Nothing needed to call this six-parameter tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description's notes on job-based ranking ('a nonempty job ranks text matches by task fit, even with a non-combo sort') largely restate the job and sort schema descriptions, and the example adds no syntax beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource (the Spark AI assets marketplace), enumerates the asset types covered, and explicitly contrasts with get_asset ('get_asset describes a known slug'), so the agent can separate it from its nearest sibling 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit selection rule: use this when a text query is available but the slug is not known, and use get_asset for a known slug. It also states prerequisites (no login required) and that no acquisition occurs, which removes ambiguity about commitment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_asset1 field changedInput schema / properties / slug / descriptionPrevious value: -"Asset slug (e.g. 'vb-seo-expert', 'vb-python-expert')"New value: +"Exact asset slug from a search result or Spark URL, e.g. 'vb-seo-expert'; not a URL or asset ID."get_asset_content1 field changedInput schema / properties / slug / descriptionPrevious value: -"Asset slug"New value: +"Exact asset slug from a search result or Spark URL, e.g. 'vb-seo-expert'; not a URL or asset ID."list_popular2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Number of results (1-20, default 10)"New value: +"Maximum results; clamped to 1-20, default 10."Input schema / properties / type / descriptionPrevious value: -"Filter by asset type (agent, skill, prompt, prompt_chain, mcp_connector, bundle)"New value: +"Optional asset type: agent, skill, prompt, prompt_chain, mcp_connector or bundle; omitted means all types."report_outcome7 fields changedInput schema / properties / changed_what / descriptionPrevious value: -"applied_with_changes: what you changed (≤ 200)."New value: +"Required for applied_with_changes: what changed (≤ 200 characters); ignored for other results."Input schema / properties / expected / descriptionPrevious value: -"not_applicable: what you were looking for (≤ 200)."New value: +"Required for not_applicable: what was sought (≤ 200 characters); ignored for other results."Input schema / properties / failed_at / descriptionPrevious value: -"broke: the step, tool or command that failed, and the error class (≤ 200)."New value: +"Required for broke: failed step, tool or command and error class (≤ 200 characters); ignored for other results."Input schema / properties / got / descriptionPrevious value: -"not_applicable: what it actually does (≤ 200)."New value: +"Required for not_applicable: what the asset actually does (≤ 200 characters); ignored for other results."Input schema / properties / model / descriptionPrevious value: -"The model you run on, if you know it. Shown, never ranked."New value: +"Optional model name; trimmed to 100 characters. Shown, never ranked."Input schema / properties / note / descriptionPrevious value: -"Anything else worth knowing (≤ 300)."New value: +"Optional extra context (≤ 300 characters); published on the asset page."Input schema / properties / task / descriptionPrevious value: -"What you were trying to do, one phrase (≤ 200)."New value: +"Required nonempty task attempted, one phrase (≤ 200 characters); published on the asset page."search_assets6 fields changedInput schema / properties / domain / descriptionPrevious value: -"Filter by domain slug (e.g. 'development', 'marketing')"New value: +"Optional domain slug from list_categories, e.g. 'development'; omitted means all domains."Input schema / properties / job / descriptionPrevious value: -"Job/task the agent is trying to accomplish. Enables job-based relevance ranking (e.g. 'review Python code', 'generate marketing copy', 'analyze data')."New value: +"Optional task, e.g. 'review Python code'; a nonempty value enables job-based ranking regardless of sort."Input schema / properties / limit / descriptionPrevious value: -"Number of results (1-50, default 10)"New value: +"Maximum results; clamped to 1-50, default 10."Input schema / properties / query / descriptionPrevious value: -"Search text (matches title and description)"New value: +"Text matched against titles and descriptions, e.g. 'rate limiting'; empty text browses the catalog."Input schema / properties / sort / descriptionPrevious value: -"Sort order: combo, popular, newest, rating. 'combo' = combined quality+ratings+agent outcomes score (default)."New value: +"combo (default): quality, ratings and outcomes; popular: downloads; newest: creation date; rating: average rating. Invalid values fall back to combo; job enables ranking for any sort."Input schema / properties / type / descriptionPrevious value: -"Filter by asset type (agent, skill, prompt, prompt_chain, mcp_connector, bundle)"New value: +"Optional asset type: agent, skill, prompt, prompt_chain, mcp_connector or bundle; omitted means all types."report_outcome1 field changedInput schema / properties / application_id / descriptionPrevious value: -"The application_id printed at the end of get_asset_content."New value: +"The application_id at the end of the get_asset_content response."search_assets2 fields changedInput schema / properties / job / descriptionPrevious value: -"Job/task the agent is trying to accomplish. Enables job-based relevance ranking (e.g. 'review Python code', 'generate marketing copy', 'analyze data'). Recommended for agent use."New value: +"Job/task the agent is trying to accomplish. Enables job-based relevance ranking (e.g. 'review Python code', 'generate marketing copy', 'analyze data')."Input schema / properties / sort / descriptionPrevious value: -"Sort order: combo, popular, newest, rating. 'combo' = combined quality+ratings+agent outcomes score (default, recommended)."New value: +"Sort order: combo, popular, newest, rating. 'combo' = combined quality+ratings+agent outcomes score (default)."get_assetget_asset_contentlist_categorieslist_popularreport_outcomesearch_assetsDiscover and retrieve published Amo.ng Prompts, Workflows, and Skills.
Search and fetch AI agent skills, rules files and MCP servers indexed from GitHub.
Search and fetch skills from your org's Skills and Agents catalog. Bearer token required.
Search AI capabilities across AWS Marketplace and the Official MCP Registry.
Add one secure layer between your agents and this server.
