Search for videos and streaming media by query across PeerTube instances, with options to set result counts and cap total results for a merged, unified output.
Search videos and streaming media across PeerTube instances.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| num_results | No | Number of results per provider. | |
| max_total_results | No | Cap the final merged result set returned to the agent. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It states cross-instance searching but does not disclose whether the operation is read-only, how results are merged or capped, whether any provider-side limits apply, or what failure modes exist. The schema hints at per-provider and merged-result behavior, but the description itself does not surface these traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear, front-loaded sentence with no filler or redundancy. It is efficient, though slightly under-specified given the tool's federated-search complexity and lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, yet the description does not explain the return shape, aggregation behavior, or relationship to sibling provider tools such as list_providers or provider_health. For a multi-instance federated search, an agent needs more context about scope, providers, and result merging to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already documents query, num_results per provider, and max_total_results cap. The description adds no additional parameter semantics on top of what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Search videos and streaming media across PeerTube instances.' The explicit PeerTube scope clearly differentiates this from generic siblings like search_web and search_google, making the intended domain unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over its many siblings, nor any mention of exclusions or alternatives. The agent is left to infer that this is for video/media queries, with no stated boundary between this and other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.