Search and fetch AI agents, skills, prompts and MCP connectors from the Spark marketplace.
Scored across 6 tools
Each tool has a distinct role: browsing categories, browsing popular assets, searching, fetching asset metadata, fetching raw content, and reporting outcomes. The closest pair is get_asset and get_asset_content, but their descriptions clearly separate metadata/files from raw content acquisition.
Most names follow a consistent verb_noun pattern in snake_case, such as get_asset, list_categories, and search_assets. list_popular is a minor deviation because it omits the noun 'assets', but the overall convention remains predictable.
Six tools is well-scoped for a marketplace: discovery tools, detail/content retrieval, and outcome reporting. There are no redundant or filler tools, and each adds a distinct capability.
The tool surface covers the full agent-facing workflow: discover assets, inspect details, fetch content, and report real-world outcomes. Since the marketplace is read/apply-oriented, the lack of upload, sell, or purchase tools is not a meaningful gap.
Get full details of a Spark asset by its slug.
Returns description, metadata, outcome reports, files, and the URL on spark.entire.vc.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Asset slug (e.g. 'vb-seo-expert', 'vb-python-expert') |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It makes the read-only nature and return contents clear ('Get full details... Returns description, metadata, outcome reports, files, and the URL'), but it does not mention error behavior, access requirements, or rate limits. For a simple read tool this is adequate but not exceptional.
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?
The description is two concise sentences with no filler. The first sentence states the core action and scope, and the second lists the returned data fields, making it easy for an agent to quickly assess purpose and output.
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 only one required parameter and an output schema present, the description is largely complete for a simple lookup operation. It could be slightly stronger by clarifying how it relates to get_asset_content or when to prefer this tool over search_assets, but nothing essential about invoking it 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%, and the slug parameter already includes explanatory text and examples. The description adds no new parameter-level meaning beyond restating that the lookup is by slug, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get full details of a Spark asset by its slug') and clearly identifies the resource and key. It also enumerates the returned fields, which helps distinguish it from sibling tools like get_asset_content that likely return only a subset.
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?
The description gives no explicit guidance on when to use this tool versus alternatives such as get_asset_content or search_assets. It implies usage by slug, but it does not state any exclusions or provide routing cues, leaving the agent to infer when this is the right choice.
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).
This counts as a download/acquisition event. For paid assets, authentication is required — add your Spark API key (X-API-Key header) or a Bearer token to your MCP client configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Asset slug |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explicitly discloses that the call counts as a download/acquisition event and that authentication is required for paid assets, which is meaningful non-obvious behavior beyond simply 'getting content'.
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?
The description is compact and well-structured: a clear purpose statement in the first sentence, followed by essential caveats in the second. Every sentence earns its place with no redundancy.
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 an output schema, the description covers the key operational details: purpose, acquisition-event semantics, and authentication requirements. It is complete enough to call correctly, though explicit sibling differentiation would make it fully robust.
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%, and the slug parameter is fully documented in the input schema as 'Asset slug'. The description adds no additional meaning to the parameter, 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?
The description uses a specific verb ('Get') and resource ('raw content of a Spark asset') with concrete examples (prompt text, skill instructions, agent config). This clearly differentiates it from sibling get_asset by focusing on raw content rather than asset metadata.
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?
The description provides useful context—this counts as a download/acquisition event and paid assets require authentication—but it never explicitly says when to prefer this tool over get_asset or other siblings. The usage is implied rather than stated.
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.
Useful for filtering searches by domain or AI model compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It indicates a read-only operation through the verb 'List' but does not disclose any potential side effects, authentication requirements, or rate limits. For a simple list tool, this is minimal but not contradictory.
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?
The description is two concise sentences with no fluff. The main purpose is front-loaded, and the second sentence adds practical usage guidance. Every word earns its place.
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 zero-parameter tool with an output schema, the description covers the essential information: what is listed and why it's useful. It does not describe output format, but that is covered by the output schema. The description is complete enough for an agent 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?
There are no parameters in the schema, so the description need not explain any. The baseline for 0 parameters is 4, and the description does not introduce any parameter-related ambiguity.
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?
The description states a specific verb ('List') and resource ('available categories (domains and AI tags) in the Spark marketplace'). It clearly distinguishes this from sibling tools like search_assets by specifying the domain of categories. The additional sentence on filtering searches reinforces its purpose.
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?
The description provides a clear use case: 'Useful for filtering searches by domain or AI model compatibility.' This implies when an agent needs to retrieve valid filter values for search_assets. It does not explicitly name alternatives, but the context is sufficient for a simple list tool.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by asset type (agent, skill, prompt, prompt_chain, mcp_connector, bundle) | |
| limit | No | Number of results (1-20, default 10) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the ordering criterion (download count) and the filterable asset types, but doesn't mention pagination, whether results are cached, or what the response structure looks like. The output schema exists, so return values are covered elsewhere.
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?
A single, clear sentence that front-loads the core purpose. No wasted words.
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 simple list tool with two optional parameters and an output schema, the description is nearly complete. It could mention whether the list is sorted descending or if there are any rate limits, but these are minor gaps given the output schema covers return structure.
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 the schema already documents both parameters. The description adds the context that 'popular' means by download count, which gives meaning to the limit parameter, but doesn't add syntax details beyond the schema.
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?
The description clearly states the tool lists popular Spark assets by download count, which is a specific verb and resource. It distinguishes itself from siblings like search_assets and get_asset, though it doesn't explicitly name them.
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?
The description implies usage for discovering top assets, but doesn't explicitly state when to use this over search_assets or list_categories. The context signals show siblings, but the description itself provides no direct comparison or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what happened when you applied an asset you fetched with get_asset_content. Call it once you know: applied as is, applied with changes, broke, or not applicable. The next agent choosing this asset reads the outcomes in search results. Reports made with an API key count; anonymous ones are stored as unverified. Calling again with the same application_id updates your report.
Fields task, note, changed_what, failed_at, expected, got are shown to the asset's author. Do not include client data, private paths, keys, emails or URLs with tokens. Your identity is never shown to the author.
| Name | Required | Description | Default |
|---|---|---|---|
| got | No | not_applicable: what it actually does (≤ 200). | |
| note | No | Anything else worth knowing (≤ 300). | |
| task | Yes | What you were trying to do, one phrase (≤ 200). | |
| model | No | The model you run on, if you know it. 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 | not_applicable: what you were looking for (≤ 200). | |
| failed_at | No | broke: the step, tool or command that failed, and the error class (≤ 200). | |
| changed_what | No | applied_with_changes: what you changed (≤ 200). | |
| application_id | Yes | The application_id printed at the end of get_asset_content. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so thoroughly: it discloses verification status for API-key vs anonymous reports, update semantics for repeated application_id calls, author visibility of specific fields, and identity privacy. These are exactly the behavioral traits an agent needs beyond 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?
The description is front-loaded with purpose and trigger conditions, then moves to persistence, update behavior, and privacy constraints. Every sentence adds operational value, and the format is easy to scan despite covering several distinct behavioral aspects.
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 tool with conditional parameter requirements and an output schema, the description plus schema fully cover what an agent needs: when to call, what outcomes exist, update semantics, author visibility, and privacy rules. The output schema handles return values, so no additional explanation is required.
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 provides detailed per-field descriptions and conditional requirements. The description adds useful privacy/visibility context for certain fields, but does not add much parameter-level meaning beyond what the schema already contains, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Report what happened when you applied an asset you fetched with get_asset_content.' It names the four outcome categories, making the tool's function unmistakable and clearly distinct from the retrieval-focused siblings.
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?
It explicitly states when to call ('once you know: applied as is, applied with changes, broke, or not applicable') and provides useful downstream context about search results. It does not explicitly say when not to use it or name alternatives, but the trigger condition is clear enough for correct selection.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| job | No | 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. | |
| sort | No | Sort order: combo, popular, newest, rating. 'combo' = combined quality+ratings+agent outcomes score (default, recommended). | combo |
| type | No | Filter by asset type (agent, skill, prompt, prompt_chain, mcp_connector, bundle) | |
| limit | No | Number of results (1-50, default 10) | |
| query | Yes | Search text (matches title and description) | |
| domain | No | Filter by domain slug (e.g. 'development', 'marketing') |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and only says it searches, offering no detail about result behavior, default ranking, or side effects. It implies a read-only operation but does not disclose additional behavioral traits.
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?
One front-loaded sentence that conveys the core purpose with no filler. It is appropriately sized for a tool whose invocation details live in the schema.
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 search tool with six fully documented parameters and an output schema, the one-line description plus schema provides enough invocation context. The main omission is sibling-routing guidance, but that is covered under usage guidelines.
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 query, job, sort, type, domain, and limit are already documented. The description adds no additional parameter meaning beyond what the input schema provides, matching the baseline baseline for high schema coverage.
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: search across the Spark AI assets marketplace, which distinguishes it from sibling get/list tools. The purpose is unambiguous even without inspecting the 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?
The description gives no guidance about when to use this tool versus list_popular, list_categories, or get_asset. It neither states when this tool should be preferred nor mentions any exclusions.
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_assetget_asset_contentlist_categorieslist_popularreport_outcomesearch_assetsSearch and install curated agent skills, plus bundles that get one job done in a single call.
Discover 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.
Add one secure layer between your agents and this server.
