הצעות תיקונים למקרי קצה בכלי הCk MCP

[amirbiron]

1. שני סעיפים עם אותה כותרת. חדש, והכי שווה. ב-docs/mcp-server.rst יש שני סעיפים בשם "מצבי הקצה", תחת הורים שונים. ‏docs_get_section עונה ambiguous_section ומחזיר את טווח השורות של כל אחד, אבל אין לו פרמטר lines=. משתמש שאינו אדמין לא יכול לבקש רק את אחד מהם, ונאלץ לקרוא את כל סעיף ההורה: 24,958 בתים במקום 10,009.

הייתי הולך על שם עם "שביל" ולא על lines=: למשל section="מדידת שימוש › מצבי הקצה". שני נימוקים:

• מספרי שורות זזים בכל עריכה של המסמך, ושם עם שביל נשאר נכון.
• ככה כבר כותבים אצלך הפניות לסעיפים. הבריף של multi_edit הפנה בדיוק כך: "מדידת שימוש › לכידת הכוונה". הכלי פשוט יקבל את מה שבני אדם כבר כותבים. ותשובת ה-ambiguous_section יכולה להחזיר לכל מועמד את השביל המלא שלו, מוכן להעתקה.

2. סעיפים גדולים נחתכים ב-12,000 תווים, בלי לספר מראש כמה גדול הסעיף. הסוכן מגלה רק אחרי החיתוך, ואז מדפדף או מנסה שוב. שני תיקונים זולים:

• כל תשובה מדווחת את הגודל המלא של הסעיף ואת מספר העמודים, כבר בתשובה הראשונה.
• להעלות את ברירת המחדל. אחרי feat(mcp): כל כלי קריאה מצהיר על תקרת התשובה שלו ועומד בה — מדידה אחת, ורשת אחרונה (#3460, #3474, #3481) #3492 יש תקרה של 256,000 בתים לכל תשובה, אז 12,000 תווים הוא שמרני מאוד. אפשר להעלות משמעותית, והתקרה עדיין תגן.

3. חיפוש של כמה מחרוזות בקריאה אחת. שלוש נקודות עריכה במסמך דרשו שלוש קריאות. אבל כאן צריך זהירות בעיצוב: אם query יהפוך ל"מחרוזת או רשימה", זה בדיוק האיחוד שדיברנו עליו אחרי PR 1. רשימה שנשלחת כמחרוזת JSON מ-Claude Desktop תגיע כמחרוזת, ותחפש את התווים ["a","b"] כפשוטם. עדיף פרמטר נפרד, queries, שהוא רק רשימה.

4. גרסה לכל עריכה: זה בדיוק multi_edit_file, שכבר עלה ונבדק הלילה.

ושים לב גם לתיקון שהסוכן שלח אחר כך: הוא כתב קודם 2,500 בתים, מדד, ותיקן ל-10,009. זה בדיוק ההרגל שאתה רוצה, לבדוק את המספר ולא להשאיר הערכה.