PCFHub
Server Details
Find Power Apps PCF controls, read their docs, and validate pcfhub.json manifests.
- Status
- Healthy
- Uptime
- 97.4% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 8 tools
Each tool targets a distinct resource or action: search vs list_components separates full-text lookup from faceted browsing, get_component vs get_doc_page separates structured metadata from Markdown documentation, and list_taxonomy/list_releases cover vocabulary and hub-wide feeds. The descriptions explicitly cross-reference when to use each tool, so there is little risk of misselection.
Names are all lowercase snake_case with clear action verbs, mostly matching a verb_noun pattern like list_components, get_component, and validate_manifest. The only minor deviation is the bare verb `search` instead of something like search_components, but the overall style is highly consistent.
Eight tools is a well-scoped size for a catalog and registry server covering browsing, searching, retrieval, documentation, releases, taxonomy, and manifest validation. Every tool has a clear role, and none feel redundant or excessive.
The tool set covers the full read-side workflow of PCFHub: discover vocabulary, browse and filter, full-text search, retrieve component details, read documentation, inspect releases, and validate manifests before publishing. There are no obvious dead ends; the deliberate dependencies between list_doc_sections/get_doc_page and list_components/get_component are clearly documented.
Available Tools
8 toolsget_componentGet a PCF controlARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The control's slug, e.g. "pcf-tag-list". | |
| version | No | A specific release. Defaults to the latest stable one. | |
| include_related | No | Also return similar controls. Costs an extra query; leave off unless needed. | |
| include_versions | No | Also return every release. Costs an extra query; leave off unless needed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Absolute URL of the control's page, for citing. |
| name | Yes | |
| slug | Yes | |
| tags | No | |
| tier | No | free, or a paid tier. |
| hosts | Yes | Where this control runs: canvas apps, model-driven apps, or both. |
| author | No | |
| related | No | Empty unless include_related was set. |
| tagline | No | |
| category | No | |
| versions | No | Empty unless include_versions was set. |
| downloads | Yes | Empty where the control has no published release. |
| summaryMd | No | The author's longer description, as Markdown. |
| isArchived | Yes | True when the control is no longer maintained. |
| supportUrl | No | Where to report a problem with the control. |
| controlType | Yes | |
| homepageUrl | No | |
| licenseSpdx | No | SPDX identifier, e.g. "MIT". |
| publishedAt | No | ISO 8601. |
| downloadCount | No | |
| repositoryUrl | No | |
| currentVersion | No | The release described, or null where nothing has been published yet. |
| controlTypeDescription | No | What that control type means, in a sentence. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds meaningful behavior beyond that: unknown slugs or unreleased versions produce an error that names the tool to call instead, and include_versions/include_related incur extra query costs. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all information-dense and front-loaded: the core purpose comes first, sibling routing second, error behavior third, and parameter cost guidance last. There is no filler or repetition beyond what the schema needs reinforced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with an output schema, the description covers what is returned, when to use it, when not to use it, what happens on invalid input, and the cost trade-offs of optional parameters. Nothing an agent needs to select or invoke the tool correctly is left out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both optional parameters already carry descriptions including the extra-query warning. The description reinforces those warnings and ties include_versions to 'release history' and include_related to 'similar controls,' but it does not substantially expand on what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and resource ('one control by its slug'), then enumerates what is returned: behavior, control type, license, repository, current release properties, and solution download links. It distinguishes itself from search/list_components and get_doc_page, so an agent can disambiguate immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit sequencing guidance: use it only after search or list_components provides a slug. It also names the alternative for installation/configuration instructions (get_doc_page) and clarifies that this tool intentionally does not return them, plus warns about optional parameters costing extra queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_doc_pageRead a documentation pageARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The control's slug, e.g. "pcf-tag-list". | |
| section | Yes | Which section to read. | |
| version | No | Documentation pinned to a specific release. Defaults to the current documentation. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Absolute URL of the page, for citing. |
| title | Yes | |
| section | Yes | |
| version | No | The release this documentation describes. |
| contentMd | Yes | The page as Markdown, with its frontmatter removed. Empty when the page has no content. |
| sourceUrl | No | The file in the author's repository this was compiled from. |
| updatedAt | No | ISO 8601. |
| description | No | |
| componentName | Yes | |
| componentSlug | Yes | |
| isVersionPinned | Yes | True when a version was asked for, rather than the current documentation being returned. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds useful behavioral context: version pinning behavior, error behavior for undocumented sections (points at list_doc_sections), and the fact that Markdown comes back without frontmatter. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: what it returns, how to discover sections, when to use the sibling, version behavior, and error behavior. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need no explanation. The description covers discovery flow, sibling routing, version behavior, and error handling. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context about the version parameter (pins to a release) and the section parameter (which sections exist), but doesn't add much beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a specific resource ('one documentation section of a control'), and the output format ('as Markdown'). It also names the sibling tools it is not (list_doc_sections, get_component), so an agent can distinguish it from alternatives without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use list_doc_sections first to discover sections, and to use get_component instead for the structured property reference. It also explains the version parameter's behavior. This is clear when-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_componentsList PCF controlsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Where the control has to run. A control supporting both hosts matches either. | |
| page | No | Defaults to 1. | |
| sort | No | Defaults to relevance when there is a query, newest otherwise. | |
| tags | No | Tag slugs, from list_taxonomy. A control must carry every tag given. | |
| query | No | Words to match against names, taglines and descriptions. | |
| author | No | An author slug, from list_taxonomy. | |
| category | No | A category slug, from list_taxonomy. | |
| per_page | No | Defaults to 24; at most 48. | |
| control_type | No | field binds one column on a form; dataset renders a view; virtual is a React control; grid_customizer changes how an editable grid renders cells. |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | The page returned. |
| sort | Yes | The sort actually applied, which is the default when none was given or the one given was not recognised. |
| total | Yes | Controls matching the filters, across every page. |
| perPage | Yes | |
| lastPage | Yes | The highest page number for these filters. |
| components | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavior beyond that: unrecognized sorts fall back to defaults, unmatched filters return an empty page, and the caller should read `total` and `sort` rather than assuming filters applied. This is useful non-obvious runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: what it does, when to use alternatives, filter input requirements, and bad-input behavior. It is front-loaded with the core purpose and contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter read-only list tool with an output schema present, the description covers enumeration, narrowing, sorting/paging, taxonomy slug provenance, and failure behavior. Nothing an agent needs to call or interpret this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter and its defaults. The description adds the general rule that filters take slugs from list_taxonomy, which is useful, but most of that is also present in the schema descriptions. A baseline 3 is appropriate because the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('browse') and names the exact resource (PCFHub catalog) plus the explicit facets it can filter by. It also distinguishes itself from search and get_component, so an agent can tell siblings apart without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('enumerate or narrow the catalog') and when to use alternatives ('search for a plain-language question', 'get_component for one control in full'). It also tells the agent that filters require slugs supplied by list_taxonomy, which is a concrete prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_doc_sectionsList a control's documentationARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The control's slug, e.g. "pcf-tag-list". |
Output Schema
| Name | Required | Description |
|---|---|---|
| slug | Yes | The control the sections belong to. |
| sections | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context beyond those: it returns no page content and it deliberately returns the same error for a documented control with no sections and a non-existent slug. This error-handling disclosure is valuable for an agent deciding whether to trust the slug or fall back to search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct job: what the tool returns, when to use it versus siblings, and how to interpret its error behavior. No filler or repetition, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only list tool with an output schema, the description covers purpose, return scope, exclusions, sibling routing, and an important error ambiguity. An agent has everything needed to call this correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'slug' parameter, including an example, so the description does not need to add much. The description reinforces that the slug identifies the control, but it does not add substantially new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: listing the documentation sections a control publishes, with examples of section types and their title/URL. It explicitly contrasts itself with get_doc_page and get_component, so an agent can distinguish it from siblings without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'Use it before get_doc_page to learn which sections that control actually has.' It also states what it does not return, points to get_component for the property reference, and advises falling back to search when the error is ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_releasesList recent releasesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many releases. Defaults to 20. |
Output Schema
| Name | Required | Description |
|---|---|---|
| releases | Yes | Newest first. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds key behavioral facts: it is not paged, has no cursor, and cannot retrieve more than the newest 50. This is valuable context that would otherwise be unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by usage guidance and limitation. Every clause earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description explains the returned fields, the ordering, the limit behavior, and the alternative tool. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the limit parameter is fully described with min, max, and default. The description only repeats the bound ('at most 50') and does not add new semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact verb (list) and resource (recent releases across every control on PCFHub), specifies ordering (newest first) and the fields returned. It also distinguishes itself from the sibling tool get_component, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('what has changed hub-wide') and directs to get_component with include_versions for a single control's history. Also discloses the non-paged, bounded nature, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_taxonomyList categories, tags, authors or hostsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which list to return. |
Output Schema
| Name | Required | Description |
|---|---|---|
| kind | Yes | Which list this is. |
| items | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and idempotentHint, and the description adds meaningful behavioral detail: results are not paged, categories are returned as a full tree, authors as a full list, and tags are capped at 500. This goes beyond the annotations and helps the agent set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with dense, relevant content and no filler. The opening phrase 'The vocabulary list_components filters by' is slightly awkward, but the description is otherwise front-loaded and economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single enum parameter, an output schema, and read-only/idempotent annotations, the description covers all necessary usage context: what the list contains, how to use the result, and pagination limits. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single kind parameter, and the description adds semantics for each enum value: category tree, tags in use, authors with a published control, and hosts a control can run in, plus the slug/count shape. This meaningfully enhances the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: listing taxonomy vocabularies (categories, tags, authors, hosts) and adds that each entry has a slug and count. It differentiates from sibling list_components by explicitly stating this tool returns no controls and that the slug should be passed to list_components to see the controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: converting a human-supplied name into a slug. It also states the relationship to list_components, telling the agent to pass the slug there to see controls, which is explicit routing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch PCFHubARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return. Defaults to 10. | |
| query | Yes | What to look for, in plain words: "barcode scanner", "kanban", "date range". |
Output Schema
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| query | Yes | The query as it was searched. |
| total | Yes | How many results matched, which may be more than were returned. |
| correctedQuery | No | Set only when nothing matched the query and these are results for a corrected spelling of it. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, and the description adds substantial behavioral context beyond that: it returns both control and documentation hits with snippets and URLs, treats no-match as an empty result (not an error), and discloses that misspellings may yield corrected results that are labeled. This is valuable context that the annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense, front-loading the core purpose, then usage guidance, then return details and edge cases. Every sentence adds value; there is no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with an output schema, the description covers essential context: scope, ranking, return content (snippets and URLs), and unusual behaviors (empty results, misspelling). The presence of an output schema covers return structure, and the description fills in the behavioral gaps, making it complete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (query and limit) with clear descriptions. The tool description does not add additional parameter-level semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does a full-text search across every published PCF control and its documentation, ranked by relevance. It names specific sibling tools and the conditions under which they should be used instead, making the purpose unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('when you know what a control should do but not what it is called') and provides direct alternatives: list_components for filtering by category/tag/author/type, and get_component when you have a slug. It also notes edge-case behavior (empty result vs. error, misspelling correction) which guides expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_manifestValidate a pcfhub.jsonARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest | Yes | The full contents of pcfhub.json, as JSON text. |
Output Schema
| Name | Required | Description |
|---|---|---|
| valid | Yes | False when there is at least one error. Warnings alone leave it true. |
| errors | Yes | Must be fixed; publishing refuses the manifest until they are. |
| warnings | Yes | Do not block publishing, but reach the author through their own CI. |
| schemaVersion | Yes | The manifest schema version it was checked against. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and idempotent hints, so the description doesn't need to repeat them. It adds substantial behavioral context: that an invalid manifest is an ordinary result (valid false), errors block publishing while warnings do not, each carries a JSON pointer, and only empty, unreadable, or oversized (>64 KB) manifests are errors. This goes beyond annotations and is critical for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first front-loads the purpose and scope, the second covers usage, result semantics, and error conditions. There is no redundancy, and every clause adds value. It is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (validates many aspects), but the description enumerates all validation areas and explains the result behavior clearly. Since an output schema exists, it doesn't need to detail the return structure; it covers everything an agent needs to invoke it correctly, including edge cases (oversized manifest).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'manifest' (full contents as JSON text), so the baseline is 3. The description adds an important constraint not in the schema: manifests over 64 KB are treated as errors, which helps the agent set expectations for valid input. This extra information raises the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and clearly identifies the resource (pcfhub.json) and the rules it validates against, listing the exact aspects (schema version, control block, demo fidelity, bundle, presets, media files, release artifacts). It is unmistakably a validation tool, distinct from the sibling retrieval/query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'Use it while writing or reviewing that file, before a release is tagged.' It also advises to read the result rather than retry, which is a practical usage hint. It does not name alternatives, but the sibling set (get, list, search) makes the distinction clear, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
search3 fields changed- changed
Output schema / properties / hits / items / properties / section / descriptionPrevious value: -"The documentation section, on a doc hit; null on a component hit."New value: +"On a doc hit, the section key — \"installation\" — to pass to get_doc_page with componentSlug; null on a component hit." - added
Output schema / properties / hits / items / properties / sectionLabelAdded value: +{ + "description": "On a doc hit, the section as the site titles it — \"Installation\"; null on a component hit.", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / hits / items / properties / type / enumPrevious value: -[ - "component", - "doc" -]New value: +[ + "component", + "doc_page" +]
1 tool update
- Changed
validate_manifest1 field changed- changed
Output schema / properties / schemaVersion / typePrevious value: -"string"New value: +"integer"
3 tool updates
- Changed
get_component2 fields changed- added
Output schema / properties / hostsAdded value: +{ + "description": "Where this control runs: canvas apps, model-driven apps, or both.", + "items": { + "enum": [ + "canvas", + "model-driven" + ], + "type": "string" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "slug", - "name", - "controlType", - "isArchived", - "downloads", - "url" -]New value: +[ + "slug", + "name", + "controlType", + "hosts", + "isArchived", + "downloads", + "url" +]
- Changed
list_components3 fields changed- added
Input schema / properties / hostAdded value: +{ + "description": "Where the control has to run. A control supporting both hosts matches either.", + "enum": [ + "canvas", + "model-driven" + ], + "type": "string" +} - added
Output schema / properties / components / items / properties / hostsAdded value: +{ + "description": "Where this control runs. Empty only where nobody has declared it.", + "items": { + "enum": [ + "canvas", + "model-driven" + ], + "type": "string" + }, + "type": "array" +} - changed
Output schema / properties / components / items / requiredPrevious value: -[ - "slug", - "name", - "controlType", - "category", - "author", - "downloadCount", - "url" -]New value: +[ + "slug", + "name", + "controlType", + "hosts", + "category", + "author", + "downloadCount", + "url" +]
- Changed
list_taxonomy3 fields changed- changed
Input schema / properties / kind / enumPrevious value: -[ - "categories", - "tags", - "authors" -]New value: +[ + "categories", + "tags", + "authors", + "hosts" +] - changed
Output schema / properties / items / items / properties / slug / descriptionPrevious value: -"Pass to list_components as its category, tag or author filter."New value: +"Pass to list_components as its category, tag, author or host filter." - changed
Output schema / properties / kind / enumPrevious value: -[ - "categories", - "tags", - "authors" -]New value: +[ + "categories", + "tags", + "authors", + "hosts" +]
8 tool updates
- Changed
get_component1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "author": { + "properties": { + "githubLogin": { + "type": [ + "string", + "null" + ] + }, + "isVerified": { + "type": "boolean" + }, + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "category": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "controlType": { + "type": "string" + }, + "controlTypeDescription": { + "description": "What that control type means, in a sentence.", + "type": "string" + }, + "currentVersion": { + "description": "The release described, or null where nothing has been published yet.", + "properties": { + "framework": { + "description": "How the control is built, e.g. \"react_virtual\".", + "type": "string" + }, + "isLatest": { + "type": "boolean" + }, + "isPrerelease": { + "type": "boolean" + }, + "minPlatformVersion": { + "type": [ + "string", + "null" + ] + }, + "properties": { + "description": "Every property the control exposes, including the columns a dataset control binds.", + "items": { + "properties": { + "defaultValue": { + "type": [ + "string", + "null" + ] + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "displayName": { + "type": [ + "string", + "null" + ] + }, + "isRequired": { + "type": "boolean" + }, + "kind": { + "description": "input, output, dataset, dataset_column or feature.", + "type": "string" + }, + "name": { + "description": "The property's logical name, as bound in the maker.", + "type": "string" + }, + "type": { + "description": "The Power Platform type, e.g. \"SingleLine.Text\", \"TwoOptions\", \"DataSet\".", + "type": "string" + }, + "usage": { + "description": "input, output or bound. Null on a feature.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "name", + "type", + "isRequired" + ], + "type": "object" + }, + "type": "array" + }, + "releaseNotesMd": { + "type": [ + "string", + "null" + ] + }, + "releasedAt": { + "description": "ISO 8601.", + "type": [ + "string", + "null" + ] + }, + "version": { + "type": "string" + } + }, + "required": [ + "version", + "isPrerelease" + ], + "type": [ + "object", + "null" + ] + }, + "downloadCount": { + "type": "integer" + }, + "downloads": { + "description": "Empty where the control has no published release.", + "items": { + "properties": { + "fileName": { + "type": "string" + }, + "kind": { + "description": "managed_solution or unmanaged_solution.", + "type": "string" + }, + "label": { + "type": "string" + }, + "requiresEntitlement": { + "description": "True where the file is paid for and the download needs an entitlement.", + "type": "boolean" + }, + "size": { + "description": "Human-readable, e.g. \"14.8 KB\".", + "type": [ + "string", + "null" + ] + }, + "url": { + "description": "Absolute URL of the counted download route. Use this rather than any storage URL.", + "type": "string" + } + }, + "required": [ + "kind", + "label", + "fileName", + "requiresEntitlement", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "homepageUrl": { + "type": [ + "string", + "null" + ] + }, + "isArchived": { + "description": "True when the control is no longer maintained.", + "type": "boolean" + }, + "licenseSpdx": { + "description": "SPDX identifier, e.g. \"MIT\".", + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "publishedAt": { + "description": "ISO 8601.", + "type": [ + "string", + "null" + ] + }, + "related": { + "description": "Empty unless include_related was set.", + "type": "array" + }, + "repositoryUrl": { + "type": [ + "string", + "null" + ] + }, + "slug": { + "type": "string" + }, + "summaryMd": { + "description": "The author's longer description, as Markdown.", + "type": [ + "string", + "null" + ] + }, + "supportUrl": { + "description": "Where to report a problem with the control.", + "type": [ + "string", + "null" + ] + }, + "tagline": { + "type": [ + "string", + "null" + ] + }, + "tags": { + "items": { + "properties": { + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "tier": { + "description": "free, or a paid tier.", + "type": "string" + }, + "url": { + "description": "Absolute URL of the control's page, for citing.", + "type": "string" + }, + "versions": { + "description": "Empty unless include_versions was set.", + "type": "array" + } + }, + "required": [ + "slug", + "name", + "controlType", + "isArchived", + "downloads", + "url" + ], + "type": "object" +}
- Changed
get_doc_page1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "componentName": { + "type": "string" + }, + "componentSlug": { + "type": "string" + }, + "contentMd": { + "description": "The page as Markdown, with its frontmatter removed. Empty when the page has no content.", + "type": "string" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "isVersionPinned": { + "description": "True when a version was asked for, rather than the current documentation being returned.", + "type": "boolean" + }, + "section": { + "enum": [ + "overview", + "installation", + "canvas", + "model_driven", + "api", + "examples", + "limitations", + "faq", + "migration", + "changelog" + ], + "type": "string" + }, + "sourceUrl": { + "description": "The file in the author's repository this was compiled from.", + "type": [ + "string", + "null" + ] + }, + "title": { + "type": "string" + }, + "updatedAt": { + "description": "ISO 8601.", + "type": [ + "string", + "null" + ] + }, + "url": { + "description": "Absolute URL of the page, for citing.", + "type": "string" + }, + "version": { + "description": "The release this documentation describes.", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "componentSlug", + "componentName", + "isVersionPinned", + "section", + "title", + "contentMd", + "url" + ], + "type": "object" +}
- Changed
list_components1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "components": { + "items": { + "properties": { + "author": { + "description": "Author slug.", + "type": "string" + }, + "category": { + "description": "Category slug.", + "type": "string" + }, + "controlType": { + "enum": [ + "field", + "dataset", + "virtual", + "grid_customizer" + ], + "type": "string" + }, + "downloadCount": { + "type": "integer" + }, + "latestVersion": { + "description": "Null where nothing has been released yet.", + "type": [ + "string", + "null" + ] + }, + "name": { + "type": "string" + }, + "slug": { + "description": "Pass to get_component.", + "type": "string" + }, + "tagline": { + "type": [ + "string", + "null" + ] + }, + "url": { + "description": "Absolute URL of the control's page.", + "type": "string" + } + }, + "required": [ + "slug", + "name", + "controlType", + "category", + "author", + "downloadCount", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "lastPage": { + "description": "The highest page number for these filters.", + "type": "integer" + }, + "page": { + "description": "The page returned.", + "type": "integer" + }, + "perPage": { + "type": "integer" + }, + "sort": { + "description": "The sort actually applied, which is the default when none was given or the one given was not recognised.", + "type": "string" + }, + "total": { + "description": "Controls matching the filters, across every page.", + "type": "integer" + } + }, + "required": [ + "page", + "perPage", + "lastPage", + "total", + "sort", + "components" + ], + "type": "object" +}
- Changed
list_doc_sections1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "sections": { + "items": { + "properties": { + "section": { + "description": "Pass to get_doc_page as its section argument.", + "type": "string" + }, + "title": { + "description": "The section's heading, as the author wrote it.", + "type": "string" + }, + "url": { + "description": "Absolute URL of the page.", + "type": "string" + } + }, + "required": [ + "section", + "title", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "slug": { + "description": "The control the sections belong to.", + "type": "string" + } + }, + "required": [ + "slug", + "sections" + ], + "type": "object" +}
- Changed
list_releases1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "releases": { + "description": "Newest first.", + "items": { + "properties": { + "componentName": { + "type": "string" + }, + "componentSlug": { + "description": "Pass to get_component.", + "type": "string" + }, + "isPrerelease": { + "type": "boolean" + }, + "releasedAt": { + "description": "ISO 8601, or null where the release carries no date.", + "type": [ + "string", + "null" + ] + }, + "url": { + "description": "Absolute URL of the release.", + "type": "string" + }, + "version": { + "type": "string" + } + }, + "required": [ + "componentSlug", + "componentName", + "version", + "isPrerelease", + "url" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "releases" + ], + "type": "object" +}
- Changed
list_taxonomy1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "items": { + "items": { + "properties": { + "children": { + "description": "Child categories, in the same shape. Categories only.", + "type": "array" + }, + "componentsCount": { + "description": "How many published controls this covers.", + "type": "integer" + }, + "description": { + "description": "Categories only.", + "type": [ + "string", + "null" + ] + }, + "githubLogin": { + "description": "Authors only.", + "type": [ + "string", + "null" + ] + }, + "isVerified": { + "description": "Authors only.", + "type": "boolean" + }, + "name": { + "type": "string" + }, + "slug": { + "description": "Pass to list_components as its category, tag or author filter.", + "type": "string" + } + }, + "required": [ + "slug", + "name", + "componentsCount" + ], + "type": "object" + }, + "type": "array" + }, + "kind": { + "description": "Which list this is.", + "enum": [ + "categories", + "tags", + "authors" + ], + "type": "string" + } + }, + "required": [ + "kind", + "items" + ], + "type": "object" +}
- Changed
search1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "correctedQuery": { + "description": "Set only when nothing matched the query and these are results for a corrected spelling of it.", + "type": [ + "string", + "null" + ] + }, + "hits": { + "items": { + "properties": { + "componentName": { + "type": "string" + }, + "componentSlug": { + "description": "Pass to get_component or get_doc_page.", + "type": "string" + }, + "section": { + "description": "The documentation section, on a doc hit; null on a component hit.", + "type": [ + "string", + "null" + ] + }, + "snippet": { + "description": "The matching text, with the site's highlight markup stripped.", + "type": [ + "string", + "null" + ] + }, + "title": { + "type": "string" + }, + "type": { + "description": "A control, or a page of its documentation.", + "enum": [ + "component", + "doc" + ], + "type": "string" + }, + "url": { + "description": "Absolute URL of the page, for citing.", + "type": "string" + } + }, + "required": [ + "type", + "title", + "componentSlug", + "componentName", + "url" + ], + "type": "object" + }, + "type": "array" + }, + "query": { + "description": "The query as it was searched.", + "type": "string" + }, + "total": { + "description": "How many results matched, which may be more than were returned.", + "type": "integer" + } + }, + "required": [ + "query", + "total", + "hits" + ], + "type": "object" +}
- Changed
validate_manifest1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "errors": { + "description": "Must be fixed; publishing refuses the manifest until they are.", + "items": { + "properties": { + "message": { + "type": "string" + }, + "pointer": { + "description": "RFC 6901 JSON pointer to the part of the manifest at fault, e.g. \"/demo/presets/0\".", + "type": "string" + } + }, + "required": [ + "pointer", + "message" + ], + "type": "object" + }, + "type": "array" + }, + "schemaVersion": { + "description": "The manifest schema version it was checked against.", + "type": "string" + }, + "valid": { + "description": "False when there is at least one error. Warnings alone leave it true.", + "type": "boolean" + }, + "warnings": { + "description": "Do not block publishing, but reach the author through their own CI.", + "items": { + "properties": { + "message": { + "type": "string" + }, + "pointer": { + "description": "RFC 6901 JSON pointer to the part of the manifest at fault, e.g. \"/demo/presets/0\".", + "type": "string" + } + }, + "required": [ + "pointer", + "message" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "valid", + "schemaVersion", + "errors", + "warnings" + ], + "type": "object" +}
8 tool updates
- First observed
get_component - First observed
get_doc_page - First observed
list_components - First observed
list_doc_sections - First observed
list_releases - First observed
list_taxonomy - First observed
search - First observed
validate_manifest
Publisher details
- Operator
- PCF Hub · Publisher source
- Operator website
- https://pcfhub.dev · Publisher source
- Vendor relationship
- First-party · Publisher source
- Documentation
- https://pcfhub.dev/api · Publisher source
- Trust center
- Not applicable
- Restrictions
- Not applicable
Related MCP Connectors
Generate wiki docs from source code. Supports PowerShell, Python, Go, C#, Java, COBOL.
Validate oh-my-posh configurations and segment snippets against the official schema.
Design system contracts, docs search, and usage validation for @digitaltableteur components.
Search Tailwind CSS and React themes, read their tokens and source files, and get download URLs.
Related MCP Servers
- FlicenseCqualityDmaintenanceCreates, inspects, validates, and modifies Power BI Project (.pbip) folders, generating PBIR-style reports and TMDL semantic models from structured inputs.52-
- AlicenseAqualityDmaintenanceProvides access to PatternFly React development rules and documentation via MCP tools, allowing retrieval of documentation from URLs or local paths.217 npm1MIT
- FlicenseAqualityNot gradedmaintenanceExtracts and stores documentation content from Microsoft Learn and GitHub URLs into PocketBase with full-text search, metadata preservation, and automatic collection management for easy retrieval and organization.9-
- AlicenseBqualityCmaintenanceEnables deterministic querying of RVTDocs documentation with tools for fetching, scanning, and debugging documentation content.91MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.