"Agent-Ready"IsNottheSameas"HasanAPI"

Meta ships an official Ads MCP server equipped with 95 separate tools. It has functions for fetching campaigns, reading ad sets, updating spend limits, and inspecting pixel events.

It cannot create a lead-form ad.

Not “it’s buggy.” Not “it requires complex parameters.” It cannot do it by design: the OAuth connection hardcoded into the connector never requests pages_manage_ads—the specific permission Meta’s own API requires to bind a lead form to a creative. When your agent invokes the tool, the server returns an error message that politely instructs the robot to open a web browser and finish the job by hand in Ads Manager.

It took forty-eight hours and five identical execution failures to accept that the front door was permanently locked.

What the marketing said:  "95 Tools for Full AI Automation"
What the OAuth scope had: read_insights, ads_read, ads_management
What lead ads require:   pages_manage_ads (Excluded by design)
Result:                  HTTP 403 Forbidden -> "Complete in Ads Manager"

The Catalog Is a Liability Fence

In the current wave of agent hype, enterprise software vendors are racing to stamp their products as “Agent-Ready.” They package their REST endpoints into Model Context Protocol (MCP) servers, slap on a manifest with dozens of JSON schemas, and publish press releases declaring autonomous operations.

Do not trust tool counts.

An MCP catalog is not a measure of what the system can do. It is a strict scope decision reflecting what the vendor’s legal and compliance teams are willing to let an autonomous process touch.

Lead generation ads collect consumer PII—names, phone numbers, email addresses. Handling PII increases compliance exposure under GDPR and CCPA. So Meta’s connector team simply drew a perimeter line right outside lead forms. The 95 tools give the appearance of comprehensive autonomy, but the moment you cross the line into customer data capture, the agent hits a brick wall.

“Agent-ready” isn’t defined by the number of endpoints wrapped in tool declarations. It is defined by where the refusals live.

The Four Invisible Walls

When we tried to push through the official connector, the build failed across four successive layers. Each layer hid behind the previous one, and none were documented together:

1. The Scope Omission: The MCP server’s fixed OAuth application lacked pages_manage_ads. Toggling permissions inside Meta Business Settings did nothing because the client app definition itself was locked upstream.
2. The Defaulting Trap: Setting destination_type: ON_AD required an explicit bid_strategy that the MCP’s default schema omitted, causing schema validation rejections from the underlying Graph API.
3. App Mode Rejection: The backing developer app couldn’t execute writes against real ad accounts while set to Development Mode, even for the admin who created it.
4. The macOS Token Truncation: When generating a long-lived System User token to bypass the UI, pasting the 200-character credential into an interactive /usr/bin/security add-generic-password prompt silently truncated the string at character 128.

Four separate systems, four silent failure modes, zero unified error logs.

The Unofficial Escape Hatch

After two days of wrestling the official MCP wrapper, we threw it away.

We provisioned a direct Meta System User token inside Business Manager, granted explicit pages_manage_ads and ads_management permissions, and handed the agent a simple Python script running standard requests calls against Graph API v19.0.

The result? The agent built three ad sets, configured audiences, attached creative assets, and staged three campaigns in one single execution pass. First try.

The raw, unbranded HTTP endpoint was ten times more agent-ready than the official “AI connector.”

The Intermediary Tax

During our troubleshooting, we encountered another modern trap: third-party “agent skill” repositories claiming to solve vendor MCP gaps.

When we audited the source code of a popular lead-gen skill, the reality was worse than the broken MCP: the skill was just a wrapper for a proprietary cloud proxy. To use it, you had to OAuth your corporate ad account through a startup’s cloud gateway.

The vendor’s permission gap was being resold as a monthly subscription, routing customer lead data through an unvetted third-party middleman. That isn’t an integration; that’s an unforced security breach.

How to Audit an “Agent-Ready” Connector

Before building automated workflows on any vendor’s MCP server, run this checklist:

• Audit the Scope Manifest First: Ignore the tool list. Check the OAuth scope array requested in the authentication flow. If the scopes don’t cover your core business objects, the tools are paperweights.
• Trigger the Irreversible Action in Week One: Don’t waste time testing read operations (list_campaigns, get_metrics). Attempt the highest-value write operation on day one in a test sandbox. That is where the hidden constraints live.
• Inspect the Error Strings: When an agent tool fails, does it output structured error codes with recovery paths, or does it tell the user to visit a web GUI? An error that demands a browser visit is proof of a human-gated product.

Honest Caveats

Writing your own raw API calls instead of using vendor-provided MCP connectors comes with clear trade-offs:

• Maintenance Burden: When a vendor deprecates Graph API v19.0, your custom script breaks. Official connectors eventually get updated upstream, even if they arrive months late.
• Credential Surface: Storing a direct System User token in the local macOS keychain bypasses the vendor’s OAuth consent screen, which means you bear the sole responsibility for secret rotation and permission auditing.

Authority comes from knowing how the underlying machinery works, not from trusting a vendor’s catalog.