@aborruso/ckan-mcp-server 0.4.17 → 0.4.18

package/openspec/changes/archive/add-automated-tests/tasks.md

@@ -1,132 +0,0 @@
-# Tasks: Add Automated Testing
-
-Ordered list of work items to add automated tests to the project.
-
-## Phase 1: Foundation
-
-- [x] Install Vitest and related dependencies
-- [x] Create vitest.config.ts with TypeScript support
-- [x] Create test directory structure: `tests/unit/`, `tests/integration/`, `tests/fixtures/`
-- [x] Add test scripts to package.json (test, test:watch, test:coverage)
-- [x] Create .gitignore entry for coverage directory
-- [x] Configure coverage settings (threshold: 80%)
-
-## Phase 2: Create Mock Fixtures
-
-- [x] Create `tests/fixtures/responses/status-success.json`
-- [x] Create `tests/fixtures/responses/package-search-success.json`
-- [x] Create `tests/fixtures/responses/package-show-success.json`
-- [x] Create `tests/fixtures/responses/organization-list-success.json`
-- [x] Create `tests/fixtures/responses/organization-show-success.json`
-- [x] Create `tests/fixtures/responses/organization-search-success.json`
-- [x] Create `tests/fixtures/responses/datastore-search-success.json`
-- [x] Create `tests/fixtures/errors/timeout.json`
-- [x] Create `tests/fixtures/errors/not-found.json`
-- [x] Create `tests/fixtures/errors/server-error.json`
-- [x] Document fixture structure in tests/README.md
-
-## Phase 3: Unit Tests for Utils
-
-- [x] Create `tests/unit/formatting.test.ts`
-- [x] Write test for truncateText() with normal text
-- [x] Write test for truncateText() with empty string
-- [x] Write test for truncateText() with text under limit
-- [x] Write test for truncateText() with text over limit
-- [x] Write test for formatDate() with ISO date string
-- [x] Write test for formatDate() with null/undefined
-- [x] Write test for formatBytes() with bytes
-- [x] Write test for formatBytes() with kilobytes
-- [x] Write test for formatBytes() with megabytes
-- [x] Write test for formatBytes() with gigabytes
-- [x] Run tests and verify all pass
-
-- [x] Create `tests/unit/http.test.ts`
-- [x] Write test for makeCkanRequest() successful response
-- [x] Write test for makeCkanRequest() with error (404)
-- [x] Write test for makeCkanRequest() with error (500)
-- [x] Write test for makeCkanRequest() with timeout
-- [x] Write test for makeCkanRequest() URL normalization (trailing slash)
-- [x] Write test for makeCkanRequest() User-Agent header
-- [x] Run tests and verify all pass
-
-## Phase 4: Integration Tests for Tools
-
-### Status Tool
-- [x] Create `tests/integration/status.test.ts`
-- [x] Write test for ckan_status_show with valid server URL
-- [x] Write test for ckan_status_show with invalid URL
-- [ ] Write test for ckan_status_show with server error
-- [ ] Write test for markdown output format
-- [ ] Write test for JSON output format
-- [x] Run tests and verify all pass
-
-### Package Tools
-- [ ] Create `tests/integration/package.test.ts`
-- [ ] Write test for ckan_package_search with basic query
-- [ ] Write test for ckan_package_search with facets
-- [ ] Write test for ckan_package_search with pagination
-- [ ] Write test for ckan_package_search with sorting
-- [ ] Write test for ckan_package_search with filter query
-- [ ] Write test for ckan_package_show with valid package ID
-- [ ] Write test for ckan_package_show with invalid package ID
-- [ ] Write test for markdown output format
-- [ ] Write test for JSON output format
-- [ ] Run tests and verify all pass
-
-### Organization Tools
-- [ ] Create `tests/integration/organization.test.ts`
-- [ ] Write test for ckan_organization_list
-- [ ] Write test for ckan_organization_list with sorting
-- [ ] Write test for ckan_organization_show
-- [ ] Write test for ckan_organization_search
-- [ ] Write test for markdown output format
-- [ ] Write test for JSON output format
-- [ ] Run tests and verify all pass
-
-### DataStore Tool
-- [ ] Create `tests/integration/datastore.test.ts`
-- [ ] Write test for ckan_datastore_search with basic query
-- [ ] Write test for ckan_datastore_search with filters
-- [ ] Write test for ckan_datastore_search with sorting
-- [ ] Write test for ckan_datastore_search with pagination
-- [ ] Write test for markdown output format
-- [ ] Write test for JSON output format
-- [ ] Run tests and verify all pass
-
-## Phase 5: Validation and Documentation
-
-- [x] Run `npm test` and verify all tests pass
-- [x] Run `npm run test:coverage` and check coverage report
-- [ ] Verify coverage meets 80% threshold
-- [ ] Update CLAUDE.md with testing instructions
-- [ ] Update README.md with test section
-- [x] Create test writing guide in tests/README.md
-- [ ] Add example test in test writing guide
-
-## Phase 6: Continuous Integration
-
-- [ ] Check if CI/CD exists (GitHub Actions, etc.)
-- [ ] Add test step to CI pipeline if exists
-- [ ] Add coverage reporting to CI if exists
-- [ ] Verify tests run in CI environment
-- [ ] Configure coverage upload to service (optional)
-
-## Dependencies
-
-- Phase 1 must complete before Phase 2, 3, 4
-- Phase 2 must complete before Phase 4 (fixtures needed)
-- Phase 3 and Phase 4 can be done in parallel after Phase 2
-- Phase 5 depends on completion of Phase 3 and Phase 4
-- Phase 6 is optional and depends on CI infrastructure
-
-## Notes
-
-- Use vi.fn() for mocking axios
-- Keep tests focused and readable
-- Mock realistic CKAN API responses from actual documentation
-- One assertion per test when possible
-- Describe expected behavior clearly in test names
-- Use describe blocks for grouping related tests
-- Use test.only sparingly and remove before committing
-- Run tests in watch mode during development: `npm run test:watch`
-- Generate coverage report: `npm run test:coverage`

package/openspec/project.md

@@ -1,115 +0,0 @@
-# Project Context
-
-## Purpose
-CKAN MCP Server - MCP (Model Context Protocol) server for interacting with open data portals based on CKAN (dati.gov.it, data.gov, demo.ckan.org, etc.).
-
-Exposes MCP tools for:
-- Advanced dataset search with Solr syntax
-- DataStore queries for tabular data analysis
-- Organization and group exploration
-- Complete metadata access
-
-## Tech Stack
-- **TypeScript** (ES2022 target)
-- **Node.js**
-- **esbuild** - ultra-fast build system (preferred over tsc for memory efficiency)
-- **@modelcontextprotocol/sdk** - official MCP SDK
-- **axios** - HTTP client for CKAN API calls
-- **zod** - schema validation for tool inputs
-- **express** - HTTP server (for HTTP transport mode)
-
-## Project Conventions
-
-### Code Style
-- TypeScript strict mode enabled
-- Modular tool files in `src/tools/*`
-- Utility functions for reusable operations (makeCkanRequest, truncateText, formatDate)
-- Zod schemas for strict input validation (reject extra parameters)
-- Italian locale for date formatting (it-IT)
-- Markdown output optimized for human readability; JSON available for programmatic use
-
-### Architecture Patterns
-- **Modular MCP server** - registration in `src/server.ts`
-- **Tool-based architecture** - 13 registered MCP tools for CKAN operations
-- **Multiple transport modes**:
-  - stdio (default) - for local MCP client integration
-  - HTTP - for remote access via POST /mcp endpoint
-  - Cloudflare Workers - `/mcp` endpoint in `src/worker.ts`
-- **Read-only operations** - no data modification on CKAN
-- **No caching** - fresh API calls for each request
-- **Error handling** - HTTP errors, timeouts, server validation
-
-### Testing Strategy
-- **Automated tests** with Vitest (integration fixtures)
-- Manual testing:
-  - stdio mode: direct integration testing with Claude Desktop
-  - HTTP mode: curl-based testing against localhost endpoint
-- Build validation via `npm run build` before deployment
-
-### Git Workflow
-- **Main branch**: `main`
-- **Commit style**: extremely concise, prioritize brevity over grammar
-- **LOG.md**: date-based entries (YYYY-MM-DD format), most recent at top
-- **GitHub operations**: use `gh` CLI exclusively
-- Update LOG.md for any significant change
-
-## Domain Context
-
-### CKAN Knowledge
-- **CKAN API v3** - standard API across all CKAN portals
-- **Apache Solr** - powers search functionality
-  - Supports field:value syntax, AND/OR/NOT operators, wildcards, ranges
-  - Filter queries (fq) for filtering without affecting score
-  - Facets for statistical aggregations
-  - Sort and pagination (start/rows)
-
-### Output Conventions
-- All tools support `format` parameter: `markdown` (default) or `json`
-- Output truncated to 50000 characters max (hardcoded)
-- Dates formatted in Italian locale
-- File sizes in human-readable format
-- `server_url` for Italy uses `https://dati.gov.it/opendata`
-
-## Important Constraints
-
-### Environment
-- **WSL considerations** - memory constraints require esbuild instead of tsc
-- Always use `npm run build` (esbuild) not `npm run build:tsc`
-- esbuild bundles internal modules but keeps external deps as-is
-
-### Technical Limits
-- 50000 character output limit (hardcoded, could be configurable)
-- 30-second timeout for CKAN API calls
-- Read-only operations only (security by design)
-- No authentication (public endpoints only)
-- No caching (trade-off: freshness vs performance)
-
-### Build System
-- esbuild config: bundles TypeScript, externalizes runtime deps
-- External deps must be in node_modules: @modelcontextprotocol/sdk, axios, express, zod
-- tsconfig.json mainly for IDE support (esbuild ignores most options)
-
-## External Dependencies
-
-### CKAN Portals
-Major supported portals:
-- 🇮🇹 https://dati.gov.it/opendata (Italia)
-- 🇺🇸 https://catalog.data.gov (United States)
-- 🇨🇦 https://open.canada.ca/data (Canada)
-- 🇬🇧 https://data.gov.uk (United Kingdom)
-- 🇪🇺 https://data.europa.eu (European Union)
-- 🌍 https://demo.ckan.org (Official CKAN demo)
-
-### CKAN API Integration
-- All requests use axios with 30s timeout
-- User-Agent: `CKAN-MCP-Server/1.0`
-- URL normalization (remove trailing slash)
-- Response validation (success === true)
-- Error handling: HTTP errors, timeouts, unreachable servers
-
-### Portal Variations
-Each CKAN portal may differ in:
-- DataStore availability
-- Custom dataset fields
-- Available organizations and tags
-- Supported resource formats

package/openspec/specs/ckan-insights/spec.md

@@ -1,23 +0,0 @@
-# ckan-insights Specification
-
-## Purpose
-Describe dataset insight tools (relevance, freshness, structure) once implemented.
-## Requirements
-### Requirement: Insights capability reserved
-The system SHALL maintain this specification to document dataset insight tools when they are added.
-
-#### Scenario: Insight tools documented
-- **WHEN** new insight tools are implemented
-- **THEN** their requirements are captured in this specification
-
-### Requirement: Find relevant datasets
-The system SHALL provide a `ckan_find_relevant_datasets` tool that accepts `server_url`, `query`, `limit`, optional weights for title, notes, tags, and organization, and an optional search parser override, and returns the top N datasets ranked by score with a per-field score breakdown.
-
-#### Scenario: Ranked results returned
-- **WHEN** the tool is invoked with a query and limit
-- **THEN** the system uses `package_search` results to return the top N datasets with numeric scores and field contributions
-
-#### Scenario: Search parser override applied
-- **WHEN** the tool is invoked with a search parser override
-- **THEN** the system applies the override to the underlying `package_search` query
-

package/openspec/specs/ckan-search/spec.md

@@ -1,16 +0,0 @@
-# ckan-search Specification
-
-## Purpose
-TBD - created by archiving change update-search-parser-config. Update Purpose after archive.
-## Requirements
-### Requirement: Package search parser override
-The system SHALL support a per-portal default and a per-request override to force package search queries through the `text` field when needed.
-
-#### Scenario: Portal default applies
-- **WHEN** a portal is configured to force the text-field parser
-- **THEN** `ckan_package_search` uses `text:(...)` for non-fielded queries by default
-
-#### Scenario: Request override applies
-- **WHEN** a client explicitly requests the text-field parser
-- **THEN** `ckan_package_search` uses `text:(...)` regardless of portal defaults
-

package/openspec/specs/cloudflare-deployment/spec.md

@@ -1,344 +0,0 @@
-# cloudflare-deployment Specification
-
-## Purpose
-TBD - created by archiving change add-cloudflare-workers. Update Purpose after archive.
-## Requirements
-### Requirement: Workers Entry Point
-
-The system SHALL provide a Cloudflare Workers-compatible entry point that handles HTTP requests using the Workers fetch API.
-
-#### Scenario: Health check endpoint
-
-- **WHEN** client sends `GET /health` to Workers endpoint
-- **THEN** server returns JSON with status, version, tool count, and resource count
-
-#### Scenario: MCP protocol endpoint
-
-- **WHEN** client sends `POST /mcp` with JSON-RPC request to Workers endpoint
-- **THEN** server processes MCP request and returns JSON-RPC response
-
-#### Scenario: Invalid route
-
-- **WHEN** client requests any path other than `/health` or `/mcp`
-- **THEN** server returns 404 Not Found
-
-#### Scenario: Invalid method on MCP endpoint
-
-- **WHEN** client sends non-POST request to `/mcp`
-- **THEN** server returns 404 Not Found
-
----
-
-### Requirement: MCP Server Integration
-
-The system SHALL initialize MCP server instance on each Workers invocation and register all tools and resources.
-
-#### Scenario: Server initialization
-
-- **WHEN** Workers receives MCP request
-- **THEN** server creates MCP Server instance with name "ckan-mcp-server" and version "0.4.0"
-
-#### Scenario: Tool registration
-
-- **WHEN** Workers initializes MCP server
-- **THEN** server registers all 7 CKAN tools (package_search, package_show, organization_list, organization_show, organization_search, datastore_search, status_show)
-
-#### Scenario: Resource registration
-
-- **WHEN** Workers initializes MCP server
-- **THEN** server registers all 3 resource templates (dataset, resource, organization)
-
-#### Scenario: Tools list request
-
-- **WHEN** client calls `tools/list` method via Workers endpoint
-- **THEN** response includes all 7 registered CKAN tools with descriptions
-
----
-
-### Requirement: Web Standards HTTP Client
-
-The system SHALL use native Web Fetch API for CKAN API requests instead of Node.js-specific libraries.
-
-#### Scenario: CKAN API request with fetch
-
-- **WHEN** tool calls `makeCkanRequest()` in Workers runtime
-- **THEN** client uses native `fetch()` with 30-second timeout
-
-#### Scenario: Query parameter encoding
-
-- **WHEN** CKAN request includes parameters (e.g., `q`, `rows`, `start`)
-- **THEN** client encodes parameters in URL using `URLSearchParams`
-
-#### Scenario: Request timeout
-
-- **WHEN** CKAN API takes longer than 30 seconds
-- **THEN** client aborts request using `AbortController` and returns timeout error
-
-#### Scenario: HTTP error handling
-
-- **WHEN** CKAN API returns HTTP error status (4xx, 5xx)
-- **THEN** client throws error with status code and message
-
-#### Scenario: CKAN API validation
-
-- **WHEN** CKAN API returns 200 OK but `success: false`
-- **THEN** client throws error with CKAN error message
-
----
-
-### Requirement: Workers Build Configuration
-
-The system SHALL provide separate build configuration for Workers deployment targeting browser platform with ESM format.
-
-#### Scenario: Workers build script
-
-- **WHEN** user runs `npm run build:worker`
-- **THEN** esbuild compiles `src/worker.ts` to `dist/worker.js` in ESM format
-
-#### Scenario: Bundle all dependencies
-
-- **WHEN** esbuild builds Workers bundle
-- **THEN** all dependencies are bundled (no external modules)
-
-#### Scenario: Platform targeting
-
-- **WHEN** esbuild builds Workers bundle
-- **THEN** platform is set to `browser` and target is `es2022`
-
-#### Scenario: Output format
-
-- **WHEN** Workers build completes
-- **THEN** output is ESM format (not CommonJS)
-
-#### Scenario: Bundle size validation
-
-- **WHEN** Workers build completes
-- **THEN** bundle size is less than 1MB (Workers script size limit)
-
----
-
-### Requirement: Wrangler Configuration
-
-The system SHALL provide Wrangler configuration file for Workers deployment and local development.
-
-#### Scenario: Wrangler configuration file
-
-- **WHEN** project contains `wrangler.toml` in root directory
-- **THEN** configuration specifies name, main entry point, and compatibility date
-
-#### Scenario: Build command
-
-- **WHEN** `wrangler deploy` or `wrangler dev` runs
-- **THEN** Wrangler executes `npm run build:worker` before deployment
-
-#### Scenario: Local development server
-
-- **WHEN** user runs `npm run dev:worker`
-- **THEN** Wrangler starts local Workers server on http://localhost:8787
-
----
-
-### Requirement: Workers Deployment
-
-The system SHALL deploy to Cloudflare Workers and provide public HTTPS endpoint.
-
-#### Scenario: Deploy to Workers
-
-- **WHEN** user runs `npm run deploy`
-- **THEN** Wrangler builds and uploads worker to Cloudflare
-
-#### Scenario: Public endpoint
-
-- **WHEN** deployment succeeds
-- **THEN** Workers script is accessible at `https://ckan-mcp-server.<account>.workers.dev`
-
-#### Scenario: HTTPS support
-
-- **WHEN** client accesses Workers endpoint
-- **THEN** connection uses HTTPS with valid certificate
-
----
-
-### Requirement: Tool Functionality Preservation
-
-The system SHALL maintain identical functionality for all CKAN tools in Workers runtime compared to Node.js runtime.
-
-#### Scenario: Package search in Workers
-
-- **WHEN** client calls `ckan_package_search` via Workers endpoint
-- **THEN** response is identical to Node.js runtime response
-
-#### Scenario: Datastore query in Workers
-
-- **WHEN** client calls `ckan_datastore_search` via Workers endpoint
-- **THEN** response is identical to Node.js runtime response
-
-#### Scenario: Resource template in Workers
-
-- **WHEN** client reads `ckan://{server}/dataset/{id}` via Workers
-- **THEN** response is identical to Node.js runtime response
-
-#### Scenario: Error handling in Workers
-
-- **WHEN** CKAN API is unreachable in Workers runtime
-- **THEN** error response matches Node.js runtime error format
-
----
-
-### Requirement: Response Format Compatibility
-
-The system SHALL support both markdown and JSON output formats in Workers runtime.
-
-#### Scenario: Markdown format
-
-- **WHEN** client requests tool with `response_format: "markdown"`
-- **THEN** Workers returns formatted markdown text
-
-#### Scenario: JSON format
-
-- **WHEN** client requests tool with `response_format: "json"`
-- **THEN** Workers returns raw JSON data
-
-#### Scenario: Character limit
-
-- **WHEN** response exceeds CHARACTER_LIMIT (50000 characters)
-- **THEN** Workers truncates response identically to Node.js runtime
-
----
-
-### Requirement: Error Handling
-
-The system SHALL handle Workers-specific errors gracefully with JSON-RPC error responses.
-
-#### Scenario: Malformed JSON-RPC request
-
-- **WHEN** client sends invalid JSON to `/mcp` endpoint
-- **THEN** Workers returns JSON-RPC error with code -32700 (Parse error)
-
-#### Scenario: Internal worker error
-
-- **WHEN** worker encounters unexpected exception
-- **THEN** Workers returns JSON-RPC error with code -32603 (Internal error)
-
-#### Scenario: Method not found
-
-- **WHEN** client calls non-existent MCP method
-- **THEN** Workers returns JSON-RPC error with code -32601 (Method not found)
-
----
-
-### Requirement: CORS Support
-
-The system SHALL include CORS headers to enable browser-based MCP clients.
-
-#### Scenario: CORS headers on success
-
-- **WHEN** Workers returns successful response
-- **THEN** response includes `Access-Control-Allow-Origin: *` header
-
-#### Scenario: CORS headers on error
-
-- **WHEN** Workers returns error response
-- **THEN** response includes `Access-Control-Allow-Origin: *` header
-
-#### Scenario: Preflight request
-
-- **WHEN** browser sends OPTIONS request for CORS preflight
-- **THEN** Workers returns allowed methods and headers
-
----
-
-### Requirement: Deployment Documentation
-
-The system SHALL provide comprehensive documentation for deploying to Cloudflare Workers.
-
-#### Scenario: Deployment guide
-
-- **WHEN** contributor wants to deploy Workers instance
-- **THEN** `docs/DEPLOYMENT.md` provides step-by-step instructions
-
-#### Scenario: Prerequisites documentation
-
-- **WHEN** contributor reads DEPLOYMENT.md
-- **THEN** document lists all prerequisites (Cloudflare account, wrangler CLI)
-
-#### Scenario: Troubleshooting guide
-
-- **WHEN** deployment fails
-- **THEN** DEPLOYMENT.md includes common errors and solutions
-
-#### Scenario: README update
-
-- **WHEN** user reads README.md
-- **THEN** deployment options section includes Cloudflare Workers option
-
----
-
-### Requirement: Backwards Compatibility
-
-The system SHALL maintain all existing deployment modes (stdio, self-hosted HTTP) without breaking changes.
-
-#### Scenario: Stdio mode unchanged
-
-- **WHEN** user runs `npm start` after Workers implementation
-- **THEN** stdio transport works identically to pre-Workers version
-
-#### Scenario: Self-hosted HTTP mode unchanged
-
-- **WHEN** user runs `TRANSPORT=http PORT=3000 npm start` after Workers implementation
-- **THEN** HTTP server works identically to pre-Workers version
-
-#### Scenario: Existing tests pass
-
-- **WHEN** user runs `npm test` after Workers implementation
-- **THEN** all 113 existing tests pass without modification
-
-#### Scenario: Node.js bundle unchanged
-
-- **WHEN** user runs `npm run build` after Workers implementation
-- **THEN** Node.js bundle (`dist/index.js`) is unchanged
-
----
-
-### Requirement: Development Workflow
-
-The system SHALL support efficient local development and testing of Workers deployment.
-
-#### Scenario: Local Workers testing
-
-- **WHEN** developer runs `npm run dev:worker`
-- **THEN** wrangler starts local server with hot reload
-
-#### Scenario: Quick iteration
-
-- **WHEN** developer modifies `src/worker.ts`
-- **THEN** wrangler automatically rebuilds and reloads
-
-#### Scenario: curl testing
-
-- **WHEN** developer sends curl request to local Workers
-- **THEN** response matches expected MCP protocol format
-
----
-
-### Requirement: Monitoring and Debugging
-
-The system SHALL provide access to Workers logs and metrics for troubleshooting.
-
-#### Scenario: Real-time logs
-
-- **WHEN** developer runs `wrangler tail`
-- **THEN** console.log output from worker appears in terminal
-
-#### Scenario: Error logs
-
-- **WHEN** worker throws exception
-- **THEN** stack trace appears in `wrangler tail` output
-
-#### Scenario: Cloudflare dashboard
-
-- **WHEN** user accesses Cloudflare Workers dashboard
-- **THEN** metrics show request count, error rate, and CPU time
-
----
-

package/openspec/specs/documentation-language/spec.md

@@ -1,32 +0,0 @@
-# documentation-language Specification
-
-## Purpose
-TBD - created by archiving change translate-project-to-english. Update Purpose after archive.
-## Requirements
-### Requirement: Project documentation in English
-
-The project SHALL provide all user-facing documentation in English to ensure accessibility for the international open data community.
-
-#### Scenario: English documentation
-Given a CKAN MCP Server project
-When a user reads the documentation
-Then the documentation is in English
-And code examples are in English
-And technical terms follow CKAN API terminology
-
-### Requirement: Preserve multilingual examples
-
-The project SHALL preserve non-English portal names, organization titles, or data values in their original language to accurately reflect real-world CKAN portals.
-
-#### Scenario: Italian portal example
-Given an example using dati.gov.it
-When the example references Italian organizations
-Then organization names remain in Italian (e.g., "Regione Siciliana")
-And descriptions are in English
-
-#### Scenario: Non-English data values
-Given an example query with data filters
-When the data contains non-English values
-Then those values are preserved in their original language
-And the surrounding documentation explains the context in English
-

package/openspec/specs/mcp-prompts/spec.md

@@ -1,26 +0,0 @@
-# mcp-prompts Specification
-
-## Purpose
-TBD - created by archiving change add-mcp-prompts. Update Purpose after archive.
-## Requirements
-### Requirement: Guided prompts are available
-The system SHALL expose a set of guided MCP prompts for common CKAN discovery workflows.
-
-#### Scenario: User requests a guided search prompt
-- **WHEN** a client lists MCP prompts
-- **THEN** the guided prompts are returned with name, description, and parameters
-
-### Requirement: Prompt output includes tool usage instructions
-Each guided prompt SHALL produce instructions that reference the appropriate CKAN tools and parameters.
-
-#### Scenario: Prompt generation for thematic search
-- **WHEN** the user generates a prompt for a specific theme and format
-- **THEN** the output includes the correct tool name and required parameters
-
-### Requirement: Prompt content is localized and consistent
-Guided prompts SHALL use consistent language and parameter naming aligned with CKAN tool schemas.
-
-#### Scenario: Prompt content consistency
-- **WHEN** a prompt is generated
-- **THEN** parameter names match the tool schema (e.g., `server_url`, `q`, `fq`, `rows`)
-