Search your saved videos by what was said. YouTube, Reels, and TikTok transcripts. Read-only.
Scored across 2 tools
The two tools target entirely different resources: one returns static product metadata, the other looks up a specific video's public transcript. There is no plausible way to confuse them, and each description explicitly states its scope and limits.
Both tools follow the same get_<noun> snake_case pattern (get_product_info, get_public_transcript), and the nouns clearly describe the returned resource. No mixing of conventions or verb styles.
Two tools is thin for a server whose domain includes a public transcript index across four platforms. It is defensible as a minimal read-only surface, but a single lookup tool plus a static info tool leaves little room for the stated scope.
The surface covers product facts and single-URL transcript lookup, but there is no way to search or browse the transcript index, list processed videos, or check coverage for multiple URLs. Core lookup works, but agents hit dead ends on discovery-style tasks.
Return a factual overview of SavedThat: what the service does, which video platforms it supports, the current plan limits and prices, and links to its apps and documentation. Use it to answer questions about the product itself. It reads no user data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| apps | No | |
| pricing | Yes | |
| product | Yes | |
| docs_url | No | |
| platforms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is largely covered structurally. The description adds a useful behavioral nuance on top: 'It reads no user data,' which tells the agent no user context, auth scope, or privacy considerations are involved — beyond what the readOnly hint alone conveys.
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?
Two sentences, front-loaded with the action and enumerated contents, then immediately followed by when-to-use and the no-user-data caveat. Every clause earns its place with no filler.
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?
An output schema exists, so return structure need not be explained; the description instead summarizes the semantic content of the response and confirms it touches no user data. For a zero-parameter, read-only informational tool this covers everything an agent needs to invoke it correctly.
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?
The tool takes zero parameters, so the baseline is 4 per the rubric. The description correctly implies a parameterless, context-free call and adds no misleading parameter claims.
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?
States a specific verb and resource ('Return a factual overview of SavedThat') and enumerates exactly what the payload covers: service function, supported platforms, plan limits and prices, and links to apps and docs. This is clearly distinguishable from the sibling get_public_transcript, which deals with transcripts of user content rather than static product facts.
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?
Provides clear usage context: 'Use it to answer questions about the product itself.' That tells the agent when the tool is appropriate. It stops short of naming get_public_transcript as the alternative or stating an explicit when-not condition (e.g. for user-specific data), so it is strong but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one video URL (YouTube, YouTube Shorts, Instagram Reels or TikTok) in SavedThat's public transcript index and return the opening excerpt of that transcript plus the link to its public page. Returns found=false when SavedThat has not processed the video. Only an excerpt is public; the full transcript is available to signed-in users in the app.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Video URL on YouTube, Instagram Reels or TikTok. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| found | Yes | |
| title | No | |
| channel | No | |
| excerpt | No | |
| platform | No | |
| truncated | No | |
| transcript_page_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: only an excerpt is public, the full transcript is gated behind sign-in, and a not-found result is expressed as found=false rather than an error.
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?
Three tightly written sentences with the primary operation front-loaded, followed by the failure case and the public/excerpt limitation. No filler and nothing repeated from the schema or 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?
For a one-parameter lookup with a rich annotation set and an output schema, the description is complete: it covers what is fetched, what is returned, what the not-found sentinel is, and why only an excerpt is available. An agent can call this correctly without further information.
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?
There is a single required parameter at 100% schema description coverage, so the baseline is 3. The description does add platform scope (mentioning YouTube Shorts, which the schema's url description omits), but adds no format or normalization guidance for the URL.
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?
States a specific verb (look up) and resource (one video URL in SavedThat's public transcript index) and names the exact return (opening excerpt plus public page link). It also enumerates the supported platforms, so the agent knows the scope of inputs immediately.
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?
The description clarifies the intended use case (single-URL lookup against the public index) and signals the failure mode (found=false when the video has not been processed), plus the scope boundary that full transcripts require sign-in. It does not explicitly contrast with the only sibling, get_product_info, but that tool is unrelated enough that no routing ambiguity exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_product_info1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "apps": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "docs_url": {
+ "type": "string"
+ },
+ "platforms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pricing": {
+ "type": "string"
+ },
+ "product": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "product",
+ "url",
+ "platforms",
+ "pricing"
+ ],
+ "type": "object"
+}get_public_transcript2 fields changedInput schema / properties / url / descriptionPrevious value: -"The video URL."New value: +"Video URL on YouTube, Instagram Reels or TikTok."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "channel": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "excerpt": {
+ "type": "string"
+ },
+ "found": {
+ "type": "boolean"
+ },
+ "platform": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "transcript_page_url": {
+ "type": "string"
+ },
+ "truncated": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "found"
+ ],
+ "type": "object"
+}get_product_infoget_public_transcriptSearch everything you save: YouTube, articles, podcasts, PDFs, Notion, Obsidian. API key or OAuth.
Get transcripts from YouTube, TikTok, X, Instagram and more - even when captions are off.
Extract YouTube transcripts, search what was said, and read on-screen frames with cited timestamps.
Summarize and transcribe videos, audio, documents and web pages; subtitles; search your library.
Add one secure layer between your agents and this server.
