discover-portal-apis
Discover APIs published in an API Experience Hub portal as a portal consumer. Use when an end user needs to browse the catalog, search assets by keyword or filter, open an API's detail page, read its terms and conditions, or fetch rendered documentation pages and resources.
72
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong description that clearly defines the skill's scope as an API Experience Hub portal consumer tool. It lists specific actions, includes natural trigger terms, explicitly states both what the skill does and when to use it, and occupies a distinct niche unlikely to conflict with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: browse the catalog, search assets by keyword or filter, open an API's detail page, read terms and conditions, fetch rendered documentation pages and resources. | 3 / 3 |
Completeness | Clearly answers both what ('Discover APIs published in an API Experience Hub portal') and when ('Use when an end user needs to browse the catalog, search assets by keyword or filter, open an API's detail page, read its terms and conditions, or fetch rendered documentation pages and resources'). | 3 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'API', 'portal', 'catalog', 'search', 'keyword', 'filter', 'documentation', 'terms and conditions', 'API Experience Hub'. These cover a good range of terms a portal consumer would use. | 3 / 3 |
Distinctiveness Conflict Risk | Targets a very specific niche — API Experience Hub portal consumer actions — with distinct triggers like 'portal', 'catalog', 'API detail page', and 'terms and conditions' that are unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, actionable skill with clear step sequencing and concrete API call specifications. Its main weakness is verbosity from repeated input parameter definitions across six steps — the same five parameters are fully redefined each time, inflating the token cost significantly. The workflow logic and cross-references to related skills are strong.
Suggestions
Define common input parameters (targetOrganizationId, targetPortalId, groupId, assetId, minorVersion) once at the top and reference them in subsequent steps to eliminate ~60% of the repetitive YAML.
Remove the 'What you'll need' bullet lists before each YAML block — the YAML inputs section already documents what's needed, making these redundant.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is moderately efficient but has significant repetition — the same five input parameters (targetOrganizationId, targetPortalId, groupId, assetId, minorVersion) are fully redefined with descriptions in every step. This boilerplate could be factored out. The 'What you'll need' sections and some framing text ('What you'll build', 'What You've Built') add modest padding. | 2 / 3 |
Actionability | Each step provides a concrete, structured YAML block with the exact API URN, operationId, input specifications (including sourcing from variables vs user-provided), output paths, and examples. This is copy-paste ready for the tool-calling framework it targets. | 3 / 3 |
Workflow Clarity | The six steps are clearly sequenced from broad browsing to specific resource fetching, with explicit data dependencies between steps (e.g., groupId/assetId from Step 1/2 feeds into Step 3+). The completion checklist provides validation. This is a read-only discovery workflow with no destructive operations, so the level of validation is appropriate. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and cross-references to related skills (request-api-access, manage-portal-applications). However, the document is quite long (~180 lines) with highly repetitive YAML blocks that could be condensed or split into a reference file. No bundle files exist to offload the repetitive input definitions. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- mulesoft/mulesoft-dx
- Commit
32e2b58
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.