feat: add description field for TOML sources

[tianzhou]

Add optional description field to source configurations that serves as human documentation and is exposed via /api/sources for MCP clients.

[Copilot]

Pull request overview

This pull request adds an optional description field to database source configurations in the TOML config files. The description serves as human-readable documentation and is exposed through the /api/sources REST API for MCP clients to access.

Changes:

• Added optional description field to SourceConfig TypeScript interface
• Updated API transformation logic to include description in responses when present
• Enhanced OpenAPI specification with description field schema and documentation

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/types/config.ts	Added optional description field to SourceConfig interface with clear documentation
src/api/sources.ts	Updated transformSourceConfig to conditionally include description in API responses
src/api/openapi.yaml	Added description field to DataSource schema with example
src/api/openapi.d.ts	Auto-generated TypeScript types reflecting the OpenAPI schema changes
src/config/tests/toml-loader.test.ts	Comprehensive tests for parsing description from TOML files
src/api/tests/sources.integration.test.ts	Integration tests verifying description is exposed via list sources endpoint
src/fixtures/toml/readonly-maxrows.toml	Test fixture updated with example description
dbhub.toml.example	Documentation and examples showing how to use the description field

Comments suppressed due to low confidence (1)

src/api/tests/sources.integration.test.ts:242

• The GET /api/sources/{source-id} endpoint tests should also verify that the description field is properly included in the response when present. Since both this endpoint and the list endpoint use the same transformSourceConfig function, consistency in test coverage would be beneficial. Consider adding a test similar to the one in the list endpoint tests (lines 215-226) to verify the description field is present for sources that have it and undefined for those that don't.

  describe('GET /api/sources/{source-id}', () => {
    it('should return specific source by ID', async () => {
      const response = await fetch(`${BASE_URL}/api/sources/readonly_limited`);
      expect(response.status).toBe(200);

      const source = (await response.json()) as DataSource;
      expect(source.id).toBe('readonly_limited');
      expect(source.type).toBe('sqlite');

      // Check execute_sql tool has readonly and max_rows
      const executeSql = source.tools.find(t => t.name.startsWith('execute_sql'));
      expect(executeSql?.readonly).toBe(true);
      expect(executeSql?.max_rows).toBe(100);
    });