PCFHub

Everything about one control by its slug: what it does, its control type, license and repository, the current release's properties, and download links for its solutions. Use it once search or list_components has given you a slug; use get_doc_page for installation and configuration instructions, which this does not return. An unknown slug, or a version the control never released, returns an error naming the tool to call instead. include_versions and include_related each cost an extra query, so leave them off unless you need the release history or similar controls.

Read one documentation section of a control as Markdown — installation steps, canvas or model-driven configuration, examples, limitations. Use list_doc_sections first for the sections that control publishes; use get_component instead for the structured property reference. Passing a version returns the documentation pinned to that release rather than the current page. A section the control does not document returns an error pointing at list_doc_sections, and the Markdown comes back without the frontmatter the site keeps.

Browse the PCFHub catalog by category, tag, author, control type, host or text, paged and sorted. Use it to enumerate or narrow the catalog; use search for a plain-language question about what a control should do, and get_component for one control in full. Filters take slugs, which list_taxonomy supplies. Nothing here fails on bad input: an unrecognised sort falls back to the default, and filters matching nothing return an empty page — so read `total` and `sort` from the result rather than assuming the filters applied.

The documentation sections one control publishes — overview, installation, canvas, model_driven, examples, limitations and so on — each with its title and URL. Use it before get_doc_page to learn which sections that control actually has; it returns no page content, and get_component covers the property reference. A control with no documentation and a slug that does not exist return the same error on purpose, so fall back to search rather than concluding the slug is wrong.

The most recent releases across every control on PCFHub, newest first: which control, which version, whether it is a prerelease, and when it shipped. Use it for what has changed hub-wide; for one control's own history call get_component with include_versions instead. Bounded by limit, at most 50, and not paged — there is no cursor, so it cannot walk back beyond the newest 50.

The vocabulary list_components filters by: the category tree, the tags in use, the authors with a published control, or the hosts a control can run in, each with its slug and a count. Use it to turn a name a person used into a slug; it returns no controls, so pass the slug to list_components to see them. Not paged — categories come back as a full tree and authors as a full list, while tags are capped at the 500 most used.

Full-text search across every published PCF control and its documentation, ranked by relevance. Use it when you know what a control should do but not what it is called; use list_components instead to filter by category, tag, author or control type, and get_component when you already have a slug. Returns control and documentation hits, each with a snippet and a URL. A query that matches nothing is an empty result rather than an error, and a misspelling may be answered with results for a corrected spelling, which the result states.

Check a pcfhub.json against the rules PCFHub applies when it publishes a control: the schema version, the control block (namespace, constructor, type and framework), the demo's fidelity, bundle and presets, the media files it declares, and the release artifacts it expects to find. Use it while writing or reviewing that file, before a release is tagged. An invalid manifest is an ordinary result — valid false, with errors that block publishing and warnings that do not, each carrying the JSON pointer it applies to — so read the result rather than retrying. Only an empty, unreadable or oversized manifest (over 64 KB) is an error.