GenFlick

research source capabilities

native.research_source_capabilities

DestructiveIdempotent

Read the executable operations and available import kinds for a public source link or platform. Free; no supplier request. Use this when coverage is uncertain, then use the existing quote/start/read tools. A source lookup is not a video inspection.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "work_id": "<work_id>",
      "arguments": "<arguments>",
      "expected_catalog_version": "<expected_catalog_version>",
      "read_skills": "<read_skills>",
      "request_key": "<request_key>"
    },
    "name": "native.research_source_capabilities"
  }
}

Input Schema

Name	Required	Description
`work_id`	Yes
`arguments`	Yes
`read_skills`	Yes	Exact required native skills and their dependencies, copied from the accepted session bootstrap's skills array. Include only entries in that array. General mcp.* guides and native.{studio}.instructions are guidance, not native skill proofs.
`request_key`	Yes
`publication_proposal_id`	No	For native Social scheduling, the exact server-approved publication proposal. This identifier cannot confer approval by itself.
`expected_catalog_version`	Yes	For a new session, read a studios/{studio}/native/{pack} child toolset and copy invocation.catalog_version from a native tool descriptor. Do not use the top-level library version. For calls in an existing session, use that session proposal's catalog_version.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A3.5/5.0

Behavior2/5

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

The description adds real behavioral value by stating the call is free and requires no supplier request, which materially affects when an agent should call it. However, it frames the operation purely as a read ("Read the executable operations") while the annotations declare readOnlyHint=false and destructiveHint=true, and it says nothing to reconcile that difference or explain what the destructive/open-world envelope means here. That conflict is a meaningful safety signal gap for an agent deciding whether to invoke it.

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?

Four short sentences, front-loaded with the operation and its cost profile, with no filler. The only soft spot is the vague "then use the existing quote/start/read tools", which could be replaced with concrete sibling names at the same length.

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?

The output schema exists, so return-shape explanation is correctly omitted, and the schema documents read_skills and expected_catalog_version in detail. But for a tool with 5 required parameters involving a session protocol, the description leaves work_id and request_key completely unexplained and never says whether platform and publicUrl are alternatives or complements.

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 coverage is only 50%, so the description should compensate, but it only hints that a source is identified by "a public source link or platform" (the arguments.publicUrl and arguments.platform pair). It says nothing about work_id, request_key, read_skills, or expected_catalog_version, and nothing about how the two source-identification paths differ or when to prefer one.

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?

Names a specific verb ("Read") and a specific resource ("executable operations and available import kinds for a public source link or platform"), and explicitly distinguishes itself from inspection: "A source lookup is not a video inspection." An agent can tell this apart from native.inspect_source or native.extract_source without opening the schema.

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?

"Use this when coverage is uncertain, then use the existing quote/start/read tools" gives an explicit trigger condition plus a follow-up path, and the closing sentence rules out the video-inspection route. It stops short of naming the exact alternative tools (quote_social_research / quote_social_research_next) that the vague "quote/start/read tools" phrase gestures at.

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

All GenFlick 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?