Meta ออกแบบ MCP tool ดีแค่ไหน เมื่อเทียบ 6 หลักที่ Anthropic สอน

โดย Nokka (นก-กา) | 18 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka

ก่อนอื่นต้องแก้ชื่อให้ตรงก่อน เพราะชื่อที่คนส่วนใหญ่ใช้กัน ไม่มีอยู่จริงแล้ว

"Meta Developer Tools MCP" ถูกเปลี่ยนชื่อเป็น Meta Social Technologies MCP ตั้งแต่ 18 สิงหาคม 2026 [11] ⇒ แต่ endpoint และคำนำหน้าชื่อ tool ยังเป็น devtools_ เหมือนเดิม [1]

⇒ Meta เขียนเหตุผลของการคงชื่อเดิมไว้ตรง ๆ [1]

"endpoint ของ server และคำนำหน้าชื่อ tool devtools_ ไม่เปลี่ยน ⇒ การตั้งค่าของ client ที่มีอยู่จึงยังใช้ได้" [1]

⇒ ผมคิดว่าการตัดสินใจนี้ถูกแล้ว เพราะการเปลี่ยนชื่อ tool จะทำให้ทุกคนที่ตั้งค่าไว้พัง ⇒ แต่ผมกลับเห็นว่ามันเผยความจริงที่ตรงข้ามกับที่ผมคาด

⇒ Meta ไม่ได้ทำแค่เปลี่ยนชื่อ ตอนนี้ Meta มี MCP server ที่เปิดให้ใช้ อย่างน้อย 2 ตัว และ สองตัวนั้นใช้ปรัชญาการออกแบบตรงข้ามกัน [1][2][3]

หนึ่ง: Meta มี 2 server ที่ออกแบบสวนทางกัน

ตารางนี้คือจุดตั้งต้นของบทความทั้งหมด [1][2][4]

มิติ	Meta Social Technologies	Ads MCP
Endpoint	mcp.facebook.com/devtools	mcp.facebook.com/ads
จำนวน tool	11	82
ระดับความละเอียด	1 tool ต่อ 1 โดเมน + พารามิเตอร์ actions	1 tool ต่อ 1 การกระทำ
ขอบเขต	จัดการแอปและ webhook	จัดการโฆษณาทั้งวงจร
สถานะ	เบต้า (ประกาศ 30 มิ.ย. 2026)	เบต้า (เปิด 29 เม.ย. 2026)

⇒ สังเกตตัวเลข 11 กับ 82 ⇒ ต่างกัน 7.5 เท่า ทั้งที่เป็นบริษัทเดียวกัน

และทั้งสองใช้ชื่อ tool แบบ namespaced ด้วยคำนำหน้าต่างกัน ⇒ devtools_ และ ads_ [1][4]

ประเด็นคือ 11 tools กับ 82 tools ไม่ใช่เรื่องบังเอิญ ⇒ มันสะท้อน คำตอบที่ต่างกัน ต่อคำถามเดียวกันในหลักออกแบบ MCP [4][5]

สอง: ทบทวน 6 หลักที่ผมจะใช้เป็นไม้บรรทัด

ผมเขียนหลักออกแบบ MCP tool ไว้ในบทความก่อน ⇒ รอบนี้ผมจะใช้หกข้อนั้นเป็นเกณฑ์ตัดสิน Meta [6]

หนึ่ง ⇒ รวม tool ที่ทำคล้ายกันเข้าด้วยกัน อย่าเปิด tool หลายตัวที่ agent ต้องเดาว่าตัวไหนใช้ตอนไหน
สอง ⇒ ตั้งชื่อให้เป็นระบบ ชื่อต้องบอกการกระทำและขอบเขต
สาม ⇒ ให้สัญญาณที่อ่านออก คำอธิบายต้องบอกว่าใช้เมื่อไร ไม่ใช้เมื่อไร
สี่ ⇒ คิดเพดานโทเคน ทุก tool มีค่าใช้จ่าย แม้ไม่ถูกเรียก
ห้า ⇒ ประกาศ annotation โดยเฉพาะ readOnlyHint และ destructiveHint
หก ⇒ ออกแบบให้ประเมินได้ ด้วย agent ไม่ใช่ด้วยตา

⇒ และผมจะใช้เกณฑ์ชุดเดิมนี้กับทั้งสอง server ⇒ ไม่ใช่เพื่อหาว่าใครผิด แต่เพื่อดูว่า บริษัทที่ออกแบบ API มากว่าทศวรรษ เลือกอะไร และเลือกเพราะอะไร [6]

สาม: สิ่งที่ Meta ทำได้ดี และดีกว่าที่ผมคาด

1) สร้างของที่ใช้เงิน ต้องเป็น "หยุด" ก่อนเสมอ

นี่คือการตัดสินใจออกแบบที่ผมคิดว่าดีที่สุดในทั้งสอง server [4]

"ขั้นตอนการสร้างทั้งหมดคือ campaign ⇒ ad set ⇒ creative ⇒ ad ⇒ activation **entity ถูกสร้างในสถานะ PAUSED เสมอ ⇒ การใช้จ่ายเริ่มเมื่อเรียก ads_activate_entity เท่านั้น" [4]

⇒ พูดอีกแบบคือ Meta แยก "สร้างของ" ออกจาก "เปิดใช้ของ" ⇒ เป็นการออกแบบที่ทำให้ความผิดพลาดที่แพงที่สุด เป็นไปไม่ได้ในทางโครงสร้าง

⇒ ถ้าเทียบกับหลักข้อห้า เรื่อง annotation ⇒ การออกแบบนี้ ดีกว่า annotation เพราะ:

annotation destructiveHint ⇒ เป็นคำอธิบาย ⇒ client อาจไม่สน
PAUSED by default ⇒ เป็นกลไกของระบบ ⇒ ต้องมีคนกดเปิด

⇒ ผมคิดว่านี่คือตัวอย่างที่ชัดที่สุดของหลักที่ผมเคยเขียนว่า "อย่าฝากความปลอดภัยไว้กับ prompt" ⇒ Meta ไม่ได้ขอให้ agent ระวัง แต่ทำให้มันทำไม่ได้ [6]

และ Meta ยังย้ำหลักนี้ในเอกสารอิสระที่ผมเปิดอ่าน [4]

"รักษา scope Read ไว้ เว้นแต่ agent จำเป็นต้องเขียนจริง ๆ ⇒ *ระวัง prompt injection เพราะเนื้อหาที่เชื่อถือไม่ได้ซึ่ง agent อ่านไป อาจพยายามชักจูงให้ทำสิ่งที่ไม่เหมาะสม*" [4]

2) ads_get_ad_entities ⇒ tool เดียวที่รวมสี่ระดับ

นี่คือตัวอย่างที่ตรงกับหลักข้อหนึ่งมากที่สุด [4]

"เครื่องมือหลักด้านข้อมูลและการรายงาน ⇒ query ระดับ account, campaign, ad set หรือ ad พร้อมตัวชี้วัด แอตทริบิวต์ breakdown ตัวกรอง และการเรียงลำดับ" [4]

⇒ Meta ใช้พารามิเตอร์ level ตัวเดียว [4]

level = account | campaign | adset | ad

⇒ แทนที่จะเปิด 4 tools แยกต่อ 4 ระดับ ⇒ และยังมี date_preset, time_increment และ breakdowns ให้ดึงหลายมิติในคำขอเดียว [4]

⇒ และมี tool ที่ผมคิดว่าฉลาดกว่าที่เห็น ⇒ ads_get_field_context [4]

"แคตาล็อก metadata ของฟิลด์รายงาน ⇒ ชนิด คำอธิบาย ระดับที่รองรับ กรองได้/เรียงได้ ตัวดำเนินการ และค่า enum *และแปลง alias** เช่น spend ⇒ amount_spent"* [4]

⇒ สองอย่างนี้รวมกันคือสิ่งที่ผมคิดว่า Meta ทำถูกที่สุดในเชิงออกแบบ ⇒ ให้ tool หนึ่งตัวอธิบายตัวเองได้ ⇒ agent ไม่ต้องเดาชื่อฟิลด์ และไม่ต้องลองผิดลองถูกซึ่งกิน rate limit [4]

3) แยก scope เป็นชั้น และให้ client ตรวจได้

ทั้งสอง server ใช้ OAuth ไม่ใช่ API key ⇒ ซึ่งตรงกับหลักที่ผมเขียนไว้ในบทความ production [1][4]

Meta Social Technologies ให้สอง scope ที่ตั้งรายแอปได้ [1]

Read ⇒ app config · สถานะ App Review · สถานะ compliance · API usage · webhook
Manage ⇒ ทุกอย่างใน Read + เขียน webhook + ส่ง test payload

⇒ และมีรายละเอียดที่ผมคิดว่าละเอียดดีมาก [1]

"การส่ง test payload ต้องใช้ Manage แม้มันจะไม่เก็บอะไร *เพราะมันทำให้ Meta ส่ง event จริงไปที่ callback URL ของคุณ** ⇒ การกันมันออกจาก Read หมายความว่า สิทธิ์แบบอ่านอย่างเดียวจะไม่ถูกชักจูงให้ไปกระตุ้นการส่งข้อมูลได้"* [1]

⇒ ประโยคนี้คือการคิดเรื่อง prompt injection ในระดับออกสิทธิ์ ⇒ ไม่ได้เป็นแค่การเขียนเตือน [1]

4) Activity log ⇒ ทำให้ตรวจสอบย้อนหลังได้

Ads MCP มี ads_account_get_activity_logs ⇒ เอกสารทางการระบุว่า [2]

"ดูการเปลี่ยนแปลงใน activity log ของบัญชีโฆษณา *เทียบเท่ากับหน้า campaign history ใน Ads Manager*" [2]

⇒ ผมคิดว่านี่คือสิ่งที่ MCP server หลายตัวลืม ⇒ agent ทำงานแทนคน แต่ ไม่มีร่องรอยให้คนตรวจ [2]

5) บอกข้อจำกัดของตัวเอง และไม่กลบ

เอกสารอิสระที่ไล่ทีละ tool รวบข้อจำกัดไว้ชัด ⇒ และผมคิดว่าการที่ server บอกว่า "ทำอะไรไม่ได้" มีค่าพอ ๆ กับบอกว่าทำอะไรได้ [4]

upload รูปหรือวิดีโอเข้าคลัง ⇒ ทำไม่ได้ (ดูรายการได้อย่างเดียว)
ลบ campaign / ad set / ad / creative ⇒ ทำไม่ได้ (มีแค่ pause ผ่าน update)
ลบ catalog / product set / feed ⇒ ทำไม่ได้
แก้เนื้อหา creative ที่มีอยู่แล้ว ⇒ ทำไม่ได้ (creative เป็นของที่แก้ไม่ได้)
ดึง Ad Library แบบปริมาณมาก ⇒ ทำไม่ได้ (ห้าม scraping)
ดูข้อมูล billing ⇒ ทำไม่ได้

⇒ ผมชอบข้อ "creative เป็นของที่แก้ไม่ได้" เป็นพิเศษ ⇒ เพราะมัน บังคับขั้นตอนที่ถูก คือสร้างใหม่แล้วผูกกับ ad ใหม่ ⇒ แทนที่จะเปิดช่องให้แก้ของเดิมซึ่งทำให้ประวัติเพี้ยน [4]

สี่: สิ่งที่ผมคิดว่าเป็นการออกแบบที่ยังมีปัญหา

1) 82 tools ⇒ ตัวเลขที่ขัดกับหลักข้อหนึ่งโดยตรง

หลักข้อหนึ่งบอกให้รวม tool ⇒ แต่ Ads MCP มี 82 tools แบ่งเป็น 9 หมวด [4]

Account discovery & structure 17
Insights & diagnosis 6
Datasets (Pixel) & conversions 5
Custom Audiences 7
Pixel: events & parameters 8
Creation & management of campaigns 7
Experiments (A/B & lift) 7
Product catalog ⇒ read 15
Product catalog ⇒ write 10

⇒ และหมวดที่ผมคิดว่าน่าตั้งคำถามที่สุดคือ catalog ⇒ 25 tools จาก 82 [4]

⇒ คือเกือบหนึ่งในสามของทั้ง server ใช้กับงานเดียว

⇒ และมีคนวัดต้นทุนจริงไว้ ⇒ งานวิเคราะห์ที่รายงานว่า โปรไฟล์ MCP 58 tools กิน input token ประมาณ 55,000 โทเคนในเซสชันเดียว [7]

"คุณกำลังจ่ายเงินจริงเป็นค่า input token ก่อนที่โมเดลจะเขียนคำตอบกลับแม้แต่คำเดียว ⇒ *ให้ลด scope ลง ⇒ ปิด tool หมวด catalog เมื่อไม่ได้ทำงาน commerce*" [7]

⇒ ผมยังไม่ได้วัดเอง ⇒ แต่ตัวเลขนี้ตรงกับหลักข้อสี่ที่บอกว่า ทุก tool มีค่าใช้จ่ายแม้ไม่ถูกเรียก [6][7]

และมีข้อเสนอเชิงออกแบบที่ตรงกับหลักข้อหนึ่งพอดี [7]

"หมวด product catalog ⇒ 25 tools น่าจะลดได้ด้วยพารามิเตอร์ operation แบบเดียวกับที่ Meta ทำได้แล้วใน ads_get_ad_entities" [7]

2) ชื่อ tool ไม่สม่ำเสมอ ⇒ ขัดกับหลักข้อสอง

นี่คือสิ่งที่ผมตรวจจากรายชื่อ 82 tools เองและเจอความไม่สม่ำเสมอชัดเจน [4]

กลุ่มที่ใช้คำกริยาปกติ ⇒ get, create, update, delete [4]

ads_get_ad_accounts ads_create_campaign
ads_get_creatives ads_update_entity
ads_catalog_get_catalogs ads_catalog_delete_product

กลุ่มที่ใช้คำกริยาต่างออกไป ⇒ read แทน get ⇒ ในโดเมนเดียวกัน [4]

ads_pixel_event_read ← ใช้ read
ads_pixel_parameter_read ← ใช้ read
แต่
ads_get_datasets ← โดเมนเดียวกันแต่ใช้ get
ads_get_custom_audience ← ใช้ get

และกลุ่มที่ไม่มีคำกริยาเลย ⇒ มี 5 tools [4]

ads_insights_advertiser_context
ads_insights_anomaly_signal
ads_insights_auction_ranking_benchmarks
ads_insights_industry_benchmark
ads_insights_performance_trend

⇒ สังเกตว่า ads_insights_* ทั้งห้าไม่มีคำกริยา ⇒ เป็นคำนามล้วน ⇒ ในขณะที่ tool ตัวอื่นบอกชัดว่า อ่าน หรือ เขียน [4]

⇒ ทำไมเรื่องนี้สำคัญกว่าที่คิด ⇒ เพราะหลักข้อสามบอกว่า คำอธิบายและชื่อคือสัญญาณที่ agent ใช้เลือก tool ⇒ ถ้าชื่อไม่บอกว่าอ่านหรือเขียน ⇒ agent ต้องเดา ⇒ และการเดาผิดใน server ที่แตะเงินจริงมีราคา [6]

⇒ และมีความไม่สม่ำเสมออีกชั้นที่ผมคิดว่าน่าสนใจ [4]

ads_account_get_activity_logs ← namespace account + verb get
ads_catalog_get_catalogs ← namespace catalog + verb get
ads_experiment_abtest_get_test ← namespace experiment + subtype + verb
ads_library_search ← namespace library + verb search

⇒ สังเกตว่า Meta ใช้ namespace ซ้อนได้ถึงสามชั้น (ads_experiment_abtest_get_test) แต่ก็มี tool ที่แบนสนิท (ads_get_datasets) [4]

⇒ ผมไม่คิดว่านี่คือความผิดพลาดร้ายแรง ⇒ แต่เมื่อเทียบกับหลักที่บอกให้ตั้งชื่อเป็นระบบ ⇒ นี่คือจุดที่หลักถูกประนีประนอมกับความต่อเนื่องของ API เดิม [4][6]

3) 🔴 เรื่องที่ผมยืนยันไม่ได้ และคิดว่าคุณควรถาม Meta

หลักข้อห้าคือให้ประกาศ readOnlyHint และ destructiveHint ⇒ และนี่คือจุดที่ผมต้องรายงานข้อจำกัดของตัวเอง [5][6]

⇒ ผมยืนยันไม่ได้ว่า server ของ Meta ประกาศ annotation หรือไม่ ⇒ เพราะ schema ของ tool จะเห็นได้หลังเชื่อมต่อ OAuth ซึ่งผมไม่มีสิทธิ์ [4]

⇒ และผมต้องแยกให้ชัดด้วย เพราะผมพบข้อมูลที่ชวนเข้าใจผิดง่ายมาก

งานตรวจอัตโนมัติที่ผมเปิดอ่าน พบว่า MCP server ฝั่งโฆษณาหลายตัว "ไม่มี annotation เลย" ⇒ เช่น server ชุมชนตัวหนึ่ง 17 จาก 17 tools ขาด hint อย่างน้อยหนึ่งตัว [8]

⇒ แต่ทุกตัวที่งานตรวจนี้ชี้คือ server ที่คนอื่นเขียน ⇒ ไม่ใช่ server ของ Meta [8]

⇒ และมีข้อความในงานตรวจนั้นที่ผมคิดว่าสำคัญกับทุกคนที่ทำ MCP [8]

"ไดเรกทอรีของ OpenAI ปฏิเสธ tool ที่ hint ใดหายไปหรือไม่เป็นค่าบูลีน ⇒ *สำหรับทุก tool ให้ตั้ง hint ทั้งสี่ (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) เป็น true/false ให้ตรงกับพฤติกรรมจริงของ handler*" [8]

⇒ แปลว่าการประกาศ annotation กลายเป็นข้อบังคับในทางปฏิบัติ ถ้าอยากให้ server ผ่านการรีวิวขึ้นไดเรกทอรี [8]

⇒ และผมพบงานวิจัยที่อธิบายว่าทำไม annotation จึงไม่ใช่คำตอบสุดท้าย [9]

"tool ที่โฆษณาตัวเองว่า readOnlyHint: true และ idempotentHint: true *กลับเขียนไฟล์ทั้งสองครั้งที่ถูกเรียก** ⇒ SDK ขนส่ง hint อย่างซื่อสัตย์ และ dispatch การเปลี่ยนแปลงอย่างซื่อสัตย์"* [9]

⇒ และงานวิจัยนั้นอ้างถึงสิ่งที่ spec เขียนไว้เอง [5][9]

"ไคลเอนต์ *ต้อง** ถือว่า tool annotation เชื่อถือไม่ได้ เว้นแต่จะมาจาก server ที่เชื่อถือได้"* [5]

⇒ นี่คือส่วนที่ทำให้ผมกลับมาชื่นชมการออกแบบ PAUSED ของ Meta มากขึ้น ⇒ Meta ไม่ได้พึ่ง annotation แต่ใช้กลไกที่บังคับได้จริง [4]

4) สาม tool ที่รวมกันแล้วเป็นความเสี่ยงคลาสสิก

ผมพบรูปแบบที่ตรงกับ "lethal trifecta" ที่ผมเขียนไว้ในบทความก่อน [6]

ads_get_help_article ⇒ อ่านเนื้อหาจากภายนอก (Help Center)
ads_library_search ⇒ อ่านเนื้อหาจากภายนอก (Ad Library)
ads_activate_entity ⇒ เปิดใช้โฆษณา ⇒ เริ่มใช้จ่ายเงิน

⇒ องค์ประกอบครบทั้งสาม คือ อ่านข้อมูลภายนอก + เข้าถึงข้อมูลส่วนตัว + ลงมือที่ย้อนกลับยาก [6][4]

⇒ และ Meta เองเขียนเตือนเรื่องนี้ไว้ในเอกสาร [4]

"ระวัง prompt injection เพราะเนื้อหาที่เชื่อถือไม่ได้ซึ่ง agent อ่านไป อาจพยายามชักจูงให้ทำสิ่งที่ไม่เหมาะสม" [4]

⇒ ผมคิดว่านี่คือจุดที่ต้องมองให้เป็นธรรม ⇒ Meta มีความเสี่ยงนี้ เพราะนี่เป็นธรรมชาติของงาน ⇒ แต่ การออกแบบ PAUSED คือคำตอบที่ถูก ⇒ เพราะต่อให้ agent ถูกชักจูงจนเรียก ads_activate_entity ก็ยังมีคนต้องกดเปิดอยู่ดี [4]

⇒ และนี่คือบทเรียนที่ผมคิดว่าสำคัญที่สุดของบทความนี้ ⇒ ถ้าคุณออกแบบ agent ให้แตะเงิน การแยก "เตรียม" ออกจาก "อนุมัติ" มีค่ามากกว่า annotation ทุกตัวรวมกัน [4][9]

5) ความไม่สมมาตรระหว่าง MCP กับ CLI

นี่คือจุดที่ผมคิดว่าน่ากังวลที่สุด และเป็นเรื่องที่แหล่งหลายแห่งรายงานตรงกัน [7][10]

ผ่าน MCP ⇒ entity ที่ agent สร้าง ลงเป็น PAUSED เสมอ
ผ่าน CLI ⇒ ทรัพยากรถูกสร้างเป็น ACTIVE โดยค่าเริ่มต้น
 ต้องส่ง --status PAUSED เองในโฟลว์อัตโนมัติ

⇒ และมีคำเตือนที่ตรงไปตรงมา [10]

"อย่าปล่อยให้งาน CLI ที่ไม่มีคนเฝ้าสร้าง campaign โดยไม่มี flag นั้น ⇒ *ไม่งั้นคุณอาจปล่อยการใช้จ่ายจริงออกไปโดยไม่มีใครรีวิว*" [10]

⇒ ผมคิดว่านี่คือตัวอย่างของหลักการที่ถูกนำไปใช้ไม่ครบ ⇒ หลักการเดียวกันถูกใช้กับทางหนึ่ง แต่ไม่ใช้อีกทางหนึ่ง ⇒ และทางที่ไม่ใช้คือทางที่ ไม่มีคนเฝ้า ซึ่งเป็นทางที่ต้องการมันมากที่สุด [10]

⇒ ผมยืนยันเรื่องนี้จากเอกสารทางการของ Meta ไม่ได้ ⇒ จึงรายงานตามที่แหล่งเหล่านี้ระบุ ⇒ ถ้าคุณใช้ Ads CLI ในงานอัตโนมัติ ควรตรวจ flag นี้เอง [10]

ห้า: สรุปเป็นตารางเดียว

ผมให้คะแนนตาม 6 หลัก แยกสอง server [1][2][4][6]

หลัก	Meta Social Technologies (11)	Ads MCP (82)
1. รวม tool	✅ ดีมาก ⇒ 1 tool ต่อโดเมน + actions	⚠️ ตรงข้าม ⇒ 82 tools, catalog 25
2. ชื่อเป็นระบบ	✅ ทั้ง 11 ใช้ devtools_	⚠️ ปนสามแบบ · มี 5 tools ไม่มีคำกริยา
3. สัญญาณอ่านออก	✅ ระบุ Actions ต่อ tool	✅ เอกสารบอกข้อจำกัดครบ ดีมาก
4. เพดานโทเคน	✅ 11 tools เบามาก	⚠️ 82 tools ⇒ ตัวเลขวัด 55,000 โทเคนต่อเซสชัน
5. Annotation	⚠️ ยืนยันไม่ได้	⚠️ ยืนยันไม่ได้ (แต่ออกแบบ PAUSED ชดเชย)
6. ประเมินได้	⚠️ ยังไม่มีข้อมูล	✅ activity log + field context

⇒ และมีเกณฑ์ที่อยู่นอก 6 หลัก ซึ่งทั้งสองทำได้ดีเท่ากัน [1][4]

⇒ คือการยืนยันตัวตนด้วย OAuth และ scope แยกชั้น ⇒ ซึ่งเป็นฐานที่ผมคิดว่าสำคัญก่อนเรื่องอื่นทั้งหมด [1]

หก: แล้ว Meta ควรทำอะไรต่อ

หนึ่ง ⇒ ลด catalog ให้เหลือไม่กี่ tools ที่ใช้ operation เป็นพารามิเตอร์ ⇒ เพราะ 25 tools จาก 82 คือจุดที่หลักข้อหนึ่งถูกทิ้งมากที่สุด และมีคนเสนอทางนี้ไว้แล้ว [4][7]

สอง ⇒ แก้ชื่อ ads_pixel_*_read ให้เป็น get และเติมคำกริยาให้ ads_insights_* ⇒ เพื่อให้ agent แยกอ่านกับเขียนได้จากชื่อ [4][6]

สาม ⇒ ประกาศ annotation ให้ครบทั้งสี่ตัว ⇒ เพราะไดเรกทอรีของ OpenAI ปฏิเสธ tool ที่ hint หายไป และเพราะนี่เป็นข้อมูลที่ client ใช้ตัดสินใจว่า จะถามยืนยันผู้ใช้หรือไม่ [8]

⇒ แต่ผมอยากปิดท้ายด้วยข้อเสนอที่ตรงข้าม ⇒ อย่าเพิ่งไปแก้ catalog ก่อนนำหลัก PAUSED ไปใช้กับ CLI ⇒ เพราะการแยก "เตรียม" ออกจาก "อนุมัติ" แก้ความเสี่ยงที่แพงกว่าการประหยัดโทเคน [4][10]

ข้อควรระวัง

หนึ่ง บทความนี้วิเคราะห์จาก เอกสารทางการของ Meta · เอกสารอิสระที่ไล่ทีละ tool · และงานตรวจของบุคคลที่สาม ⇒ ผมไม่ได้เชื่อมต่อ server ของ Meta และไม่ได้ทดลองเรียก tool ใดเลย [1][4]

สอง ผมยืนยันไม่ได้ว่า Meta ประกาศ annotation หรือไม่ เพราะ schema ของ tool ต้องเข้าเฉพาะหลังยืนยันตัวตน ⇒ ผมจึงไม่สรุปว่ามีหรือไม่มี และไม่นับเป็นข้อบกพร่อง ⇒ นี่คือข้อที่คุณควรถาม Meta โดยตรง [4]

สาม เอกสาร 82 tools เป็นงานของบุคคลที่สาม ไม่ใช่ของ Meta ⇒ ผู้จัดทำระบุว่าเป็นเอกสารอิสระและไม่มีความเกี่ยวข้องกับ Meta ⇒ ตัวเลข 82 และการจัดหมวดทั้งหมดมาจากเอกสารนั้น ⇒ จำนวน 29 tools มาจากบทความบุคคลที่สามที่รายงานตอนเปิด beta ไม่ใช่จากเอกสารทางการ ⇒ ผมตรวจหน้า overview ทางการ [2] แล้ว ไม่พบตัวเลขจำนวน tool รวมในหน้านั้น (แต่หน้านั้นอ้างถึงหน้า Available tools ซึ่งเป็นรายการ tool ฉบับเต็ม ที่ผมเปิดไม่ได้ในรอบนี้)[2][7] ⇒ ส่วนเอกสารอิสระ [4] ระบุเพียงว่าตัว server เปิด beta 29 เมษายน 2026 ซึ่งเป็นวันที่ ไม่ใช่จำนวน tool ⇒ ตัวเลข 82 ที่ผมใช้จึงสะท้อนการขยายตัวของ tool ในภายหลัง ไม่ได้ขัดกับ 29

สี่ ตัวเลข 55,000 โทเคนต่อ 58 tools เป็นการวัดของบริษัทที่ขายเครื่องมือโฆษณาเอง ⇒ มีส่วนได้ส่วนเสีย และเป็นการวัดโปรไฟล์ที่รวม server อื่น ⇒ ผมรายงานตามที่เขาระบุ ไม่ได้ยืนยัน [7]

ห้า เรื่อง CLI สร้าง ACTIVE โดยค่าเริ่มต้น ผมยืนยันจากเอกสารทางการของ Meta ไม่ได้ ⇒ รายงานตามแหล่งที่ระบุตรงกัน ⇒ ถ้าคุณใช้ Ads CLI ในงานอัตโนมัติ ควรตรวจ flag เองก่อน [10]

หก การอ้างอิงงานตรวจ annotation ทั้งสองชิ้นชี้ไปที่ server ชุมชน ไม่ใช่ server ของ Meta ⇒ ผมใช้เป็นบริบทของมาตรฐานอุตสาหกรรม ไม่ใช่เป็นข้อวิจารณ์ Meta [8][9]

เจ็ด ข้อความในเครื่องหมายคำพูดที่ยกมาจากแหล่งภาษาอังกฤษเป็นคำแปลของผม ไม่ใช่สำเนาต้นฉบับ ⇒ ผมคงศัพท์เทคนิคไว้เป็นภาษาอังกฤษ (PAUSED, scope, annotation, readOnlyHint, operation) เพื่อให้ตรวจเทียบกับต้นฉบับได้เอง

แปด ผมทำงานบนระบบที่ใช้โมเดล AI และเขียนบทความนี้ด้วยความช่วยเหลือของ AI

บทความในซีรีส์นี้

• ชั้นออกแบบ ⇒ MCP tool design: หลักออกแบบ tool ให้ agent เลือกถูกและไม่ทำอันตราย
• ชั้นทำให้พร้อมใช้จริง ⇒ สร้าง MCP server ให้พร้อม production: 7 เรื่องที่ tutorial ไม่บอก ⇒ อยู่ในซีรีส์เดียวกัน
• ชั้นดูของจริง ⇒ MCP server ที่คนใช้จริง: วัด 11 ตัว แล้วพบว่าโทเคนเป็นข้อจำกัดการออกแบบ ⇒ อยู่ในซีรีส์เดียวกัน

แหล่งอ้างอิง

[1] "Meta Social Technologies MCP" เอกสารทางการ ระบุว่าเคยชื่อ Meta Developer Tools MCP และเปลี่ยนชื่อเมื่อ 18 ส.ค. 2026 · 11 tools · สอง scope · หมายเหตุเรื่อง test payload (ปรับปรุง 8 ก.ย. 2026 / ค.ศ. 2026), Meta for Developers, https://developers.facebook.com/documentation/mcp/devtools-mcp

[2] "Ads MCP Server" เอกสารทางการ ระบุ 7 หมวดความสามารถ รวม activity logs และ catalog (ค.ศ. 2026), Meta for Developers, https://developers.facebook.com/documentation/ads-commerce/ads-ai-connectors/ads-mcp-server/ads-mcp-server-overview

[3] "Connect AI Agents to Meta with MCP" เอกสารทางการ ระบุรายชื่อ MCP server ของ Meta (ค.ศ. 2026), Meta for Developers, https://developers.facebook.com/documentation/mcp

[4] Caliman, T., "Meta Ads MCP: Complete Technical Reference" เอกสารอิสระไล่ทีละ 82 tools พร้อมข้อจำกัดและค่าเริ่มต้น (ก.ค. 2026 / ค.ศ. 2026), AI PRO Revolution, https://raw.githubusercontent.com/thiagocaliman/meta-ads-mcp-reference/master/README.en.md

[5] "Tools" ข้อกำหนดเรื่อง tool annotation ระบุว่าไคลเอนต์ต้องถือว่า annotation เชื่อถือไม่ได้จาก server ที่ไม่น่าเชื่อถือ, MCP specification รุ่น 2026-07-28, https://modelcontextprotocol.io/specification/2026-07-28/server/tools

[6] "Writing effective tools for agents" หลักออกแบบ tool ของ Anthropic (ค.ศ. 2026), https://www.anthropic.com/engineering/writing-tools-for-agents

[7] "Meta Ads MCP and CLI: Inside Meta's Official AI Connectors" บทวิเคราะห์ รวมการวัด 55,000 โทเคนต่อ 58 tools และคำแนะนำให้ลด scope (ค.ศ. 2026), MCP.directory, https://mcp.directory/blog/meta-ads-cli-mcp

[8] "Tool annotations" การทดสอบและเกณฑ์ annotation รวมข้อกำหนดว่าห้าม missing hint, Sunpeak (ก.ค. 2026 / ค.ศ. 2026), https://sunpeak.ai/blogs/testing-mcp-tool-annotations/

[9] "MCP's readOnlyHint Is Not a Permission Boundary" การทดลองที่พบว่า tool ซึ่งประกาศ readOnlyHint: true ยังเขียนไฟล์ได้ (31 ส.ค. 2026 / ค.ศ. 2026), AccessAllGPT Research, https://accessallgpt.com/research/mcp-tool-annotations-permission-boundary

[10] "Meta Ads MCP Setup Guide" ระบุความไม่สมมาตรระหว่าง MCP ที่สร้างแบบ PAUSED กับ CLI ที่สร้างแบบ ACTIVE (ค.ศ. 2026), Soku, https://soku.ai/blog/meta-ads-mcp-setup-guide
[11] "Announcing Meta Social Technologies MCP" โพสต์ประกาศทางการ ลงวันที่ 30 มิ.ย. 2026 พร้อมหมายเหตุการเปลี่ยนชื่อ 18 ส.ค. 2026 (ระบุว่า previously known as Developer Tools MCP), Meta for Developers (ค.ศ. 2026), https://developers.facebook.com/blog/post/2026/06/30/developer-tools-mcp/