io.github.lsmman/fetchive

Official

by lsmman

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but archive_batch and ingest_links both parse links from text, which could cause misselection. summarise_pending and add_summary are also related, though descriptions clarify their different roles.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (archive_batch, get_batch_status, ingest_links, etc.). The naming is predictable and easy to reason about.
Tool Count5/5
11 tools is well within the ideal range for a focused archiving workflow. Each tool supports a distinct step in the pipeline: extraction, transcription, summarization, search, and duplicate management.
Completeness4/5
The core workflow is well-covered: link extraction, YouTube transcript retrieval, summary generation, archiving, search, and duplicate detection. Minor gaps exist, such as no direct update or fetch-by-ID for individual archived items, but the server's purpose is well-served.
Average 4.1/5 across 11 of 11 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive; the description adds behavioral constraints (quotes are capped, transcripts never verbatim) and mentions context about workspace tag vocabulary. No contradiction with annotations.
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 front-loaded sentence that conveys purpose and key caveats without fluff. Slightly vague 'properties' keeps it from a perfect score.
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 output schema exists and annotations cover safety, the description covers essential non-obvious behavior (tag vocabulary, quote cap, no verbatim transcripts). It lacks explicit alternatives to sibling tools and could be clearer about expected inputs, but overall it's adequate.
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 0% and the description does not systematically explain the five parameters; only 'quotes' and indirectly 'tags' are addressed through the caveats. The self-explanatory parameter names help, but the description doesn't fully compensate for the lack of schema documentation.
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 ('Shape') and resource ('one link into a page payload'), and clarifies it includes properties, tag vocabulary, and classification instructions. This distinguishes it from ingestion/extraction siblings, though it doesn't explicitly name alternatives.
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 description implies this is for preparing a single link for Notion, particularly with workspace-specific tags and quote/transcript constraints. It provides context but no explicit 'use when' guidance or exclusions against siblings like ingest_links or summarise_pending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds valuable behavioral context by explaining the output structure when state is 'completed', specifically mentioning `ready_to_save` and `items`. This goes beyond the annotations and helps the agent anticipate the response.
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 two sentences long, front-loaded with the core purpose, and every word earns its place. It avoids fluff and clearly presents the conditional detail about the completed state without repetition.
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 presence of an output schema (not shown but indicated), the description sufficiently explains the key aspects of the tool's behavior. It covers the completed state's output meaning and implies progress for other states. It does not detail any error handling or pagination, but for a simple status check, this level is adequate.
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?
The input schema has only batch_id with no description, and description coverage is 0%. The description does not mention batch_id at all, so it fails to compensate for the lack of schema documentation. Although the parameter is self-explanatory, the description adds no semantic value beyond the schema.
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 starts with 'Progress for a running or finished batch,' which clearly indicates the tool reports batch status. It distinguishes from sibling tools by focusing on status rather than actions like archiving or ingesting, though it lacks an explicit verb like 'get' or 'retrieve.' The added detail about completed state further clarifies its purpose.
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 description implies when to use the tool: to check progress of a batch, whether running or finished. However, it provides no explicit guidance on when not to use it or alternatives, likely because no sibling tool serves the same status-checking role. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description reveals that summaries are checked for copying the source and that the item transitions to ready_to_save. This adds meaningful behavioral context. Annotations only indicate not read-only, not open-world, etc., and the description does not contradict them.
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 two sentences, front-loaded with the core action, and includes workflow context. Every word adds value, making it concise and well-structured.
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 description explains the overall workflow and outcome (item appears in ready_to_save) and the anti-copy check. However, with 5 parameters and zero schema descriptions, it leaves out parameter-level detail and error conditions. The output schema exists but the description does not attempt to cover all dimensions.
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?
The schema has no descriptions (0% coverage), so the description must compensate. It explicitly names 'summary' and 'tags' but does not explain 'url', 'batch_id', or 'confidence'. The phrase 'one extracted item' vaguely implies identity via url/batch_id but lacks clarity. Confidence is completely unaddressed.
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 clearly states the tool records a summary and tags for one extracted item, using specific verbs and resources. It also distinguishes from summarise_pending by specifying it is used after receiving a prompt to write the summary.
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?
The description provides explicit when-to-use context ('Use this after summarise_pending hands you a prompt to write yourself') and implies a prerequisite. However, it does not explicitly name alternative tools or when-not-to-use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds context about return format: 'Returns matching excerpts with the workspace page link where one was recorded.' This goes beyond the annotations and clarifies output 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?
The description is three short sentences, with the main purpose front-loaded in the first sentence. Every sentence adds value: purpose, use cases, and return value. No redundancy or fluff.
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 a simple two-parameter tool, an output schema, and strong annotations, the description covers purpose, usage, and return format. It lacks mention of pagination or limit behavior, but the output schema likely covers those details. The description is sufficient for selecting and invoking the tool.
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%, so the description must compensate. It mentions 'query' implicitly via full-text search but does not explicitly define the query parameter or explain the 'limit' parameter. The description adds little meaning beyond the parameter names themselves.
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 clearly states a specific action: 'Full-text search across everything archived — transcripts and article bodies, not just titles.' This distinguishes it from other archive tools by emphasizing full-text content and provides a precise resource and scope.
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 explicit use cases: 'Use this to answer questions about what the user has already saved, or to find the source of a half-remembered idea.' It does not name alternative tools or exclusions, but the context is clear and effectively guides when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint, but the description adds valuable context by clarifying that the operation only affects the archive index and 'does not touch the workspace itself.' This explains the scope of destruction beyond what annotations convey.
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 sentences, each with a distinct role: the action, the use case, and a clarifying caveat. No redundancy, and it is front-loaded with the core purpose.
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 destructive tool with annotations and an output schema, the description covers the what, when, and scope well. It could mention idempotency or irreversible nature, but the annotations already imply these, so the description is sufficiently complete.
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?
The schema only defines 'url' as a string with no description, and schema coverage is 0%. The description says 'Remove a URL from the archive index,' which directly maps the parameter to the URL being removed. This adds basic semantic grounding but does not explain format, validation, or exact matching requirements.
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 clearly states the action (remove a URL from the archive index) and the outcome (counts as new again). It distinguishes this from siblings like record_archived by focusing on removal, and adds a specific resource (archive index) that is not confused with the workspace.
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?
The description provides an explicit trigger condition: 'Use when the page it points to was deleted from the workspace.' However, it does not name alternative tools or state when not to use it, so it falls short of full guidance but is still contextually clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by explaining that this tool is the mechanism that informs duplicate detection, which is not visible in the readOnlyHint or other annotations. It does not contradict annotations, and while it doesn't detail every side effect, it provides a key behavioral consequence of using the tool.
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 two sentences, front-loaded with the core instruction and followed by a concise justification of its importance. Every word contributes value, with no redundancy.
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 description provides strong guidance for the primary use case and differentiates from siblings, but it omits explanations for the optional parameters and does not clarify what 'where' refers to. Given the output schema exists, return values are covered, but the parameter vocabulary and edge cases are under-specified for a 4-parameter tool.
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?
With 0% schema description coverage, the description must explain the parameters, but it only references 'a URL' and vaguely 'and where.' It does not explain the optional tags, title, or page_url parameters, leaving significant ambiguity about their meanings and usage.
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 clearly states the tool's function: to tell Fetchive that a URL has been saved to the workspace. The phrase 'it is the only way duplicate detection learns what exists' distinguishes it from sibling tools like check_duplicate, establishing a unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool 'after every successful save' and declares it 'the only way duplicate detection learns what exists.' This provides a clear when-to-use directive and implicitly states that no alternative tool can replace this function, satisfying the exclusion criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that it processes a few items at a time for practical capacity reasons and that it uses the model. This adds useful behavioral context without contradicting 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?
Two concise, front-loaded sentences that state the action, the triggering condition, the repetition loop, and the rationale for batching. No redundant information.
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?
The description covers the workflow, batching behavior, and why limits exist. Since an output schema exists, return details are already handled. It lacks error-handling notes, but overall it is sufficient for a tool of this complexity.
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?
The schema has 0% coverage, so the description must compensate. It implies batch_id (via 'a batch') and limit (via 'a few items at a time'), but does not explicitly name or explain the parameters or their effects. Partial compensation.
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 clearly identifies the tool's function: writing summaries and tags for pending extracted items using the model. It references specific workflow states ('needs_summary', 'remaining') which distinguishes it from sibling tools like add_summary.
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?
Explicitly states when to call the tool (after archive_batch reports needs_summary) and how to loop until remaining reaches zero. However, it does not mention alternatives or explicitly state when not to use it, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint false and destructiveHint false, but the description adds crucial async behavior: 'Returns a batch ID immediately; extraction runs in the background' and 'Poll get_batch_status'. It also discloses that already-archived links are skipped. No contradictions with 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?
The description is two sentences, front-loaded with the main action, and includes necessary follow-up instruction. Every clause adds value with no redundancy.
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 tool's simplicity (one input), an output schema, and async behavior, the description adequately covers input semantics, immediate output (batch ID), and next steps. It omits error cases and rate limits, but these are not critical for basic selection and invocation.
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 sole parameter 'text' has no schema description, but the description explains it as 'pasted text (a KakaoTalk or Slack export, a bare list, anything)' and specifies it as the source of links. This fully compensates for the lack of schema coverage, though it doesn't mention size limits or formatting.
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 uses specific verbs: 'Parse every link out of pasted text', 'skip what is already archived', 'extract YouTube transcripts', and 'prepare a page payload'. It clearly states the tool's purpose and distinguishes it from siblings like ingest_links by emphasizing batch processing and asynchronous behavior.
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?
The description provides clear usage context, listing example input types ('KakaoTalk or Slack export, a bare list, anything') and instructing to poll get_batch_status. However, it lacks explicit exclusions or alternative tool references, such as when to use ingest_links instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral details beyond that: it matches against canonical URL forms and compares titles against archived titles to detect re-uploads and mirrors. This explains how the check is performed, which is not inferable from structured fields alone.
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 consists of two sentences, with the first posing a direct, purpose-clarifying question. The second sentence adds key matching behavior. No extraneous words; every phrase earns its place.
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 tool's simplicity (2 params, no nested objects) and the presence of an output schema and annotations, the description is largely complete. It covers the main behavior and parameter semantics. Minor gaps like return format are handled by the output schema, and safety is covered by annotations. A 4 is appropriate as it leaves some ambiguity about edge cases (e.g., what counts as a canonical match).
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 input schema has no descriptions (0% coverage), so the description must compensate. It does so by explaining the role of each parameter: 'url' is matched in canonical form, and 'title' (optional) is compared against archived titles. This provides meaning that the schema lacks, though it doesn't deeply elaborate on URL normalization or title matching specifics.
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 clearly states the tool's purpose with a direct question: 'Has this URL already been archived?' It specifies the resource (URL) and the action (checking for duplicates), and distinguishes itself from siblings by detailing the matching logic (canonical form, title comparison) that other search/archive tools likely don't include.
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?
The description implies the use case: check for duplicates before archiving. It gives clear context for when to use this tool, but does not explicitly mention alternatives or when not to use it. Sibling names like 'search_archive' suggest related but distinct functions, yet no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it discloses the sequential fallback behavior, reporting of failures, and caching semantics. This provides useful operational context that annotations (readOnlyHint false, idempotent false) do not capture, such as why a request might be expensive the first time.
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, each providing distinct value: the main function, the fallback/reporting behavior, and the caching note. No wasted words.
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 tool's moderate complexity, the description covers the core behavior, fallback chain, and cache characteristics. An output schema exists, so it needn't explain return values, but it might have mentioned output language or format limitations. Still, it's reasonably complete.
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 compensate. It implies the URL as the video identifier and mentions caching (use_cache), but doesn't explicitly explain the parameters or their formats. It adds some meaning but leaves gaps.
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 starts with a specific verb+resource: 'Get the transcript for one YouTube video.' It clearly differentiates from sibling tools like archive_batch or summarise_pending by focusing on transcript extraction. The scope is unambiguous.
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?
The description explains the fallback mechanism (caption APIs, yt-dlp, local speech-to-text) and notes that caching makes repeated calls free. This gives an implied usage context, though it doesn't explicitly state when to choose this tool over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent hints, so the description adds value by disclosing platform classification and the no-archive behavior. It does not contradict annotations and provides additional context without needing deeper details.
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 two sentences, front-loaded with the core action, and contains no wasted words. Every clause adds information.
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 extraction tool with a rich output schema and strong annotations, the description is mostly complete. It could specify the set of platforms considered, but the output schema likely covers that.
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 schema has no description on the 'text' parameter (0% coverage), but the description's 'text blob' directly maps to the parameter's purpose. It is clear enough for an agent to know that the input should be the text to extract links from.
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 uses a specific verb ('Pull every URL out') plus resource ('text blob') and adds the classification behavior, which distinguishes it from siblings like archive_batch and extract_youtube_script. The phrase 'without archiving anything' also clarifies its scope.
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 provides clear context ('Useful for showing the user what was found first') and an implicit exclusion ('without archiving anything'), but it does not explicitly name alternative tools or define when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fetchive MCP server](https://glama.ai/mcp/servers/lsmman/fetchive/badges/card.svg)](https://glama.ai/mcp/servers/lsmman/fetchive)

Score Badge

Copy to your README.md:

[![fetchive MCP server](https://glama.ai/mcp/servers/lsmman/fetchive/badges/score.svg)](https://glama.ai/mcp/servers/lsmman/fetchive)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lsmman/fetchive'

If you have feedback or need assistance with the MCP directory API, please join our Discord server