PCFHub

by io.github.pcfhub

Overview Discussions Admin

Server Details

Find Power Apps PCF controls, read their docs, and validate pcfhub.json manifests.

Ownership verified

Status: Healthy
Uptime: 98.0% over 40 days
Last Tested: 2026-10-24 08:07
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored 2026-10-05 19:30 across 8 tools

Disambiguation5/5

Each tool has a crisply distinct purpose, and the descriptions explicitly cross-reference the alternatives (search vs list_components vs get_component; list_doc_sections vs get_doc_page; list_releases vs get_component include_versions). An agent can reliably pick the right tool from the intent described.

Naming Consistency5/5

All names are snake_case verb_noun (get_component, get_doc_page, list_components, list_doc_sections, list_releases, list_taxonomy, validate_manifest) with 'search' as the sole, intuitive bare-verb exception. Pattern is predictable throughout.

Tool Count5/5

Eight tools is well-scoped for a read-oriented control catalog: browse, search, detail, docs, doc sections, releases, taxonomy, and manifest validation each cover a distinct need with no filler.

Completeness4/5

The read/discovery lifecycle is thoroughly covered — search, list, get, docs, taxonomy, releases, and manifest validation. No write/submission or per-release artifact retrieval tool exists, but the documented surface is otherwise self-sufficient for an agent working with the catalog.

Available Tools

8 tools

get_componentGet a PCF controlA

Read-onlyIdempotent

Inspect

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
`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.
`builtWith`	No	ai where an AI assistant wrote the code, ai-assisted where a person wrote it with one. Null where the author has not said.
`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.
`supportLevel`	No	maintained, or reference: a worked example not maintained for production. Null where the author has not said.
`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

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only/idempotent safety; the description goes well beyond by disclosing that unknown slugs or never-released versions produce a redirect-style error, and that include_versions/include_related each incur an extra query cost. This is exactly the cost/error behavior an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the payload, then routing, then failure behavior, then cost guidance. Every sentence carries distinct decision-relevant information with no padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 needn't explain return values, yet it still previews the returned fields for selection purposes. Combined with the routing, error, and cost guidance, nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 slug, version defaults, and the extra-query cost of the two boolean flags. The description's 'leave them off unless you need the release history or similar controls' largely restates the schema's own wording, adding little beyond it. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Everything about one control by its slug') and enumerates the actual payload (control type, license, repository, release properties, solution download links). It is immediately distinguishable from get_doc_page, search, and list_components by both content and the slug-based lookup mode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the sequencing ('once search or list_components has given you a slug') and names the alternative for the adjacent need it does NOT serve ('use get_doc_page for installation and configuration instructions, which this does not return'). It even pre-empts error cases by saying an unknown slug returns an error naming the tool to call instead.

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 pageA

Read-onlyIdempotent

Inspect

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
`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

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 controlsA

Read-onlyIdempotent

Inspect

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
`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

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly and idempotent, but the description adds substantial non-obvious behavior: bad input never fails, an unrecognised sort silently falls back to the default, and non-matching filters yield an empty page. It tells the agent to read `total` and `sort` from the result rather than assuming filters applied — exactly the kind of failure-mode disclosure structured fields cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the capability and followed by routing and caveats in priority order. Every sentence carries distinct information — scope, alternatives, and failure semantics — with no repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return structure needn't be explained, yet the description still points at the meaningful result fields. Given nine optional filter parameters and read-only annotations, an agent has everything needed to call this correctly and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description earns credit for adding the sort fallback rule ('relevance when there is a query, newest otherwise' is implied by the dynamic default) and the slug provenance from list_taxonomy. It does not add syntax beyond the schema's enum descriptions, so it stops short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — browse the PCFHub catalog — and enumerates the dimensions it can be narrowed by (category, tag, author, control type, host, text). It also explicitly distinguishes itself from the search and get_component siblings, so an agent can route without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('enumerate or narrow the catalog') and names the two alternatives with the conditions that select them: search for plain-language questions, get_component for a single control in full. It also flags the prerequisite that filter values are slugs supplied by list_taxonomy.

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 documentationA

Read-onlyIdempotent

Inspect

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

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 releasesA

Read-onlyIdempotent

Inspect

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

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 hostsA

Read-onlyIdempotent

Inspect

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

A4.9/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 PCFHubA

Read-onlyIdempotent

Inspect

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

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.jsonA

Read-onlyIdempotent

Inspect

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

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

2 tool updatesOct 5, 2026

Changedget_component2 fields changed

addedOutput schema / properties / builtWith

Added value: +{
+  "description": "ai where an AI assistant wrote the code, ai-assisted where a person wrote it with one. Null where the author has not said.",
+  "enum": [
+    "ai",
+    "ai-assisted",
+    null
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / supportLevel

Added value: +{
+  "description": "maintained, or reference: a worked example not maintained for production. Null where the author has not said.",
+  "enum": [
+    "maintained",
+    "reference",
+    null
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changedlist_components2 fields changed

addedOutput schema / properties / components / items / properties / builtWith

Added value: +{
+  "description": "ai where an AI assistant wrote the code, ai-assisted where a person wrote it with one. Null where the author has not said.",
+  "enum": [
+    "ai",
+    "ai-assisted",
+    null
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / components / items / properties / supportLevel

Added value: +{
+  "description": "maintained, or reference: a worked example not maintained for production. Null where the author has not said.",
+  "enum": [
+    "maintained",
+    "reference",
+    null
+  ],
+  "type": [
+    "string",
+    "null"
+  ]
+}

1 tool updateSep 26, 2026

Changedsearch3 fields changed

changedOutput schema / properties / hits / items / properties / section / description

Previous 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."

addedOutput schema / properties / hits / items / properties / sectionLabel

Added value: +{
+  "description": "On a doc hit, the section as the site titles it — \"Installation\"; null on a component hit.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / hits / items / properties / type / enum

Previous value: -[
-  "component",
-  "doc"
-]New value: +[
+  "component",
+  "doc_page"
+]

1 tool updateSep 26, 2026
- Changedvalidate_manifest1 field changed
  - changedOutput schema / properties / schemaVersion / type
```
Previous value: -"string"New value: +"integer"
```

3 tool updatesSep 19, 2026

Changedget_component2 fields changed

addedOutput schema / properties / hosts

Added value: +{
+  "description": "Where this control runs: canvas apps, model-driven apps, or both.",
+  "items": {
+    "enum": [
+      "canvas",
+      "model-driven"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "slug",
-  "name",
-  "controlType",
-  "isArchived",
-  "downloads",
-  "url"
-]New value: +[
+  "slug",
+  "name",
+  "controlType",
+  "hosts",
+  "isArchived",
+  "downloads",
+  "url"
+]

Changedlist_components3 fields changed

addedInput schema / properties / host

Added value: +{
+  "description": "Where the control has to run. A control supporting both hosts matches either.",
+  "enum": [
+    "canvas",
+    "model-driven"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / components / items / properties / hosts

Added value: +{
+  "description": "Where this control runs. Empty only where nobody has declared it.",
+  "items": {
+    "enum": [
+      "canvas",
+      "model-driven"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / properties / components / items / required

Previous value: -[
-  "slug",
-  "name",
-  "controlType",
-  "category",
-  "author",
-  "downloadCount",
-  "url"
-]New value: +[
+  "slug",
+  "name",
+  "controlType",
+  "hosts",
+  "category",
+  "author",
+  "downloadCount",
+  "url"
+]

Changedlist_taxonomy3 fields changed

changedInput schema / properties / kind / enum

Previous value: -[
-  "categories",
-  "tags",
-  "authors"
-]New value: +[
+  "categories",
+  "tags",
+  "authors",
+  "hosts"
+]

changedOutput schema / properties / items / items / properties / slug / description

Previous 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."

changedOutput schema / properties / kind / enum

Previous value: -[
-  "categories",
-  "tags",
-  "authors"
-]New value: +[
+  "categories",
+  "tags",
+  "authors",
+  "hosts"
+]

8 tool updatesSep 16, 2026

Changedget_component1 field changed

changedOutput 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"
+}

Changedget_doc_page1 field changed

changedOutput 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"
+}

Changedlist_components1 field changed

changedOutput 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"
+}

Changedlist_doc_sections1 field changed

changedOutput 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"
+}

Changedlist_releases1 field changed

changedOutput 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"
+}

Changedlist_taxonomy1 field changed

changedOutput 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"
+}

Changedsearch1 field changed

changedOutput 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"
+}

Changedvalidate_manifest1 field changed

changedOutput 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 updatesSep 13, 2026
- First observedget_component
- First observedget_doc_page
- First observedlist_components
- First observedlist_doc_sections
- First observedlist_releases
- First observedlist_taxonomy
- First observedsearch
- First observedvalidate_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

wikimint A
io.github.greenmtnsun
Generate wiki docs from source code. Supports PowerShell, Python, Go, C#, Java, COBOL.
Code Analysis Developer Tools Documentation Access
2
https://wikimint.grayocean-4062ad43.eastus.azurecontainerapps.io/mcp
Oh My Posh Validator A
dev.ohmyposh
Validate oh-my-posh configurations and segment snippets against the official schema.
Developer Tools Command Line
2321,295
https://ohmyposh.dev/api/mcp
Digitaltableteur A
com.digitaltableteur
Design system contracts, docs search, and usage validation for @digitaltableteur components.
Developer Tools Code Analysis Documentation Access
1212
https://www.digitaltableteur.com/mcp
TailThemes A
com.tailthemes
Search Tailwind CSS and React themes, read their tokens and source files, and get download URLs.
Design Tools Developer Tools
41
https://tailthemes.com/api/mcp

Related MCP Servers

PBIP Builder MCP Server
File Systems Data Visualization Developer Tools
haiprobmt
F
license
C
quality
D
maintenance
Creates, inspects, validates, and modifies Power BI Project (.pbip) folders, generating PBIR-style reports and TMDL semantic models from structured inputs.
Updated 4 months ago (2026-06-22 16:46 UTC)
52
-
PatternFly MCP Server
Documentation Access Developer Tools
jeff-phillips-18
A
license
A
quality
D
maintenance
Provides access to PatternFly React development rules and documentation via MCP tools, allowing retrieval of documentation from URLs or local paths.
Updated a year ago (2025-10-20 19:30 UTC)
2
4 npm
1
MIT
Document Extractor MCP Server
Web Scraping Databases Documentation Access
DynamicEndpoints
F
license
A
quality
Not graded
maintenance
Extracts 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.
Updated a year ago (2025-06-26 13:35 UTC)
9
-
RVTDocs MCP
Documentation Access Search
trgiangv
A
license
B
quality
D
maintenance
Enables deterministic querying of RVTDocs documentation with tools for fetching, scanning, and debugging documentation content.
Updated 3 months ago (2026-08-01 15:22 UTC)
9
1
MIT

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?