איך להפוך קובצי PDF ו-Word לטקסט עבור AI: MarkItDown של Microsoft

הוראות נוספות זמינות בתיעוד של Ailoot.

מהו MarkItDown ולמה הוא מיועד?#

אתם שולחים ל-AI חוזה, דוח או ייצוא חשבונאי, ומקבלים תשובה שאין לה שום קשר למסמך. בדרך כלל המודל אינו הבעיה. הקובץ מכיל פורמט: Word הוא ארכיון עם סימון, Excel הוא גיליון אלקטרוני עם קישורים בין תאים, ו-PDF הוא אוסף תווים עם קואורדינטות על הדף. המודל עובד עם טקסט, ומישהו צריך לחלץ את הטקסט הזה.

לשם כך נועד MarkItDown. המאגר נמצא בכתובת github.com/microsoft/markitdown, תחת רישיון MIT, כך שאפשר להשתמש בו ללא הגבלות. נכון ל-18 באוגוסט 2026, יש לו 174,412 כוכבים ו-12,756 forks; הגרסה האחרונה, 0.1.7, יצאה ב-29 ביולי. הפרויקט פעיל, אך המיקוד שלו עבר מפיתוח לתחזוקה: יש לו 481 בקשות משיכה פתוחות, לעומת 183 שאוחדו לאורך כל ההיסטוריה שלו.

המפתחים מתארים את מטרתו כך:

המשפט הבא בתיאור מסביר מחצית מהתלונות שאנשים מעלים על הכלי:

התוצאה היא חומר גלם למודל. היא לא תהיה מסמך יפה, והפרויקט אומר זאת בבירור, ממש בחלק הראשון.

התיאור מסביר ישירות למה הוא משתמש ב-Markdown: מודלים מובילים כבר ״מדברים״ את שפת הסימון הזאת ומשלבים אותה בתשובותיהם בלי שהתבקשו, כי נחשפו לכמויות עצומות שלה במהלך האימון. הסימון גם קומפקטי: שלושה סימני סולמית לכותרת במקום תריסר שורות של מטא-נתונים.

במה MarkItDown שונה מממיר רגיל?#

ההבדל מתבהר בדוגמה אחת. נניח שיש תיקייה עם עשרים קובצי PDF ומנסים להעביר אותם דרך pandoc. זה לא יעבוד: pandoc יכול להפיק קובצי PDF, אך אינו יכול לקרוא אותם כקלט. וזה בדיוק המצב הנפוץ ביותר: ״יש לי ערימה של מסמכים; תנו אותם למודל״.

מחברי MarkItDown משווים את עצמם ל-textract, ספרייה שפשוט מחלצת טקסט מכל מקום. ההבדל הוא ש-MarkItDown מנסה לשמר את המבנה: כותרות, רשימות, טבלאות וקישורים.

המסקנה המעשית פשוטה. אם צריך להמיר מאמר לפריסה המיועדת לפרסום, השתמשו ב-pandoc. אם אתם צריכים ש-AI יבין עשרים חוזים, השתמשו ב-MarkItDown.

איך מתקינים את MarkItDown בלי לקבל את הגרסה הראשונה?#

קודם הפקודה הנכונה; אחר כך נסביר למה היא נכונה.

1. בדקו את גרסת Python

   Python 3.12 היא הגרסה האמינה ביותר: MarkItDown העדכני ביותר מותקן בכל סביבה שנבדקה בה. הפקודה python3 --version מציגה את הגרסה שברשותכם. במחשבי Mac עם מעבדי Intel או במחשבי Mac עם גרסת macOS ישנה יותר, Python 3.13 ו-3.14 עלולות לבצע נסיגה שקטה; Python 3.15 עדיין אינה נתמכת, כפי שמוסבר בהמשך.

2. התקינו עם רשימת הפורמטים

   הריצו pip install 'markitdown[pdf,docx,xlsx,pptx]'. המרכאות נחוצות, אחרת ה-shell יפרש את הסוגריים המרובעים. במחשב Mac עם מעבד Intel, הוסיפו את הדגל --prefer-binary אחרי install.

3. בדקו מיד שההתקנה הצליחה

   הריצו markitdown --version. התשובה אמורה להיות markitdown 0.1.8 או גרסה מאוחרת יותר. מספר נמוך יותר פירושו שההתקנה נסוגה לגרסה ישנה; הסעיף הזה מסביר למה.

pip install 'markitdown[pdf,docx,xlsx,pptx]'
markitdown --version

תיאור הפרויקט מציג את pip install 'markitdown[all]' כפקודה הראשית להתקנת הכול בבת אחת. ב-28 בספטמבר 2026, שבוע אחרי שגרסה 0.1.8 יצאה, הופעלו ארבע גרסאות של הפקודה בסביבות נקיות במחשב Mac עם Apple Silicon, עם Python 3.14.6 ו-3.12.12:

כל שמונה ההתקנות הסתיימו בהודעה “Successfully installed”, והפקודה markitdown --version החזירה 0.1.8 בכל מקרה. באוגוסט, כש-0.1.7 הייתה הגרסה העדכנית ביותר, הפקודה השלישית ב-Python 3.14 התקינה את 0.0.2, שיצאה ב-8 במרץ 2025 — הגרסה השנייה בתולדות הפרויקט. כעת יש לו אחת עשרה גרסאות יציבות, מ-0.0.1 עד 0.1.8, ועשרים ושש גרסאות בסך הכול, כולל גרסאות קדם-הפצה.

הסיבה הייתה שרשרת התלויות. בגרסה 0.1.7, התוספת [all] כוללת ספריית כתוביות YouTube מסדרת גרסאות מסוימת, וכל הגרסאות בסדרה הזאת מצהירות שאינן פועלות ב-Python 3.14. תוכנית ההתקנה דוחה אותן, ומכיוון שלא הוצמדה גרסה, היא חוזרת אחורה בין גרסאות MarkItDown עד שהיא מוצאת גרסה שאפשר להתקין. היא מוצאת את 0.0.2 ומתקינה אותה, כך שמותקנת במחשב גרסה מלפני שנה וחצי. בגרסה 0.1.8 הועלתה דרישת גרסת ספריית הכתוביות לסדרה שתואמת ל-3.14, והנסיגה נעצרה שם.

המנגנון עדיין קיים. אם תוכנית ההתקנה אינה מוצאת רכיב נדרש למערכת שלכם, היא נסוגה בשקט ל-0.0.2 באותו אופן. בגרסאות האחרונות מדובר במנוע onnxruntime שמשמש את מזהה סוגי הקבצים. ב-Mac, הזמינות שלו היא כזאת: עבור Python 3.12, macOS 11 ואילך; עבור 3.13, macOS 13; עבור 3.14, Apple Silicon בלבד עם macOS 14 ואילך. אם ה-Mac שלכם אינו עומד בדרישות, אפילו הפקודה הבסיסית pip install markitdown מתקינה את 0.0.2. בדיקה במחשב Mac עם מעבד Intel שהריץ Python 3.14 דרך Rosetta הניבה בדיוק את התוצאה הזאת: “Successfully installed”, ללא אזהרות, ובתוכו 0.0.2.

יש למחשבי Mac עם מעבדי Intel סיבוך נוסף. מאז יוני 2026, ספריית cryptography שנמשכת לצורך קריאת קובצי PDF יוצאת ללא גרסה מוכנה מראש למעבד הזה, ולכן תוכנית ההתקנה מנסה לבנות אותה מקוד המקור. הוסיפו לפקודה את הדגל --prefer-binary, והיא תשתמש בגרסה הקודמת שיש לה חבילה מוכנה מראש. בבדיקה ב-Python 3.13 למעבדי Intel, הדבר התקין את 0.1.8, וקובץ ה-PDF נפתח. הדגל מתקין את cryptography 48.0.1, שיש לה שלוש פגיעויות ידועות: בפענוח PKCS#7 ובאימות שרשרת אישורים. MarkItDown משתמש בה רק לפענוח קובצי PDF מוצפנים, וקריאת מסמכים אינה מגיעה לחלקים האלה.

ב-Python 3.15 מתרחשת נסיגה משתי סיבות. גרסה 0.1.8 מצהירה על תמיכה רק מ-3.10 עד 3.14, ועדיין אין מנוע ל-3.15. פתרון התלות של תוכנית ההתקנה ל-3.15 מאשר זאת: גם הפקודה הבסיסית וגם הפקודה עם הפורמטים מתקינות את אותה גרסה 0.0.2.

כך נראית אזהרת נסיגה, שורה אחת עבור כל תוספת שבפקודה:

WARNING: markitdown 0.0.2 does not provide the extra 'all'

השורה הולכת לאיבוד בין עשרות שורות הורדה, והיא אינה אומרת דבר על הגרסה שהותקנה במקומה. בפקודה בסיסית ללא תוספות אין אפילו אזהרה. הדיווח הסופי משמח: “Successfully installed.”

גם התקנה ללא תוספות אינה פתרון. החבילה הבסיסית מותקנת, אך אינה יכולה לפתוח קובצי PDF:

PdfConverter recognized the input as a potential .pdf file, but the
dependencies needed to read .pdf files have not been installed. To resolve
this error, include the optional dependency [pdf] or [all] when installing
MarkItDown. For example:

* pip install 'markitdown[pdf]'
* pip install 'markitdown[all]'

הכלי עצמו ממליץ על [all], ובגרסה 0.1.8 העצה הזאת שוב עובדת ב-Python 3.14 וב-3.12. ובכל זאת, עדיף לציין פורמטים בשמות: [all] מוסיפה עוד כחמש עשרה חבילות וכ-55 מגה-בייט, כולל ספריית Azure בגרסת קדם-הפצה ושרשרת התלויות של YouTube שכבר שברה את ההתקנה פעם אחת.

תוכנית ההתקנה מטפלת בעצמה בספריית Azure שבגרסת קדם-הפצה. בדרך כלל pip מדלגת על גרסאות קדם-הפצה, אך כאן הדרישה מציינת במפורש גרסה כזאת ולכן היא מותקנת. ארבע גרסאות של pip, מ-23.2 עד 26.2, נבדקו ב-Python 3.12; כולן בוחרות בגרסה 0.1.8.

באוגוסט, התקנה חוזרת בסביבה נקייה אחרת הניבה את אותה תוצאה: 0.0.2 והמילה “Successfully”.

כדאי להכיר מראש כמה פרטים מעשיים.

ההתקנה גדולה למדי: התקנה בסיסית תופסת 143 מגה-בייט; עם ארבעה פורמטים, 303. הרכיב הכבד ביותר, 81 מגה-בייט, הוא מזהה סוגי הקבצים, שנכלל אפילו בהתקנה הבסיסית. זה לא משנה במחשב נייד, אבל כן משנה בפונקציית ענן עם מגבלת גודל.

אל תסמכו על מראות מאגר כחלופה. מראה שנבדקה סיפקה אינדקס וקובצי MarkItDown היו בה, אך תלות נדרשת אחת הייתה חסרה, ולכן ההתקנה נכשלה גם ב-Python 3.14 וגם ב-3.12.

ההתקנה היא עניין קטן בהשוואה לבעיה העיקרית. לעיתים קרובות הרבה יותר, AI מפיק שטויות כי הדבר הלא נכון, או ייצוג שגוי שלו, נכנס לחלון ההקשר שלו. היכולת להחליט מה לתת למודל לפני משימה נקראת הנדסת הקשר, והכנת מסמכים היא חלק ממנה.

איך הופכים את המסמך הראשון לטקסט?#

האפשרות הקצרה ביותר:

markitdown dogovor.docx

הטקסט מוצג בטרמינל. כדי לשמור אותו לקובץ, יש שתי דרכים:

markitdown dogovor.docx -o dogovor.md
markitdown dogovor.docx > dogovor.md

ב-Mac וב-Linux ההבדל זניח, אך ב-Windows הוא חשוב: הפניה מחדש באמצעות > עלולה לקרוס כאשר הפלט מכיל טקסט קירילי.

אפשר להעביר קובץ כזרם; במקרה כזה מועיל לציין את סיומת הקובץ:

cat dogovor.docx | markitdown -x docx

אלה הדגלים העיקריים מעזרת גרסה 0.1.8:

באותה עזרה מפורטים עוד שלושה דגלים שימושיים, שכל אחד מהם נבדק: --list-plugins מציג תוספים מותקנים, -p מפעיל אותם בהרצה מסוימת, ו---keep-data-uris משאיר בפלט תמונות המוטמעות במסמך (כברירת מחדל הן נחתכות). היתר הם הגדרות לשירותי הענן של Microsoft.

מעטפת Python כוללת שלוש שורות:

from markitdown import MarkItDown

md = MarkItDown()
print(md.convert("ostatki.xlsx").text_content)

אותה קריאה מקבלת גם URL. דף פשוט החזיר טקסט נקי של 167 תווים, כולל כותרת וקישור, בלי התפריט והכותרת התחתונה:

r = md.convert("https://example.com")

אילו פורמטים MarkItDown מבין, ומה זה באמת אומר?#

טבלת סיכום של מה שנטען ושל משמעותו בפועל.

שלושה דברים, בפירוט נוסף.

תמונות. בתיאור מופיעה המילה OCR, ולכן אנשים מצפים שהתוכנית תקרא טקסט מתוך תמונה. היא אינה עושה זאת. היא קוראת מטא-נתונים באמצעות תוכנית נפרדת, exiftool, ואם מחברים אליה מודל ראייה עם מפתח משלכם, היא יכולה לשלוח אליו את התמונה כדי לקבל תיאור.

אודיו. תמלול דיבור זמין, אך השפה אינה מועברת, והמנוע מצפה לאנגלית כברירת מחדל. הוא גם קורא לנקודת קצה חינמית ולא רשמית של Google, שמוגבלת לכחמישים בקשות ביום לכל מפתח.

ארכיונים. התוכנית פורקת קובצי ZIP ועוברת על הקבצים שבתוכם, ומשרשרת את התוצאות. אם אי אפשר לנתח קובץ, השגיאה נתפסת ומדוכאת. הקובץ פשוט לא יופיע בתוצאה, ולא תדעו שהוא חסר.

מה קורה במסמכים שמכילים טקסט קירילי?#

הקבצים שבהמשך נוצרו במיוחד לבדיקה; הנתונים שבהם מומצאים.

גיליון המלאי ב-Excel יצא נקי באותה מידה, כששם הגיליון הפך לכותרת:

## Stock
| Item | In stock | Reserved | Available |
| --- | --- | --- | --- |
| Coffee beans, kg | 420 | 38 | 382 |
| Loose-leaf tea, kg | 180 | 52 | 128 |

המצגת הפכה לטקסט, עם מספרי שקופיות כהערות וכותרות השקופיות ככותרות. גם כאן הטקסט הקירילי נשמר בשלמותו. הטענה הגורפת ש״MarkItDown לא מבין קירילית״ אינה נכונה.

ועכשיו לשלושת המקומות שבהם דברים אכן משתבשים.

CSV עם נקודה-פסיק. שני ייצואי חשבוניות זהים עובדו לצורך השוואה. זה שהשתמש בפסיקים יצר טבלה תקינה בת ארבעה עמודות. עם נקודה-פסיק, כל השורה נכנסת לתא אחד.

כל השורה נכנסה לתא אחד. הקידוד זוהה כראוי, ולא הייתה שגיאה; הדגל -c אינו עוזר. המודל יקבל את הטבלה הזאת ולא יבין איזה ערך הוא הסכום ואיזה הוא הסטטוס. ייצאו את הקובץ מחדש עם מפריד פסיק מפורש והקידוד הנכון, תוך השארת המקור ללא שינוי. אל תחליפו נקודה-פסיק באופן גורף: מפרידים בתוך טקסט במירכאות ופסיקים עשרוניים יכולים להיות חלק מערך. אם אי אפשר לייצא מחדש, פענחו את המקור באמצעות המפריד האמיתי שלו וכתבו CSV חדש באמצעות כלי כתיבה שמבין CSV ושומר על ציטוט וערכי תאים. לפני הניתוח, השוו מספר עמודות, מספר שורות וסכומי בקרה לייצוא המקורי.

עיצוב מטבע ב-Excel. סמל המטבע שמור בהגדרות התצוגה של התא ואינו חלק מהערך עצמו. מתחזקי הפרויקט אישרו את הסיבה. במחירון או בחשבונית יש לכך משמעות: המודל יראה מספרים בלי לדעת לאיזה מטבע הם שייכים.

מסוף Windows. בקבצים עם תווים שאינם לטיניים התוכנית עלולה לקרוס.

עקבת השגיאה מציגה את הקידוד cp1251, כלומר את מסוף Windows. המסמך עצמו מנותח כראוי; ההדפסה של התוצאה בחלון הטרמינל היא שנכשלת. יש שני פתרונות עוקפים:

markitdown dogovor.docx -o dogovor.md
$env:PYTHONUTF8 = "1"; markitdown dogovor.docx > dogovor.md

הראשון עוקף את המסוף לחלוטין; השני גורם ל-Python לכתוב ב-UTF-8. אנשים הגישו תיקונים לבעיה בכלי עצמו לפחות שש פעמים: חלק מההצעות נסגרו בלי מיזוג, והיתר עדיין פתוחות. לכן צריך להשתמש בפתרון עוקף.

תסמין רביעי מופיע בקובצי PDF: רצפים כמו (cid:1090) במקום אותיות. פירוש הדבר הוא שבקובץ יש טבלת גופנים לא תקנית ושאי אפשר היה לפענח את התווים שלו. אין טעם לעבד מסמך כזה באמצעות MarkItDown; צריך כלי אחר.

למה PDF יוצא כבלגן?#

לצורך הבדיקה עובד מאמר מדעי בן שני טורים, בגודל 2.16 מגה-בייט. קוד היציאה היה 0; אחרי 0.9 שניות הפלט הכיל 88,000 תווים, שכמעט כולם היו שטויות. שמונים ושמונה אלף תווים יוצרים רושם שהכול עבד. עד שפותחים את הקובץ:

|     | Hybrid |          | OCR-LLM     |     | Framework  |
| --- | ------ | -------- | ----------- | --- | ---------- |
...
Informationextractionfromcopy-heavydoc-
5202 tcO 11  ]LC.sc[  1v83101.0152:viXra

שלושה דברים השתבשו בבת אחת. פריסת שני הטורים הפכה לטבלאות שאינן קיימות במאמר. מילים התחברו בלי רווחים. השורה האחרונה היא סרגל צד אנכי בדף, שחולץ בסדר הפוך.

ואז הגיע החלק המשעשע. התברר שמאמר הבדיקה היה בדיוק המחקר שמדד את MarkItDown והשווה אותו לכלים אחרים. הכלי הפך את הפסקה שדיווחה על המדידות שלו עצמו לזה:

cues. This name-matching error could be miti-  OCRpreprocessingoverhead(0.056s),whileDo-
gatedthroughpromptengineeringtoprovidemore  clingandMinerUadoptmorecomputationallyin-
explicit matching instructions or fine-tuning the  tensive strategies with OCR latencies of approxi-

הטורים השמאלי והימני חוברו שורה אחר שורה. מודל שיקבל זאת יקרא חצי משפט מפסקה אחת וחצי מפסקה אחרת.

הסיבה טכנית ופשוטה. Word שומר במפורש ״זאת כותרת״ ו״זה תא בטבלה״. PDF שומר ״זה תו״ ו״אלה הקואורדינטות שלו על הדף״. שחזור המבנה מתוך קואורדינטות הוא משימה נפרדת וקשה, ו-MarkItDown כמעט אינו מנסה לבצע אותה. קוד המקור לניתוח PDF אינו כולל זיהוי כותרות: אם דף אינו מזוהה כטופס או כטבלה, כל המסמך עובר חילוץ טקסט בסיסי.

משתמשים מדווחים על כך בקביעות במאגר של הפרויקט, כולל במאמרים מדעיים ובטבלאות.

הכלי אינו מוצא אפילו כותרת אחת בקובצי PDF, בדיוק כפי שמראה קוד המקור שלו.

הנתון ״MarkItDown מגיע לדיוק של 82%״ מופיע באינטרנט בלי שום מתודולוגיה. מעקב אחריו עד למקור המקורי אינו מוביל לשום מקום: שרשרת הקישורים מסתיימת בדף שאינו נטען. אי אפשר להתייחס אליו כאל מדידה.

מה קורה עם חוזה סרוק?#

ההתנהגות הזאת מסוכנת יותר מהאחרות כי היא אינה נראית כמו כישלון.

לצורך הבדיקה נוצר PDF מתמונה המכילה טקסט — בדיוק מה שמתקבל כשמצלמים או סורקים חוזה. הבדיקה חזרה על עצמה כדי לשלול מקרה מקרי:

אפס תווים ואפס שגיאות, פעמיים ברצף. קוד יציאה 0 פירושו ש״הכול עבר כשורה״, וכל סקריפט שבודק הצלחה לפי קוד יציאה יחשיב את המסמך למעובד. אחר כך הפלט הריק נשלח למודל, המודל אינו רואה דבר ומתחיל להמציא תשובה יש מאין.

יש שני פתרונות עוקפים, ושניהם בתשלום. הראשון הוא הדגל -d, ששולח את המסמך לשירות הזיהוי בענן של Microsoft; טקסט העזרה של הדגל מציין במפורש שנדרשת נקודת קצה תקפה של השירות. השני הוא חבילת הרחבה נפרדת ששולחת עמודים למודל ראייה באמצעות המפתח שלכם, כך שאתם משלמים לספק המודל על כל עמוד. מאז אפריל 2026, בדיון פתוח על השיטה השנייה דווח שרק העמוד הראשון של סריקה מרובת עמודים מעובד.

אפשר גם להריץ מודל זיהוי במחשב שלכם, אך זהו פרויקט נפרד.

למסמך חד-פעמי קל יותר לפתוח אותו ולהעתיק את הטקסט ידנית. עבור זרם של סריקות, צריך כלי עם זיהוי מובנה.

אפשר פשוט להעלות את הקובץ לממיר מקוון?#

״MarkItDown online״ היא אחת מהצעות החיפוש הנפוצות ביותר, ויש אתרים שמציעים אותו. לכלי המקורי של Microsoft אין אתר כלל; הוא זמין רק כתוכנית שמתקינים בעצמכם. כל דבר עם שם דומה שנפתח בדפדפן נוצר בידי מישהו אחר.

אפשר לבדוק שירות כזה בתוך דקה: פתחו את כלי המפתחים בלשונית של בקשות הרשת, העלו קובץ לא מזיק ובדקו אם הוא נשלח לשרת. אם כן, הטענה על עיבוד בדפדפן אינה נכונה, גם אם היא מוצגת בביטחון מלא בשאלות הנפוצות.

לכן MarkItDown מוערך במקומות שבהם אסור לשלוח מסמכים אל מחוץ לארגון. בדיון אחד מישהו תיאר את מצבו: במחשב העבודה שלו נאסרו תוכניות שרירותיות, אך ספריות Python היו מותרות, והכלי המקומי התגלה כאפשרות היחידה הזמינה.

כמה MarkItDown באמת חוסך?#

קובץ Office הוא ארכיון מובנה המכיל סימון. אם פותחים את שלושת קובצי הבדיקה ומשווים את גודל החלק שמכיל את התוכן לגודל הפלט, מתקבלת התוצאה הזאת:

הקבצים קטנים; היחסים יהיו שונים בקבצים גדולים יותר, ואין נתון חיסכון יחיד. כאשר מופיעים מספרים עגולים במאמרי השוואה, שאלו על המתודולוגיה.

המפתחים עצמם מדברים גם על חיסכון: תיאור הפרויקט מציין במפורש שמוסכמות Markdown חסכוניות מאוד בתווים. זה נכון, אך לא כדאי שזה יהיה יתרון המכירה העיקרי. ההבדל בין ״המודל קיבל שלושת אלפים תווים במקום חמישה עשר אלף״ לבין ״המודל קיבל מבנה ברור במקום ערבוביה״ הוא בסדר גודל אחר. הראשון חוסך כסף; השני קובע אם התשובה תהיה הגיונית.

אם צריכת ההקשר מדאיגה אתכם, יש על כך הסבר נפרד: לאן הולכים הטוקנים ב-Claude וכמה מהם כלולים בכל תוכנית.

איך מחברים את MarkItDown ל-Claude דרך MCP?#

MCP היא דרך להעניק ל-AI כלי חיצוני שהוא יכול להשתמש בו בעצמו. לסקירה של המנגנון ושל שרתים אחרים, ראו את הסקירה של שרתי MCP ל-Claude Code.

שרת MarkItDown חושף כלי אחד בלבד: המרת מסמך לטקסט. הוא מקבל נתיב לקובץ מקומי, כתובת של דף או נתונים המשובצים ישירות בבקשה.

החיבור ל-Claude Code נעשה בפקודה אחת, עם הצמדה של גרסת השרת. דרוש מנהל החבילות uv:

claude mcp add --scope user --env 'ORT_DISABLE_TELEMETRY=1' --env 'UV_PYTHON=3.12' --transport stdio markitdown -- uvx markitdown-mcp@0.0.1a7
claude mcp list

התגובה לפקודה השנייה אמורה להציג “Connected” עבור markitdown. ההפעלה הראשונה מורידה כשבעים חבילות ונמשכת עד דקה; לאחר מכן השרת מופעל בתוך שנייה עד שנייה וחצי.

אלה ההסתייגויות, שכל אחת מהן נבדקה ידנית.

בנייה 0.0.1a7 יצאה ב-14 בספטמבר 2026. לפני כן השרת נתקע במשך יותר משנה בגרסה 0.0.1a4 ממאי 2025. מספר הגרסה העדכני עדיין מציין גרסת קדם-הפצה.

היא לא תותקן בכל מערכת עם גרסה עדכנית של Python. מנוע onnxruntime, שבו היא תלויה, זמין עבור Python 3.14 ב-Mac רק במחשבי Apple Silicon עם macOS 14 ואילך, ולכן ההתקנה נכשלת במחשבי Mac עם מעבדי Intel וב-macOS 13 או גרסה מוקדמת יותר עם Python 3.14. במחשב Mac עם Apple Silicon השרת הורץ ב-Python 3.14, 3.13 ו-3.12 והותקן בכל שלוש הגרסאות. הפקודה משתמשת ב-UV_PYTHON=3.12: חבילות מוכנות מראש ל-3.12 זמינות ב-Windows, ב-Linux ובמחשבי Mac עם Apple Silicon, ואם גרסת Python הזאת אינה ברשותכם, uv תוריד אותה. גם כאן יש הסתייגות למחשבי Mac עם מעבדי Intel: uv תבנה את ספריית cryptography מקוד המקור, משום שמאז יוני 2026 אין חבילה מוכנה מראש למעבדי Intel. ההתקנה נמשכת זמן רב יותר ועלולה להיכשל.

גרסת MarkItDown שמותקנת בפנים תלויה בגרסת uv. החל מ-MarkItDown 0.1.6, התוספת [all] שלו דורשת ספריית Azure בגרסת קדם-הפצה: uv 0.12 ואילך מתקינה אותה ואת MarkItDown 0.1.8 העדכני, ואילו גרסאות uv ישנות יותר נסוגות ל-0.1.5. בדקו את גרסת uv באמצעות uv --version.

שני דברים נשלחים מחוץ למחשב. הראשון הוא טלמטריה: ב-Mac וב-Linux, מנוע onnxruntime שבתוך השרת שולח אותה ל-Microsoft כברירת מחדל. המשתנה ORT_DISABLE_TELEMETRY=1 בפקודה משבית אותה. בבדיקה, השרת התחבר לנקודות הקצה של הטלמטריה של Microsoft בלעדיו. כאשר המשתנה הוגדר, לא היו כלל חיבורים בזמן עיבוד קבצים מהדיסק.

השני הוא אודיו. השרת שולח קובצי WAV, MP3, M4A ו-MP4 לשירות זיהוי הדיבור של Google לתמלול באמצעות HTTP רגיל, ללא הצפנה. עדיף לא להעביר דרכו הקלטות שיחות עם לקוחות.

מסמך גדול לא יעבור דרכו. דיון פתוח מתאר תגובת שרת של 51,000 טוקנים שנתקלה במגבלה של 25,000 טוקנים, והכלי אינו מחלק קבצים למקטעים.

וגם עניין האבטחה. התיעוד של החבילה עצמה אומר זאת בפשטות:

במילים אחרות, סוכן עם הכלי הזה יכול לקרוא כל דבר שאתם יכולים לקרוא. זה מקובל כשעובדים במחשב שלכם. אסור לחשוף את השרת לציבור או לתת אותו לסוכן שאינו מהימן.

לעבודה שוטפת קל יותר להפעיל את התוכנית בפקודה ולשים את הטקסט שהתקבל בתוך הפרויקט. הקובץ יושב אז לצד חומרים אחרים, והמודל יכול לעיין בו בעצמו.

מתי נכון יותר להשתמש בכלי אחר?#

השוואה לפי משימות; לכוכבי GitHub אין קשר לכך:

יש פרט על Marker שמאמרי השוואה משמיטים. מאז יולי 2026, הקוד עצמו מופץ תחת רישיון מתיר, ואילו משקלי המודל כפופים לרישיון נפרד עם סף: השימוש חינמי אם הכנסות החברה לא עלו על חמישה מיליון דולר, וסכום המימון שגויס בשנה הקודמת לא עלה על אותו סכום. סעיף נפרד אוסר שימוש על מי שבונה מוצר מתחרה. הדבר אינו משנה לרוב הקוראים, אך הוא סיבה לעסק צומח לקרוא את הרישיון לפני אימוץ הכלי.

מכאן נובע תהליך עבודה מעשי בן ארבעה שלבים:

1. העבירו הכול דרך MarkItDown — הוא חינמי ומיידי.
2. פתחו את התוצאה ובדקו את הגודל שלה.
3. אם הטקסט הגיוני, המשימה הסתיימה; אין צורך בשום דבר נוסף.
4. אם הפלט מבולגן או ריק, העבירו את הקובץ הספציפי הזה דרך כלי כבד יותר.

כך משלמים בזמן ובמורכבות רק עבור מסמכים שזקוקים לכך.

איך משלבים את MarkItDown בתהליך העבודה?#

Anthropic משתמשת ב-MarkItDown במיומנויות המוכנות שלה לעבודה עם קובצי Office, והמיומנויות האלה מנסחות את הגבול שכדאי לאמץ במלואו:

הפניות לתאים ולעמודים הולכות לאיבוד בטקסט, ולכן אי אפשר להשתמש בו כדי לשנות את קובץ המקור. הנה שלושה תרחישים.

אצווה של מסמכים דומים — אישורים, חשבוניות, טפסים ובקשות. שימו אותם בתיקייה והפעילו בשורה אחת:

for f in dokumenty/*.docx; do markitdown "$f" -o "text/$(basename "$f" .docx).md"; done

אחר כך תנו למודל את תיקיית קובצי הטקסט ובקשו ממנו לאסוף את המידע הרלוונטי לטבלה. זה עובד עם קבצים דיגיטליים; סריקות ייכשלו, ותזהו אותן מיד לפי הגודל 0 שלהן.

חומרי פרויקט קבועים — מחירונים, תבניות חוזה, נהלים ותיאורי שירותים. המירו אותם לטקסט פעם אחת והניחו אותם לצד הפרויקט. כך המודל יוכל לקרוא אותם בכל בקשה, ולא תצטרכו לצרף את הקבצים לשיחה בכל פעם. המאמר על העלאת קבצים ל-Claude מסביר במה הדבר שונה מהעלאת קובץ לצ'אט.

ייצוא ממערכת חשבונאית. ייצוא Excel מתוכנת הנהלת חשבונות או מחשבון בנק הופך לטבלה בתוך שליש שנייה, והמודל יכול לחשב ממנו בלי התעסקות ביניים. בדקו שקובץ CSV יוצא או פוענח באמצעות המפריד, כללי הציטוט והקידוד האמיתיים שלו, והשוו שורות, עמודות וסכומי בקרה לפני מסירתו למודל. אל תנרמלו מפרידים באמצעות חיפוש והחלפה. ציינו גם את המטבע במפורש: סמל ששמור רק בעיצוב תא Excel לא ישרוד את חילוץ הטקסט.

עיבוד קובצי PDF גדולים בטרמינל אינו מופיע ברשימה הזאת. זו בעיה נפרדת הקשורה לצריכת ההקשר, והיא מכוסה במאמר על עבודה עם קובצי PDF ב-Claude Code בלי לאבד טוקנים. אם אתם רק מגדירים את סביבת העבודה, התחילו בהתקנת Claude Code.

כדי להתחיל עכשיו, הריצו pip install 'markitdown[pdf,docx,xlsx,pptx]', עבדו את חוזה ה-Word הראשון שתמצאו ובדקו את גודל התוצאה. בתוך חצי דקה תדעו אם הוא עובד עם הקבצים שלכם.

כשתהיו מוכנים, הכירו את Ailoot.