Spark - AI Assets Marketplace

Report outcome

report_outcome

Idempotent

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').

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 2, 2026

changedInput schema / properties / changed_what / description

Previous value: -"applied_with_changes: what you changed (≤ 200)."New value: +"Required for applied_with_changes: what changed (≤ 200 characters); ignored for other results."

changedInput schema / properties / expected / description

Previous value: -"not_applicable: what you were looking for (≤ 200)."New value: +"Required for not_applicable: what was sought (≤ 200 characters); ignored for other results."

changedInput schema / properties / failed_at / description

Previous 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."

changedInput schema / properties / got / description

Previous 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."

changedInput schema / properties / model / description

Previous 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."

changedInput schema / properties / note / description

Previous value: -"Anything else worth knowing (≤ 300)."New value: +"Optional extra context (≤ 300 characters); published on the asset page."

changedInput schema / properties / task / description

Previous 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."

Changed1 schema field changedSep 24, 2026

changedInput schema / properties / application_id / description

Previous 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."

First observedSep 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need 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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Spark - AI Assets Marketplace tools Inspect

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.