Exchange Discover

API Discovery from Functional Specification

You are helping a MuleSoft architect find existing APIs in Anypoint Exchange that match or can satisfy a functional specification document. Follow every step below precisely and in order.

Step 1: Get the Anypoint bearer token

Run:

echo $ANYPOINT_TOKEN

If the output is empty, ask the user:

"Please provide your Anypoint Platform bearer token. You can get it from your active browser session at anypoint.mulesoft.com (Developer Tools → Network tab → any request → Authorization header)."

Store the token value as TOKEN for all subsequent curl calls.

Step 2: Ingest the specification document

The document path is the argument passed to this skill. Determine the file type:

• PDF — use the Read tool directly on the path
• DOCX — run: pandoc -f docx -t plain "<path>" (if pandoc is not in PATH, ask the user for the full path to their pandoc binary)
• TXT / MD — use the Read tool directly

If the file cannot be read, tell the user and stop.

Step 3: Learn the organization's naming conventions

Before analyzing the spec, ask the user:

"Does your organization follow a naming convention for Mulesoft APIs? For example:

• Domain prefixes (e.g. fin- for finance, snd- for sales, hr- for HR)
• Layer suffixes (e.g. -sys-api for system layer, -proc-api for process layer, -exp-api for experience layer)
• Platform-specific patterns (e.g. *-bat for batch apps, *-nala-* for a specific region/instance)

Describe your conventions briefly, or reply 'standard' if you use default Anypoint/MuleSoft naming."

Store whatever the user provides as NAMING_CONVENTIONS — you will apply these when deriving search terms in Step 4.

If the user replies 'standard' or provides no conventions, use only generic architectural patterns (layer suffixes, platform names, system names) as search terms.

Step 4: Analyze the integration pattern and derive search terms

Carefully read the full document and identify the integration architecture, not the business vocabulary. Present this to the user for confirmation before searching.

Extract and present:

How to derive search terms

Search terms must reflect the technical role and platform layer of the API, not business domain vocabulary. Apply the user's naming conventions on top of these rules:

Generic architectural patterns:

Apply naming conventions: If the user described domain prefixes (e.g. fin- for finance), prepend them to the architectural role. For example:

• Finance + SFTP batch pickup → fin bat, fin nala bat
• Finance + posts to S/4HANA → fin s4h sys, fin erp sys

Critical rules:

• Do NOT search business vocabulary (e.g. "invoice", "delivery", "freight") — internal APIs are rarely named this way
• Always run 2–3 search variants per architectural role
• Read the description of every candidate before including it — names can be misleading (e.g. "Reporting" API may write data into the ERP, not just read it)
• -sys-api = system layer (direct target system wrapper); -proc-api = process/orchestration layer; -exp-api = experience layer. Match the suffix to the architectural role you are looking for

Ask the user: "Does this integration pattern look accurate? Reply 'yes' to proceed or correct anything I've missed."

Step 5: Search Anypoint Exchange

For each technical search term, run:

curl -s "https://anypoint.mulesoft.com/exchange/api/v2/assets?search=<TERM>&limit=25" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json"

Do NOT filter by organizationId — organizations often have assets spread across multiple Exchange business groups and filtering to one will miss them.

If the API returns HTTP 401, tell the user their token has expired and ask for a new one.

Collect all results. Deduplicate by assetId — keep the highest version of each. For every promising candidate, fetch its description and read it before classifying.

Step 6: Classify each result

For every unique asset found, assess it against the spec and assign one classification:

Use the asset's name, description, tags, and type fields to make this assessment. Do not classify based on name alone.

Step 7: Present the discovery report

API Discovery Report

Specification: <filename> Searched: <number> terms | <number> unique assets found

Spec Summary

2–3 sentences describing what was analyzed.

Implements — Direct Match

APIs that fully satisfy this specification.

Reusable — Dependency / Composition

APIs providing data or operations the new API would consume.

Partial Match — Extend or Subset

APIs covering part of the requirements.

Recommendation

Based on the findings, recommend one of:

• Reuse as-is — an existing API already implements this spec; link to it
• Extend existing — name the API and describe what needs to be added
• Compose — name the APIs to combine and how
• Build new — no suitable match found; brief rationale

Exchange asset links follow this pattern — use the groupId from the search result as the org ID: https://anypoint.mulesoft.com/exchange/<groupId>/<assetId>/<version>/

Error handling