Graunt

Count the hours of video that meet a spec

match_video_spec

Read-only

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.

Input Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

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.

All Graunt 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.

Resources

Need Help?