Graunt

Server Details

The agent-native marketplace for AI data: search listings and read their price and rights.

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 54 days
Last Tested: 2026-10-31 18:36
Transport: Streamable HTTP · MCP 2025-06-18
URL

TDQS

B3.4/5.0

Scored 2026-10-31 17:55 across 10 tools

Disambiguation3/5

There are several overlapping pairs: fetch vs get_asset both read a listing by id, and search vs search_assets both search the catalog. The descriptions provide guidance on which to use, but the boundaries remain blurry enough that an agent could easily misselect. Manifest tools are more distinct but still cluster around similar listing metadata.

Naming Consistency3/5

All names use snake_case, but the verb conventions are mixed: bare verbs (fetch, search), get_* tools, match_video_spec, and meta_* tools. The pattern is readable but not predictably consistent across the set.

Tool Count5/5

Ten tools is well within the typical 3-15 range and appears appropriately scoped for a catalog/search/manifest server. Each tool corresponds to a distinct capability area, even where naming overlaps.

Completeness4/5

The surface covers catalog search, listing retrieval, commerce/manifest details, file/bundle manifests, video spec matching, and meta capabilities. Minor gaps may exist around explicit category listing or purchase workflow, but core read/discovery workflows are covered.

Available Tools

10 tools

fetchRead a Graunt packetB

Read-only

Inspect

Read one Graunt catalog packet by id. Returns its title, description, price and whether an account is needed, its seller-declared rights, and its public URL. A free packet that needs no account also returns its files: small text files (CSV, JSON, Markdown, text and similar) in the text, and a short-lived download link for each listed file in metadata.files (at most 100 per fetch; files_not_listed counts the rest). Images, audio and video carry no link and download from the packet's public URL. A video listing also returns metadata.video: its subjects, measured hours, per-hour price with volume tiers, and the seller's declarations.

Name	Required	Description	Default
`id`	Yes	The packet listing id.

Output Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`text`	Yes
`title`	Yes
`metadata`	Yes

TDQS

B3.4/5.0

Behavior4/5

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

Beyond the readOnly/openWorld annotations, the description discloses real behavioral traits: a 100-file cap per fetch with files_not_listed as the overflow counter, short-lived download links, and the fact that images/audio/video carry no link and must be fetched from the public URL. That is genuine operational context an agent could not get from the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence, but the remaining sentences are a dense block of return-value detail that substantially duplicates the existing output schema. The 100-file cap and short-lived link earn their place; much of the rest is redundant.

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?

With an output schema present and annotations covering the safety profile, the description goes further than required by explaining the file-listing and video-listing edge cases. Remaining gaps are minor: no mention of behavior when the id is unknown or invalid, and no clarification of packet versus asset/bundle terminology.

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?

Only one parameter (id), fully documented in the schema at 100% coverage, so the schema carries the semantics. The description adds nothing about id format, source, or whether it is a listing id versus another identifier type, matching the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and resource ('one Graunt catalog packet by id'), so the agent knows exactly what the call does. It does not, however, distinguish a 'packet' from the sibling concepts exposed by get_asset, get_asset_manifest, or get_bundle_manifest, so the agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this instead of search, get_asset, or get_bundle_manifest, and no prerequisites or exclusions are given. Usage is only implied by the 'by id' phrasing, which assumes the agent already has an id from somewhere.

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

get_agent_commerce_manifestRead a listing's commercial termsB

Read-only

Inspect

Read the agent commerce manifest for a listing: price, rights, and how to buy it.

Name	Required	Description	Default
`listing_id`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, lowering the bar. The description adds value by disclosing what the response contains (price, rights, how to buy), but says nothing about failure modes for an unknown listing_id or what 'rights' means structurally.

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?

One short sentence, front-loaded with the verb and resource, with the highest-value detail (the returned fields) placed immediately after. No filler.

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?

For a single-parameter read tool with annotations covering its safety profile and no output schema, the description supplies the essential payload summary. The only meaningful omission is identification of the argument as a listing UUID and any error expectation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single listing_id parameter, and the format is uuid. The description only says 'for a listing', without explaining that the argument is a listing UUID or how to obtain one, so it does not compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Read the agent commerce manifest for a listing") and enumerates the payload (price, rights, how to buy). It is clearly not get_asset_manifest or get_bundle_manifest by virtue of the commerce framing, though it never names those siblings to make the distinction explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives among fetch, get_asset_manifest, get_bundle_manifest, or search_assets. Usage is only inferable from the payload description.

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

get_assetRead a catalog listingA

Read-only

Inspect

Read one listing by id as Graunt's API gives it (GET /v1/listings/{id}). To answer a question from a listing or cite it, use fetch.

Name	Required	Description	Default
`listing_id`	Yes

TDQS

A4/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by naming the underlying GET endpoint and framing the result as what 'Graunt's API gives it,' but it does not describe return shape, auth, rate limits, or error behavior.

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, front-loaded with the primary action and endpoint, followed immediately by the alternative. There is no redundant or filler text.

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?

For a simple single-parameter read tool with annotations covering safety, the description is largely complete: it states the operation, endpoint, and when to prefer a sibling. It could say more about the raw response or error cases, but the core invocation context is present.

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 carry parameter meaning. It does clarify that the tool takes a listing id and locates it in the endpoint path, but it does not explain the UUID format, where to obtain the id, or any constraints beyond what the parameter name already implies.

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 states a specific verb and resource ('Read one listing by id') and identifies the exact API endpoint ('GET /v1/listings/{id}'). It also distinguishes the tool from the sibling 'fetch' by contrasting raw API retrieval with answering or citing questions.

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 gives a clear alternative-condition rule: use 'fetch' to answer a question from a listing or cite it. The implied use case for this tool is raw retrieval by id, but the description does not explicitly state when not to use it versus other sibling search tools.

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

get_asset_manifestRead a listing's packet manifestC

Read-only

Inspect

Read the canonical asset manifest (sha256-stamped).

Name	Required	Description	Default
`listing_id`	Yes

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the manifest is 'canonical' and 'sha256-stamped', which hints at integrity guarantees on the returned content, but says nothing about failure modes, staleness, or what a manifest actually contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short sentence with the key qualifiers up front and no wasted words. However, the terseness crosses into under-specification: the whole budget is spent on adjectives rather than on the usage and parameter context the tool lacks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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

For a one-parameter read with no output schema, the description should at minimum explain what the manifest is and what listing_id identifies. Instead it leaves the return shape, the meaning of 'canonical', and the id semantics unaddressed, so an agent knows the safety profile but not the contract.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter, listing_id (uuid), and schema description coverage is 0%, so the schema supplies only the type and format. The description never mentions listing_id, its provenance, or whether an unknown id errors versus returns empty — the parameter is entirely undocumented at the semantic level.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and resource ('asset manifest'), with the qualifiers 'canonical' and 'sha256-stamped' that narrow the meaning. It implicitly distinguishes from get_bundle_manifest by naming 'asset' rather than 'bundle', but never makes that contrast explicit against the several manifest-related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance at all, and despite siblings like get_asset, get_bundle_manifest, get_agent_commerce_manifest and search_assets, the description names no alternative or exclusion condition. The agent must infer the selection criteria from the tool name alone.

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

get_bundle_manifestRead a bundle's file inventoryB

Read-only

Inspect

Read the per-asset bundle inventory: every delivered file with role, format, size and content hash, plus counts that name the population each one counted.

Name	Required	Description	Default
`listing_id`	Yes

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare the read-only, non-destructive, open-world nature of the tool. The description adds valuable behavioral context by describing the return contents in detail (every delivered file with role, format, size, content hash, and labeled counts), which helps the agent understand what to expect. It does not mention pagination, rate limits, or authentication, so it is not fully comprehensive.

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?

The description is a single efficient sentence that front-loads the core purpose and then details the contents. The phrase 'counts that name the population each one counted' is slightly opaque, but overall there is no wasted material.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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

Given the simple one-parameter read-only tool and the absence of an output schema, the description adequately explains what the inventory contains. However, it omits the meaning of listing_id and any guidance on when to choose this tool over sibling manifest tools, leaving meaningful gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one required parameter (listing_id) with 0% schema description coverage, and the description does not mention it at all. It provides no clarification of whether listing_id refers to a bundle, asset, or listing identifier, leaving the parameter's exact meaning undocumented.

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 uses a specific verb ('Read') and a clear resource ('per-asset bundle inventory') and enumerates the fields returned (role, format, size, content hash, counts). It distinguishes itself from generic asset tools by emphasizing the bundle inventory, but it does not explicitly contrast with sibling tools like get_asset_manifest.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool returns but gives no guidance on when to use it versus alternatives such as get_asset_manifest or get_agent_commerce_manifest. There are no exclusions, prerequisites, or usage conditions stated.

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

match_video_specCount the hours of video that meet a specA

Read-only

Inspect

Find out how many hours of video on Graunt meet a spec, and in which categories. Give the requirements that matter (shortest side, frame rate, clip length, sound, on-screen text, overlays, first and last shots, freezes, slowed footage, releases, clearances, AI generation, uses, delivery); leave the rest out. Returns matching hours per category and per listing: hours that meet every requirement on recorded evidence, and hours that meet every requirement the evidence covers but lack evidence for one or more. Each listing carries its price, price per hour and volume tier, its delivery modes and where each number comes from. Thresholds snap to fixed steps and the answer says which were applied.

Name	Required	Description
`uses`	No	Uses the listing must allow, all of.
`audio`	No	Sound required, or no sound.
`limit`	No	Listings returned; default 50, cap 200. Totals and categories count every listing.
`min_fps`	No	Frames a second, at least: steps 24, 25, 30, 48, 50, 60, 120 (23.976 counts as 24).
`no_loops`	No	Leave out clips with a stretch that repeats earlier footage.
`subjects`	No	What the footage shows, any of.
`no_slowed`	No	Leave out clips with a slowed-footage signal.
`sublicense`	No	ONE_CLIENT_PREAUTHORIZED: the listing must allow buying for one client, named privately at purchase (D-651).
`native_only`	No	Leave out clips with an upscale signal.
`camera_views`	No	The camera view the listing declares, any of.
`no_grayscale`	No	Leave out black-and-white clips.
`orientations`	No	Picture orientations, any of.
`audio_checked`	No	The sound runs the length of the picture, with no dual mono and no silent channel.
`color_checked`	No	Color tags present and consistent, and luma inside the tagged range.
`music_cleared`	No	Music and audio cleared or not applicable.
`delivery_modes`	No	Delivery modes, any of: DOWNLOAD from Graunt, or LINKS from the seller's storage.
`no_ai_generated`	No	Only clips the seller declares no AI model generated.
`person_releases`	No	Clips that show people need signed releases (SIGNED), or releases the seller holds (ON_FILE).
`min_clip_seconds`	No	Clip length, at least (seconds): steps 5, 10, 30, 60, 120, 300, 600, 1200, 3600, 14400.
`people_on_camera`	No	NONE: only clips with nobody on camera.
`min_listing_hours`	No	Only listings with at least this many hours that meet the spec or might.
`min_short_side_px`	No	Shortest side of the picture, at least (pixels): steps 240, 360, 480, 720, 1080, 1440, 2160, 4320.
`property_releases`	No	Property releases where one is needed.
`clip_seconds_under`	No	Clip length, under (seconds), on the same steps.
`text_seconds_under`	No	On-screen text stays on screen under this long (seconds): steps 0.5, 1, 2, 5.
`black_seconds_under`	No	Black under this long in total (seconds): steps 0.5, 1, 2, 5.
`event_venue_cleared`	No	Event or venue cleared or not applicable.
`max_cuts_per_minute`	No	Scene cuts a minute, at most: steps 0, 1, 2, 5, 10.
`text_area_under_pct`	No	On-screen text covers under this share of the frame (percent): steps 1, 2, 5, 10.
`freeze_seconds_under`	No	No frozen stretch this long or longer (seconds): steps 0.5, 1, 2, 5.
`edge_shot_min_seconds`	No	Each clip's first and last shots last at least this long (seconds): steps 1, 2, 3, 5.
`no_identifiable_minors`	No	Leave out clips the seller says show identifiable minors.
`third_party_ip_cleared`	No	Logos and trademarks cleared or not applicable.
`overlay_share_under_pct`	No	Clips with an overlay signal (a logo or watermark) stay under this share of a listing's matching hours (percent): steps 0, 5, 10, 20, 50.
`min_audio_sample_rate_hz`	No	Sound sample rate, at least: steps 44100, 48000, 96000.
`processed_area_under_pct`	No	Black bars and fixed overlays cover under this share of the frame (percent): steps 1, 5, 10.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, so the bar is lower, but the description adds real substance: it explains the two-tier answer (fully evidenced vs. evidence-covered-but-missing), the per-listing price/tier/delivery/provenance detail, and the threshold-snapping behavior with disclosure of applied thresholds. This is meaningful behavioral context beyond the 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?

Three sentences, front-loaded with the purpose, then the parameter-selection rule, then the return shape and threshold-snapping. Dense but no filler, which is appropriate for a 36-param aggregation tool.

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?

With no output schema and 36 parameters, the description carries the burden and largely meets it: it explains both result buckets, what each listing row contains, and threshold snapping. Minor gap is that it doesn't state whether results are paginated or how totals relate to the limit, but overall it is sufficient to call correctly.

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?

Schema coverage is 100%, so the baseline is 3, and the description goes further by grouping the requirement families (shortest side, frame rate, clip length, sound, text, overlays, releases, uses, delivery) into a conceptual map. It guides the agent to pass only relevant params rather than restating schema detail.

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 opens with a specific verb and resource: counting hours of video that meet a spec, plus the categorization dimension. An agent can distinguish this 'count/aggregate hours' operation from search-style siblings like search_assets, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives partial usage guidance by telling the agent to supply only the requirements that matter and 'leave the rest out,' which is useful invocation advice for a 36-param tool. However, it never states when to choose this over search/search_assets for browsing individual clips, so routing between siblings 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.

meta_capabilitiesRead what Graunt offersB

Read-only

Inspect

Read /v1/meta/capabilities: what Graunt offers to an agent, in machine-readable form.

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare it read-only, non-destructive, and closed-world, so the safety profile is fully covered structurally. The description adds only that the payload is 'machine-readable form', which hints at the return shape but says nothing about size, caching, or auth. With annotations carrying the safety burden, this is adequate but thin.

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?

A single short sentence with the endpoint path front-loaded followed by the payload meaning. Nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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

With no output schema and no parameters, the description is the only place an agent can learn what comes back, and 'what Graunt offers to an agent, in machine-readable form' only gestures at it. It is enough to call the tool safely but not enough to know what to expect in 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 tool takes zero parameters, so the baseline is 4 and there are no parameter semantics the description could have clarified or omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific endpoint (GET /v1/meta/capabilities) and says it returns what the service offers an agent, which is a real verb+resource. However, 'what Graunt offers' is vague about content, and it does not distinguish this from siblings like get_agent_commerce_manifest or meta_refinery_support_matrix, which plausibly overlap as capability/manifest reads.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus the manifest or support-matrix tools, and no exclusions. An agent must guess whether to start here for discovery or go straight to a more specific manifest tool.

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

meta_refinery_support_matrixRead supported packet source typesA

Read-only

Inspect

Read /v1/meta/refinery-support-matrix: the source types Graunt accepts and what the Refinery does with each. Every upload gets deterministic extraction; a model drafts only the listing fields a seller leaves empty.

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful domain context — deterministic extraction on every upload and model drafting limited to seller-empty listing fields — but says nothing about the shape, size, or freshness of the returned matrix.

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, front-loaded with the endpoint and the resource it exposes, with zero filler. Nothing in it repeats the schema or annotations.

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?

For a parameterless read-only metadata endpoint with no output schema, the description covers what the resource contains and how the pipeline behaves. Only the format of the returned matrix is left unstated, a minor gap given there is no output schema to lean on.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly avoids inventing any argument surface.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it reads the refinery support matrix, i.e. the source types Graunt accepts and what the Refinery does with each. That is far more concrete than the sibling names suggest, though it never explicitly contrasts itself with meta_capabilities or the manifest tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the meta_* or manifest siblings. The second sentence describes processing behavior rather than conditions for calling the tool.

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

searchSearch the Graunt catalogA

Read-only

Inspect

Search the Graunt catalog of evaluated data packets. Returns matching packets with their id, title, and public URL. Start here to find data, then read one with fetch.

Name	Required	Description
`kind`	No	Only listings of this kind. video: video listings.
`limit`	No	Max results; default 20, cap 50.
`query`	Yes	Search keywords.
`camera_view`	No	Only video listings shot from this camera view.
`ai_generation`	No	Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding. AI processing of real material (cleaning, labeling, transcribing, captioning, structuring) is not AI generation, and a packet that contains video declares NONE.
`video_subject`	No	Only video listings whose footage shows this subject.

Output Schema

Name	Required	Description
`results`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already state readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the catalog scope and result fields (id, title, public URL), but it does not disclose ranking behavior, pagination constraints, authentication needs, or rate limits beyond what the annotations and schema provide.

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 concise sentences with no wasted wording. It front-loads what the tool searches, then states what it returns, then gives the follow-up workflow.

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 full schema, rich annotations, and an output schema, the description is largely complete for invocation: it states scope, return fields, and the follow-up fetch step. The main remaining contextual gap is that it does not clarify how this search differs from the sibling search_assets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema fully documents all six parameters, including four enumerated filters and limit defaults. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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 states a specific verb and resource: search the Graunt catalog of evaluated data packets, and it names the return fields. It also contrasts with fetch as the next step, but it does not distinguish this tool from the sibling search_assets, leaving a possible ambiguity for similarly named search tools.

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 gives clear usage guidance: "Start here to find data, then read one with fetch." That explicitly covers when to use this tool and which alternative to use afterward. It does not explain when to use it instead of search_assets or match_video_spec, so it lacks exclusions or sibling routing.

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

search_assetsSearch catalog listingsA

Read-only

Inspect

Search the public catalog and return listing rows as Graunt's API gives them (GET /v1/listings), paginated. To find data for a person, use search, then fetch.

Name	Required	Description
`q`	No	Search query string.
`kind`	No	Only listings of this kind. video: video listings.
`limit`	No	Max rows; default 20, cap 100.
`camera_view`	No	Only video listings shot from this camera view.
`ai_generation`	No	Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding. AI processing of real material (cleaning, labeling, transcribing, captioning, structuring) is not AI generation, and a packet that contains video declares NONE.
`video_subject`	No	Only video listings whose footage shows this subject.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavior beyond that: results are raw API listing rows rather than normalized objects, and responses are paginated. It omits auth requirements and rate limits, keeping it short of a 5.

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 short sentences with zero filler; the core action and its scope come first and the alternative-tool routing comes second. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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

Six optional, well-documented parameters make this a simple filtered-list tool, and pagination plus the raw-row format are disclosed. With no output schema, though, the description never says what a listing row actually contains, leaving an agent to guess the fields it will get back.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the enum parameters carry detailed, non-obvious explanations (notably the AI-generation seller-declaration caveat), so the baseline is 3. The description adds no parameter-level meaning at all, so it cannot exceed that baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search the public catalog and return listing rows') and names the underlying endpoint GET /v1/listings, which pins down the result shape. It routes person-lookup traffic to the 'search' sibling, so an agent can separate it from at least one alternative, though the boundary with get_asset and match_video_spec is left unstated.

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 one explicit routing sentence ('To find data for a person, use search, then fetch') gives real when-to-use guidance against a sibling. However, there is no guidance on when to prefer this over get_asset, match_video_spec, or search_assets' own paginated traversal, so usage is only partially implied.

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.

1 tool updateOct 31, 2026

Changedfetch1 field changed

addedOutput schema / properties / metadata / properties / samples

Added value: +{
+  "additionalProperties": false,
+  "description": "What anyone may look at before buying, with the sentence shown beside every sample. files: sample files Graunt holds, each with the API path that answers with a link of at most 5 minutes. detail_fields: the listing detail's other sample fields, by name. Absent when the listing has no samples.",
+  "properties": {
+    "detail_fields": {
+      "items": {
+        "enum": [
+          "preview",
+          "content_excerpt",
+          "preview_clips"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "files": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "bytes": {
+            "minimum": 0,
+            "type": "integer"
+          },
+          "content_path": {
+            "type": "string"
+          },
+          "content_type": {
+            "type": "string"
+          },
+          "id": {
+            "format": "uuid",
+            "type": "string"
+          },
+          "kind": {
+            "enum": [
+              "IMAGE",
+              "VIDEO",
+              "AUDIO",
+              "TEXT",
+              "FILE"
+            ],
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "bytes",
+          "content_type",
+          "kind",
+          "content_path"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "notice": {
+      "enum": [
+        "Samples are for evaluating this listing. The license to use the data comes with the purchase."
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "notice",
+    "files",
+    "detail_fields"
+  ],
+  "type": "object"
+}

1 tool updateOct 31, 2026

Changedfetch1 field changed

addedOutput schema / properties / metadata / properties / video / properties / per_hour / properties / categories

Added value: +{
+  "description": "Present when the listing can be bought by category: each category's measured hours and its price bought on its own, at the listing's rate with the tier its own hours reach. An order of several categories is priced on their combined hours; every category is the whole listing at price_cents.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "eligible_duration_seconds": {
+        "minimum": 1,
+        "type": "integer"
+      },
+      "hours": {
+        "minimum": 0,
+        "type": "number"
+      },
+      "price_cents": {
+        "minimum": 0,
+        "type": "integer"
+      },
+      "subject": {
+        "enum": [
+          "PEOPLE_TALKING",
+          "PEOPLE_IN_ACTION",
+          "PEOPLE_HANDLING_OBJECTS",
+          "HOW_TO_AND_TASKS",
+          "SPORTS_AND_FITNESS",
+          "MUSIC_AND_PERFORMANCE",
+          "ANIMALS",
+          "NATURE",
+          "CITIES_AND_BUILDINGS",
+          "DRIVING_AND_TRANSPORTATION",
+          "INDUSTRY_AND_WORK_SITES",
+          "FOOD_AND_COOKING",
+          "PRODUCTS_AND_RETAIL",
+          "ANIMATION",
+          "VIDEO_GAMES"
+        ],
+        "type": "string"
+      },
+      "tier_applied": {
+        "additionalProperties": false,
+        "properties": {
+          "discount_bps": {
+            "description": "Discount in basis points (1000 = 10%).",
+            "maximum": 9000,
+            "minimum": 1,
+            "type": "integer"
+          },
+          "min_hours": {
+            "description": "Hours in the order from which the tier applies.",
+            "minimum": 1,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "min_hours",
+          "discount_bps"
+        ],
+        "type": [
+          "object",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "subject",
+      "eligible_duration_seconds",
+      "hours",
+      "tier_applied",
+      "price_cents"
+    ],
+    "type": "object"
+  },
+  "maxItems": 15,
+  "minItems": 2,
+  "type": "array"
+}

1 tool updateOct 31, 2026

Changedfetch1 field changed

addedOutput schema / properties / metadata / properties / delivery_methods

Added value: +{
+  "description": "How the files reach a buyer, one row per way: the method and the source the files come from (GRAUNT: storage Graunt holds).",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "method": {
+        "enum": [
+          "KEY_ACCESS",
+          "DOWNLOAD"
+        ],
+        "type": "string"
+      },
+      "source": {
+        "enum": [
+          "GRAUNT",
+          "S3"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "method",
+      "source"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

1 tool updateOct 30, 2026
- Addedmatch_video_spec

2 tool updatesOct 30, 2026

Changedsearch1 field changed

changedInput schema / properties / ai_generation / description

Previous value: -"Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding."New value: +"Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding. AI processing of real material (cleaning, labeling, transcribing, captioning, structuring) is not AI generation, and a packet that contains video declares NONE."

Changedsearch_assets1 field changed

changedInput schema / properties / ai_generation / description

Previous value: -"Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding."New value: +"Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding. AI processing of real material (cleaning, labeling, transcribing, captioning, structuring) is not AI generation, and a packet that contains video declares NONE."

1 tool updateOct 30, 2026
- Changedfetch2 fields changed
  - changedOutput schema / properties / metadata / properties / video / properties / seller_declared / properties / attestations / properties / identifiable_minors / description
```
Previous value: -"Whether anyone under 16 can be identified in the content."New value: +"Whether anyone under 18 can be identified in the content."
```
  - addedOutput schema / properties / metadata / properties / video / properties / seller_declared / properties / attestations / properties / identifiable_minors_age
```
Added value: +{
+  "const": 18,
+  "description": "The age identifiable_minors was answered against: 18. A false identifiable_minors counts only with it.",
+  "type": "integer"
+}
```

1 tool updateOct 29, 2026

Changedfetch1 field changed

addedOutput schema / properties / metadata / properties / seller_hosted

Added value: +{
+  "description": "Present only on a listing whose files are delivered from the seller's storage after purchase: file count, bytes, media facts, delivery modes and samples. Never a link to a file.",
+  "properties": {
+    "access_period_days": {
+      "description": "Days the buyer can get the files once they are available; the buyer copies the set within them.",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "delivered_from": {
+      "enum": [
+        "seller_storage"
+      ],
+      "type": "string"
+    },
+    "delivery_modes": {
+      "description": "How the buyer can receive the files. LINKS: a download link per file.",
+      "items": {
+        "enum": [
+          "LINKS"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "file_count": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "media": {
+      "description": "Null when the set holds no audio or video. Frame rates are frames per second; clip lengths are whole seconds.",
+      "properties": {
+        "files_with_audio": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "max_clip_seconds": {
+          "minimum": 0,
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "max_fps": {
+          "minimum": 0,
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "max_height": {
+          "minimum": 0,
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "max_width": {
+          "minimum": 0,
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "media_files": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "min_clip_seconds": {
+          "minimum": 0,
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "min_fps": {
+          "minimum": 0,
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "min_height": {
+          "minimum": 0,
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "min_width": {
+          "minimum": 0,
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "video_codecs": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "video_files": {
+          "minimum": 0,
+          "type": "integer"
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "samples": {
+      "description": "Sample files a buyer can look at before buying.",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "samples_url": {
+      "description": "The public route that lists the samples.",
+      "type": "string"
+    },
+    "spec_check": {
+      "description": "Files Graunt read at random from the full set and compared with the manifest's media facts, and how many matched. Null when none were read.",
+      "properties": {
+        "checked": {
+          "minimum": 0,
+          "type": "integer"
+        },
+        "matched": {
+          "minimum": 0,
+          "type": "integer"
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "total_bytes": {
+      "minimum": 0,
+      "type": "integer"
+    },
+    "total_duration_seconds": {
+      "description": "Seconds of audio and video in the set.",
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "delivered_from",
+    "file_count",
+    "total_bytes",
+    "total_duration_seconds",
+    "media",
+    "delivery_modes",
+    "samples",
+    "samples_url",
+    "access_period_days",
+    "spec_check"
+  ],
+  "type": "object"
+}

1 tool updateOct 29, 2026

Changedfetch1 field changed

changed

Output schema / properties / metadata / properties / video / properties / per_hour / properties / price_cents / description

Previous value: -"The listing price, subtotal_cents minus discount_cents: what checkout charges before the processing fee."New value: +"The listing price, subtotal_cents minus discount_cents: what checkout charges before any sales tax."

3 tool updatesOct 29, 2026

Changedfetch2 fields changed

addedOutput schema / properties / metadata / properties / ai_generation

Added value: +{
+  "description": "The seller's AI-generation declaration: extent NONE (not AI-generated), PARTIAL (with share_percent and description) or FULL. A seller declaration, not a Graunt finding; absent when the seller has not declared.",
+  "properties": {
+    "description": {
+      "type": "string"
+    },
+    "extent": {
+      "enum": [
+        "NONE",
+        "PARTIAL",
+        "FULL"
+      ],
+      "type": "string"
+    },
+    "share_percent": {
+      "maximum": 99,
+      "minimum": 1,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "extent"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / metadata / properties / video

Added value: +{
+  "additionalProperties": false,
+  "description": "Present only on a video listing: subjects, the hours Graunt measured, the per-hour price with its volume tiers, and the seller's declarations (people on camera, releases, sublicense), kept apart.",
+  "properties": {
+    "barred_uses": {
+      "description": "Uses no license permits for this footage, whatever else the listing allows. Present when the footage shows people.",
+      "items": {
+        "enum": [
+          "person_likeness_use",
+          "voice_clone",
+          "deepfake_use",
+          "biometric_identification"
+        ],
+        "type": "string"
+      },
+      "maxItems": 4,
+      "type": "array"
+    },
+    "camera_views": {
+      "description": "How the footage was shot, from the closed camera-view list; empty when none was given. Filter with camera_view on GET /v1/listings.",
+      "items": {
+        "enum": [
+          "FIRST_PERSON",
+          "AERIAL_OR_DRONE",
+          "VEHICLE_OR_DASHCAM",
+          "FIXED_CAMERA",
+          "OTHER"
+        ],
+        "type": "string"
+      },
+      "maxItems": 5,
+      "type": "array"
+    },
+    "measured": {
+      "additionalProperties": false,
+      "description": "What Graunt measured from the files; null when it measured none.",
+      "properties": {
+        "eligible_duration_seconds": {
+          "description": "Seconds of video a buyer of the whole listing receives and pays for.",
+          "minimum": 0,
+          "type": "integer"
+        },
+        "hours": {
+          "description": "The same length in hours, to one decimal place.",
+          "minimum": 0,
+          "type": "number"
+        }
+      },
+      "required": [
+        "eligible_duration_seconds",
+        "hours"
+      ],
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "media_kind": {
+      "enum": [
+        "VIDEO"
+      ],
+      "type": "string"
+    },
+    "per_hour": {
+      "additionalProperties": false,
+      "description": "The per-hour price, or null when the listing has a flat price. The seller sets the rate. The volume tier is applied automatically from the hours in the order; there is no code and nothing to request. All amounts are integer cents.",
+      "properties": {
+        "currency": {
+          "const": "usd"
+        },
+        "discount_cents": {
+          "description": "floor(subtotal_cents × the applied tier's discount_bps / 10000).",
+          "minimum": 0,
+          "type": "integer"
+        },
+        "price_cents": {
+          "description": "The listing price, subtotal_cents minus discount_cents: what checkout charges before the processing fee.",
+          "minimum": 0,
+          "type": "integer"
+        },
+        "price_per_hour_cents": {
+          "description": "The seller's rate.",
+          "minimum": 1,
+          "type": "integer"
+        },
+        "rate_class": {
+          "enum": [
+            "BASIC",
+            "STANDARD",
+            "PREMIUM",
+            "NATIVE_1080P",
+            "NATIVE_4K",
+            "ARCHIVAL"
+          ],
+          "type": "string"
+        },
+        "subtotal_cents": {
+          "description": "floor(eligible_duration_seconds × price_per_hour_cents / 3600).",
+          "minimum": 0,
+          "type": "integer"
+        },
+        "tier_applied": {
+          "additionalProperties": false,
+          "description": "The tier this listing's hours reach; null when they reach none.",
+          "properties": {
+            "discount_bps": {
+              "description": "Discount in basis points (1000 = 10%).",
+              "maximum": 9000,
+              "minimum": 1,
+              "type": "integer"
+            },
+            "min_hours": {
+              "description": "Hours in the order from which the tier applies.",
+              "minimum": 1,
+              "type": "integer"
+            }
+          },
+          "required": [
+            "min_hours",
+            "discount_bps"
+          ],
+          "type": [
+            "object",
+            "null"
+          ]
+        },
+        "volume_tiers": {
+          "description": "This listing's volume schedule, lowest tier first: a term of the listing, recorded in every purchase. The seller funds each discount.",
+          "items": {
+            "additionalProperties": false,
+            "properties": {
+              "discount_bps": {
+                "description": "Discount in basis points (1000 = 10%).",
+                "maximum": 9000,
+                "minimum": 1,
+                "type": "integer"
+              },
+              "min_hours": {
+                "description": "Hours in the order from which the tier applies.",
+                "minimum": 1,
+                "type": "integer"
+              }
+            },
+            "required": [
+              "min_hours",
+              "discount_bps"
+            ],
+            "type": "object"
+          },
+          "maxItems": 5,
+          "type": "array"
+        }
+      },
+      "required": [
+        "rate_class",
+        "price_per_hour_cents",
+        "currency",
+        "volume_tiers",
+        "tier_applied",
+        "subtotal_cents",
+        "discount_cents",
+        "price_cents"
+      ],
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "seller_declared": {
+      "additionalProperties": false,
+      "description": "The seller's declarations, kept apart from what Graunt measured. Never Graunt's findings.",
+      "properties": {
+        "attestations": {
+          "additionalProperties": false,
+          "description": "What the seller declares about the material, recorded as the seller declared it. Graunt does not compute these.",
+          "properties": {
+            "event_or_venue_rights_status": {
+              "description": "Events and venues.",
+              "enum": [
+                "NOT_APPLICABLE",
+                "SELLER_ATTESTED",
+                "EVIDENCE_ON_FILE",
+                "INCOMPLETE"
+              ],
+              "type": "string"
+            },
+            "guardian_releases_on_file": {
+              "description": "Whether the releases on file include a parent's or guardian's release for each minor shown.",
+              "type": "boolean"
+            },
+            "identifiable_minors": {
+              "description": "Whether anyone under 16 can be identified in the content.",
+              "type": "boolean"
+            },
+            "music_audio_rights_status": {
+              "description": "Music and audio.",
+              "enum": [
+                "NOT_APPLICABLE",
+                "SELLER_ATTESTED",
+                "EVIDENCE_ON_FILE",
+                "INCOMPLETE"
+              ],
+              "type": "string"
+            },
+            "native_resolution": {
+              "description": "The lowest native resolution in the listing.",
+              "enum": [
+                "SD",
+                "HD_720P",
+                "FHD_1080P",
+                "QHD_1440P",
+                "UHD_4K",
+                "UHD_8K"
+              ],
+              "type": "string"
+            },
+            "people_on_camera": {
+              "description": "How people appear: SUBJECT (the footage is about them) or INCIDENTAL (in passing, in a crowd).",
+              "enum": [
+                "INCIDENTAL",
+                "SUBJECT"
+              ],
+              "type": "string"
+            },
+            "person_release_status": {
+              "description": "Releases from the people shown. INCOMPLETE is allowed only when people appear incidentally.",
+              "enum": [
+                "NOT_APPLICABLE",
+                "SELLER_ATTESTED",
+                "EVIDENCE_ON_FILE",
+                "INCOMPLETE"
+              ],
+              "type": "string"
+            },
+            "property_release_status": {
+              "description": "Private property shown.",
+              "enum": [
+                "NOT_APPLICABLE",
+                "SELLER_ATTESTED",
+                "EVIDENCE_ON_FILE",
+                "INCOMPLETE"
+              ],
+              "type": "string"
+            },
+            "third_party_ip_status": {
+              "description": "Third-party marks and designs.",
+              "enum": [
+                "NOT_APPLICABLE",
+                "SELLER_ATTESTED",
+                "EVIDENCE_ON_FILE",
+                "INCOMPLETE"
+              ],
+              "type": "string"
+            }
+          },
+          "type": [
+            "object",
+            "null"
+          ]
+        },
+        "depicts_person": {
+          "description": "Whether the seller says people appear in the footage.",
+          "type": "boolean"
+        },
+        "sublicense": {
+          "description": "ONE_CLIENT_PREAUTHORIZED: the buyer may pass the data through to one client, named privately at purchase in sublicense_client, for that client's use within the license; the buyer makes no use of it for itself. The license itself stays non-transferable.",
+          "enum": [
+            "NONE",
+            "ONE_CLIENT_PREAUTHORIZED"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "depicts_person",
+        "sublicense",
+        "attestations"
+      ],
+      "type": "object"
+    },
+    "subjects": {
+      "description": "What the footage shows, from the closed video-subject list. Filter with video_subject on GET /v1/listings.",
+      "items": {
+        "enum": [
+          "PEOPLE_TALKING",
+          "PEOPLE_IN_ACTION",
+          "PEOPLE_HANDLING_OBJECTS",
+          "HOW_TO_AND_TASKS",
+          "SPORTS_AND_FITNESS",
+          "MUSIC_AND_PERFORMANCE",
+          "ANIMALS",
+          "NATURE",
+          "CITIES_AND_BUILDINGS",
+          "DRIVING_AND_TRANSPORTATION",
+          "INDUSTRY_AND_WORK_SITES",
+          "FOOD_AND_COOKING",
+          "PRODUCTS_AND_RETAIL",
+          "ANIMATION",
+          "VIDEO_GAMES"
+        ],
+        "type": "string"
+      },
+      "maxItems": 15,
+      "type": "array"
+    }
+  },
+  "required": [
+    "media_kind",
+    "subjects",
+    "camera_views",
+    "measured",
+    "per_hour",
+    "seller_declared",
+    "barred_uses"
+  ],
+  "type": "object"
+}

Changedsearch4 fields changed

addedInput schema / properties / ai_generation

Added value: +{
+  "description": "Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding.",
+  "enum": [
+    "NONE",
+    "PARTIAL",
+    "FULL"
+  ],
+  "type": "string"
+}

addedInput schema / properties / camera_view

Added value: +{
+  "description": "Only video listings shot from this camera view.",
+  "enum": [
+    "FIRST_PERSON",
+    "AERIAL_OR_DRONE",
+    "VEHICLE_OR_DASHCAM",
+    "FIXED_CAMERA",
+    "OTHER"
+  ],
+  "type": "string"
+}

addedInput schema / properties / kind

Added value: +{
+  "description": "Only listings of this kind. video: video listings.",
+  "enum": [
+    "video"
+  ],
+  "type": "string"
+}

addedInput schema / properties / video_subject

Added value: +{
+  "description": "Only video listings whose footage shows this subject.",
+  "enum": [
+    "PEOPLE_TALKING",
+    "PEOPLE_IN_ACTION",
+    "PEOPLE_HANDLING_OBJECTS",
+    "HOW_TO_AND_TASKS",
+    "SPORTS_AND_FITNESS",
+    "MUSIC_AND_PERFORMANCE",
+    "ANIMALS",
+    "NATURE",
+    "CITIES_AND_BUILDINGS",
+    "DRIVING_AND_TRANSPORTATION",
+    "INDUSTRY_AND_WORK_SITES",
+    "FOOD_AND_COOKING",
+    "PRODUCTS_AND_RETAIL",
+    "ANIMATION",
+    "VIDEO_GAMES"
+  ],
+  "type": "string"
+}

Changedsearch_assets4 fields changed

addedInput schema / properties / ai_generation

Added value: +{
+  "description": "Keep only packets whose seller declares this AI-generation extent: NONE (not AI-generated), PARTIAL or FULL. A seller declaration, not a Graunt finding.",
+  "enum": [
+    "NONE",
+    "PARTIAL",
+    "FULL"
+  ],
+  "type": "string"
+}

addedInput schema / properties / camera_view

Added value: +{
+  "description": "Only video listings shot from this camera view.",
+  "enum": [
+    "FIRST_PERSON",
+    "AERIAL_OR_DRONE",
+    "VEHICLE_OR_DASHCAM",
+    "FIXED_CAMERA",
+    "OTHER"
+  ],
+  "type": "string"
+}

addedInput schema / properties / kind

Added value: +{
+  "description": "Only listings of this kind. video: video listings.",
+  "enum": [
+    "video"
+  ],
+  "type": "string"
+}

addedInput schema / properties / video_subject

Added value: +{
+  "description": "Only video listings whose footage shows this subject.",
+  "enum": [
+    "PEOPLE_TALKING",
+    "PEOPLE_IN_ACTION",
+    "PEOPLE_HANDLING_OBJECTS",
+    "HOW_TO_AND_TASKS",
+    "SPORTS_AND_FITNESS",
+    "MUSIC_AND_PERFORMANCE",
+    "ANIMALS",
+    "NATURE",
+    "CITIES_AND_BUILDINGS",
+    "DRIVING_AND_TRANSPORTATION",
+    "INDUSTRY_AND_WORK_SITES",
+    "FOOD_AND_COOKING",
+    "PRODUCTS_AND_RETAIL",
+    "ANIMATION",
+    "VIDEO_GAMES"
+  ],
+  "type": "string"
+}

1 tool updateOct 21, 2026

Changedfetch3 fields changed

addedOutput schema / properties / metadata / properties / files

Added value: +{
+  "description": "Present when the packet downloads without an account: one entry per listed file (at most 100; files_not_listed counts the rest). inline says how much of the file the text shows (up to 200 KB of text in all); download_url works until download_expires_at. Images, audio and video carry no link here and download from the packet's public URL.",
+  "items": {
+    "properties": {
+      "download_expires_at": {
+        "type": "string"
+      },
+      "download_url": {
+        "type": "string"
+      },
+      "format": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "inline": {
+        "enum": [
+          "FULL",
+          "PARTIAL",
+          "NONE"
+        ],
+        "type": "string"
+      },
+      "inline_bytes": {
+        "minimum": 0,
+        "type": "integer"
+      },
+      "name": {
+        "type": "string"
+      },
+      "size_bytes": {
+        "minimum": 0,
+        "type": [
+          "integer",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "name",
+      "format",
+      "size_bytes",
+      "inline",
+      "inline_bytes"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / metadata / properties / files_not_listed

Added value: +{
+  "description": "Present when the packet has more files than one fetch lists (100): how many more there are. They download from the packet's public URL.",
+  "minimum": 1,
+  "type": "integer"
+}

addedOutput schema / properties / metadata / properties / files_note

Added value: +{
+  "description": "Why the files could not be returned right now (for example a rate limit), in plain words.",
+  "type": "string"
+}

1 tool updateOct 1, 2026

Changedfetch3 fields changed

addedOutput schema / properties / metadata / properties

Added value: +{
+  "acquisition_mode": {
+    "type": "string"
+  },
+  "asset_class": {
+    "type": "string"
+  },
+  "category": {
+    "type": "string"
+  },
+  "currency": {
+    "enum": [
+      "usd"
+    ],
+    "type": "string"
+  },
+  "free_access_grant_url": {
+    "description": "Present only when the packet can be taken with no account: POST it for a short-lived grant, then GET the download_url in its response.",
+    "type": "string"
+  },
+  "payment_required": {
+    "type": "boolean"
+  },
+  "price_cents": {
+    "minimum": 0,
+    "type": "integer"
+  },
+  "publisher": {
+    "type": "string"
+  },
+  "registration_required": {
+    "type": "boolean"
+  },
+  "rights_passport_summary": {
+    "properties": {
+      "citation_required": {
+        "type": "boolean"
+      },
+      "license_family": {
+        "type": "string"
+      },
+      "no_redistribute": {
+        "type": "boolean"
+      },
+      "no_train": {
+        "type": "boolean"
+      },
+      "personal_data_sensitive": {
+        "type": "boolean"
+      },
+      "redistribution_allowed": {
+        "type": "boolean"
+      },
+      "training_allowed": {
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "license_family",
+      "training_allowed",
+      "redistribution_allowed",
+      "citation_required",
+      "no_train",
+      "no_redistribute",
+      "personal_data_sensitive"
+    ],
+    "type": "object"
+  }
+}

addedOutput schema / properties / metadata / required

Added value: +[
+  "price_cents",
+  "currency",
+  "acquisition_mode",
+  "registration_required",
+  "payment_required",
+  "rights_passport_summary"
+]

changedOutput schema / required

Previous value: -[
-  "id",
-  "title",
-  "text",
-  "url"
-]New value: +[
+  "id",
+  "title",
+  "text",
+  "url",
+  "metadata"
+]

9 tool updatesSep 6, 2026
- First observedfetch
- First observedget_agent_commerce_manifest
- First observedget_asset
- First observedget_asset_manifest
- First observedget_bundle_manifest
- First observedmeta_capabilities
- First observedmeta_refinery_support_matrix
- First observedsearch
- First observedsearch_assets

Related MCP Connectors

Agent Data Marketplace A
io.github.wabarakat
Marketplace for AI agents: buy finance, satellite and agro data, hire agent services, apply to sell.
Agent Orchestration AI & Machine Learning E-commerce & Retail
121
https://dlfyresearch.com/mcp
sella A
io.github.sella-network
Marketplace where AI agents buy datasets and API access, pay per call in USDC over x402.
Cryptocurrency Payments & Billing AI & Machine Learning
522
https://sellag.vercel.app/api/mcp
Almured A
com.almured
Marketplace where AI agents ask AI agents that have live or proprietary data.
Autonomous Agents Agent Orchestration
1322
https://api.almured.com/mcp
spectrum-data-digital
io.github.spectrumdatadigital
Data marketplace for AI agents: quality-scored datasets, compliance checks, x402 USDC payments.
AI & Machine Learning Cryptocurrency Payments & Billing
1
https://ugduocbgwoqoiyyjdnzr.supabase.co/functions/v1

Related MCP Servers

agent-marketplace-mcp
Search Data Platforms
wabarakat
A
license
A
quality
D
maintenance
Enables AI agents to search data sellers and datasets across categories, inspect sellers and data points, and request purchases, samples, or unlisted data without an API key.
Updated 6 days ago (2026-10-25 12:39 UTC)
7
MIT
com.macaroonnetwork/mcp-server
Blockchain Payments & Billing Search
kevmoz
A
license
A
quality
D
maintenance
Enables AI agents to discover, evaluate, and purchase live data from the Macaroon Network marketplace using semantic search, metadata checks, and Bitcoin Lightning payments.
Updated a month ago (2026-09-16 13:23 UTC)
4
MIT
glongus-mcp
E-commerce & Retail Search
glongusmain
A
license
A
quality
B
maintenance
Enables AI agents to search, inspect, and purchase physical goods on an escrow-secured marketplace, including listing search, agent reputation checks, and offer creation.
Updated 13 days ago (2026-10-18 12:45 UTC)
44
197 npm
MIT
databazaar-mcp
E-commerce & Retail Payments & Billing Research & Data
shagarwal
A
license
A
quality
D
maintenance
Search datasets and preview samples without an API key. Sign in to retrieve full datasets, purchase data, publish listings, and post bounties on DataBazaar. Supports local stdio and remote MCP connections.
Updated 21 days ago (2026-10-10 20:03 UTC)
27
38 npm
MIT

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.

Resources

Need Help?