Construct model providers table automatically

[zastrowm]

Overview

Currently the model providers overview page contains a table of model providers, hardcoded in text. Instead of doing that, generate it dynamically by querying the docs collection and extracting entries with integrationType: 'model-provider' frontmatter/entry data.

---

Implementation Requirements

Based on clarification discussion and repository analysis:

Technical Approach

• Framework: Astro/Starlight documentation site
• Filtering: Use frontmatter-based filtering with new integrationType field

Frontmatter Field

• Add new integrationType field to content schema in src/content.config.ts
• Value: 'model-provider' for model provider pages
• All model provider pages must be updated with this frontmatter field

Language Support Detection

• Use existing languages frontmatter field convention:
  • languages: Python = Python-only support
  • No languages field = Both Python and TypeScript support
• No new fields needed for language detection

Community Provider Handling

• Include community providers in the generated table
• Visually distinguish them from official providers (separate section or badge)
• Community providers are identified by having community: true in frontmatter

Sort Order

• Sort providers alphabetically by title (non-community first)

Special Cases

• Custom Providers page: Include in the generated table
• Index page: Automatically exclude from the list (it's the overview page itself)

Files to Create/Modify

Create:

• src/components/ModelProvidersList.astro - New component to generate the table dynamically

Modify:

• src/content.config.ts - Add integrationType field to docs schema
• src/content/docs/user-guide/concepts/model-providers/index.mdx - Replace hardcoded table with component
• src/content/docs/user-guide/concepts/model-providers/*.mdx - Add integrationType: 'model-provider' frontmatter to all provider pages (18 files)

Tests:

• Add tests for the new ModelProvidersList.astro component

Model Provider Pages to Update (18 files)

1. amazon-bedrock.mdx
2. amazon-nova.mdx
3. anthropic.mdx
4. clova-studio.mdx
5. cohere.mdx
6. custom_model_provider.mdx
7. fireworksai.mdx
8. gemini.mdx
9. litellm.mdx
10. llamaapi.mdx
11. llamacpp.mdx
12. mistral.mdx
13. nebius-token-factory.mdx
14. ollama.mdx
15. openai.mdx
16. sagemaker.mdx
17. writer.mdx
18. xai.mdx

---

Acceptance Criteria

• New integrationType field added to content schema
• All model provider pages have integrationType: 'model-provider' frontmatter
• ModelProvidersList.astro component created following existing patterns
• Component correctly generates table with Provider, Python Support, TypeScript Support columns
• Community providers are visually distinguished (badge or separate section)
• Table is sorted alphabetically by provider name
• Index page is excluded from the generated list
• Custom Providers page is included in the table
• Hardcoded table in index.mdx replaced with new component
• Tests added for the new component
• All existing tests pass
• Site builds successfully with npm run build

[zastrowm]

/strands

[github-actions]

Repository Analysis & Clarifying Questions

I've analyzed the repository structure and have some questions to ensure proper implementation.

Repository Context

Current State

• Location: src/content/docs/user-guide/concepts/model-providers/index.mdx
• Current Table: Hardcoded with 17 providers showing Python/TypeScript support
• Existing Pattern: PythonApiList.astro and TypeScriptApiList.astro components query the docs collection and dynamically generate content

Existing Frontmatter Fields

• languages: Already used to indicate SDK limitation (e.g., languages: Python means Python-only)
• Pages without languages field imply both Python and TypeScript support
• category: Used for TypeScript API docs categorization

Provider Categories Found

Official/Core Providers (13 pages with actual content):

• 4 with both Python + TypeScript: Amazon Bedrock, Gemini, OpenAI, Custom Providers
• 9 with Python-only: Amazon Nova, Anthropic, LiteLLM, llama.cpp, LlamaAPI, Mistral AI, Ollama, SageMaker, Writer

Community Providers (redirect stubs → community section):

• Cohere, CLOVA Studio, FireworksAI, Nebius Token Factory, xAI
• These have sidebar.badge: Community and contain <auto-redirect /> to redirect users

Clarifying Questions

1. Filtering Approach

Should we use:

• Option A: New frontmatter field like integrationType: 'model-provider' (as suggested in the issue)
• Option B: Path-based filtering similar to API docs (filter by docs/user-guide/concepts/model-providers/*)

Path-based (Option B) would require no changes to existing provider pages, but is less explicit. Frontmatter-based (Option A) is more explicit but requires updating all provider pages.

2. Community Provider Handling

The current hardcoded table includes community providers (Cohere, CLOVA Studio, etc.). Should the generated table:

• Option A: Include community providers (matching current behavior)
• Option B: Exclude community providers (only show official/core providers)
• Option C: Include them but visually distinguish them (e.g., with a badge or separate section)

3. Language Support Determination

The existing languages frontmatter field already indicates support:

• languages: Python = Python-only
• No languages field = Both Python and TypeScript

Should we:

• Option A: Continue using this existing convention (derive TypeScript support from absence of languages: Python)
• Option B: Add explicit fields like supportsPython: true, supportsTypeScript: true

Option A requires no changes to existing pages; Option B is more explicit but requires updating all provider pages.

4. Sort Order

How should providers be sorted in the generated table?

• Option A: Alphabetical by title
• Option B: Match current sidebar order (as defined in navigation.yml)
• Option C: Custom order via a new order or priority frontmatter field

5. Special Cases

• Should the Custom Providers page be included in the generated table? (It's currently first in the hardcoded table)
• Should the index page itself be automatically excluded from the list?

Implementation Approach

Based on your answers, I'm planning to:

1. Add any needed frontmatter field to the content schema (src/content.config.ts)
2. Create a new ModelProvidersList.astro component (similar to existing API list components)
3. Update provider pages with new frontmatter if needed
4. Replace the hardcoded table in index.mdx with the new component
5. Add tests for the new component

This task appears well-scoped for a single PR and follows existing patterns in the codebase. No GitHub workflow changes are needed.

[zastrowm]

Repository Analysis & Clarifying Questions
I've analyzed the repository structure and have some questions to ensure proper implementation.

Repository Context

Current State

• Location: src/content/docs/user-guide/concepts/model-providers/index.mdx
• Current Table: Hardcoded with 17 providers showing Python/TypeScript support
• Existing Pattern: PythonApiList.astro and TypeScriptApiList.astro components query the docs collection and dynamically generate content

Existing Frontmatter Fields

• languages: Already used to indicate SDK limitation (e.g., languages: Python means Python-only)
• Pages without languages field imply both Python and TypeScript support
• category: Used for TypeScript API docs categorization

Provider Categories Found

Official/Core Providers (13 pages with actual content):

• 4 with both Python + TypeScript: Amazon Bedrock, Gemini, OpenAI, Custom Providers
• 9 with Python-only: Amazon Nova, Anthropic, LiteLLM, llama.cpp, LlamaAPI, Mistral AI, Ollama, SageMaker, Writer

Community Providers (redirect stubs → community section):

• Cohere, CLOVA Studio, FireworksAI, Nebius Token Factory, xAI
• These have sidebar.badge: Community and contain <auto-redirect /> to redirect users

Clarifying Questions

1. Filtering Approach

Should we use:

• Option A: New frontmatter field like integrationType: 'model-provider' (as suggested in the issue)
• Option B: Path-based filtering similar to API docs (filter by docs/user-guide/concepts/model-providers/*)

OptionA

Path-based (Option B) would require no changes to existing provider pages, but is less explicit. Frontmatter-based (Option A) is more explicit but requires updating all provider pages.

2. Community Provider Handling

The current hardcoded table includes community providers (Cohere, CLOVA Studio, etc.). Should the generated table:

• Option A: Include community providers (matching current behavior)
• Option B: Exclude community providers (only show official/core providers)
• Option C: Include them but visually distinguish them (e.g., with a badge or separate section)

Option C if possible

3. Language Support Determination

The existing languages frontmatter field already indicates support:

• languages: Python = Python-only
• No languages field = Both Python and TypeScript

Should we:

• Option A: Continue using this existing convention (derive TypeScript support from absence of languages: Python)
• Option B: Add explicit fields like supportsPython: true, supportsTypeScript: true

OptionA

Option A requires no changes to existing pages; Option B is more explicit but requires updating all provider pages.

4. Sort Order

How should providers be sorted in the generated table?

• Option A: Alphabetical by title
• Option B: Match current sidebar order (as defined in navigation.yml)
• Option C: Custom order via a new order or priority frontmatter field

5. Special Cases

• Should the Custom Providers page be included in the generated table? (It's currently first in the hardcoded table)

Yes

• Should the index page itself be automatically excluded from the list?

No

Implementation Approach

Based on your answers, I'm planning to:

1. Add any needed frontmatter field to the content schema (src/content.config.ts)
2. Create a new ModelProvidersList.astro component (similar to existing API list components)
3. Update provider pages with new frontmatter if needed
4. Replace the hardcoded table in index.mdx with the new component
5. Add tests for the new component

This task appears well-scoped for a single PR and follows existing patterns in the codebase. No GitHub workflow changes are needed.

[zastrowm]

/strands

[zastrowm]

/strands implement