Version 1.4.2

What's Changed

Improvements

• Enhanced Error Handling: Added better feedback when LLMs attempt to run invalid query types
• Improved User Guidance: When invalid query types are used, the system now provides clear instructions to use get_term_info first to discover available query types
• Updated Tool Descriptions: Enhanced documentation to emphasize the importance of checking available queries before running them

Technical Details

• Modified handleRunQuery function to detect API error responses and provide helpful guidance
• Updated tool descriptions to prevent hallucinated query types
• Version bump to 1.4.2

This release improves the reliability and user experience when working with VirtualFlyBrain queries by ensuring LLMs follow the correct workflow of checking available query types before attempting to run them.

Release v1.4.1

Patch release with documentation improvements

Documentation Updates:

• Comprehensive documentation for new search_terms parameters
• Updated README.md with complete parameter descriptions
• Enhanced LLM_GUIDANCE.md with usage examples and best practices
• Added examples in examples.md for minimize_results and auto_fetch_term_info
• Updated TECHNICAL.md with enhanced search_terms description
• Improved best practices section for efficient searching

Maintenance:

• Version bump to 1.4.1
• All version references updated consistently

Release v1.4.0

Add optional parameters to search_terms tool for result minimization and auto term-info fetching

New Features:

• Add start, rows, minimize_results, and auto_fetch_term_info parameters to search_terms tool
• minimize_results: When true, limits results to top 10 for initial searches and adds truncation metadata
• auto_fetch_term_info: When true and an exact match is found, automatically fetches and includes term info in the response
• Maintains full backward compatibility with existing clients

Improvements:

• Better pagination support with start and rows parameters
• Reduced LLM context overhead for clients that opt into minimization
• Enhanced search result handling for exact matches

Documentation:

• Updated README.md, LLM_GUIDANCE.md, examples.md, and TECHNICAL.md
• Added comprehensive examples and usage patterns for new parameters
• Updated best practices for efficient searching

v1.3.5

What's Changed

Bug Fix

• Redirect misused tool names in run_query: When LLMs incorrectly pass tool names (e.g. get_term_info, search_terms) as query_type to run_query, the server now gracefully handles the mistake instead of returning errors that cause retry loops:
  • query_type: "get_term_info" → silently redirects to get_term_info handler, returns results with a corrective note
  • query_type: "search_terms" → returns a helpful message explaining it's a separate tool

Improvement

• Enriched run_query tool description: The description now lists valid query types grouped by entity type (templates, neurons, classes), explicitly warns against using tool names as query types, and instructs LLMs to call get_term_info first to discover available queries for a given ID

v1.3.4

Improvement

Better handling of missing term info

When the upstream VFB API returns null for a get_term_info or run_query call, the MCP server now returns a descriptive message instead of passing through a raw null.

Before:

null

After:

No term info found for ID "VFB_00120000". This ID may not exist, may be deprecated, or may not yet be indexed in the term info API. Try using the search_terms tool to verify the ID exists.

This helps AI clients understand the issue and take corrective action (e.g., using search_terms to verify the ID).

Note: The specific case of VFB_00120000 ("Adult T1 Leg (Kuan2020)") is an upstream VFB data issue — the term exists in the Solr search index but returns null from the term info API. This has been reported separately.

v1.3.3

Bug Fix

Fix multi-pod load balancer session routing (VS Code Copilot compatibility)

Problem: When deployed with multiple pods behind a load balancer, MCP clients (VS Code Copilot, etc.) would fail with "Bad Request: No valid session ID provided" because requests could be routed to a pod that doesn't hold the client's session. MCP clients don't send cookies, so sticky session routing doesn't work.

Root cause: The server returned HTTP 400 for unknown session IDs. Clients treat 400 as a fatal error and give up.

Fix: Return HTTP 404 for unknown session IDs, as required by the MCP specification:

"The server MAY terminate the session at any time, after which it MUST respond to requests containing that session ID with HTTP 404 Not Found. When a client receives HTTP 404 in response to a request containing an Mcp-Session-Id, it MUST start a new session by sending a new InitializeRequest without a session ID attached."

This applies to all three HTTP methods (POST, GET, DELETE). Clients will now automatically re-initialize when they hit a different pod, creating a new session seamlessly.

Also includes (from v1.3.2)

• Handle JSON-RPC batch initialize requests for broader client compatibility

v1.3.2

Bug Fix

VS Code Copilot compatibility fix

Fixed an issue where VS Code Copilot (and potentially other MCP clients) could not connect to the server, failing with:

Bad Request: No valid session ID provided

Root cause: The server's initialize request detection only validated single JSON-RPC messages, but VS Code Copilot sends the initialize request as a JSON-RPC batch (array). This caused every connection attempt to be rejected before the SDK transport could process it.

Changes:

• Handle both single and batched JSON-RPC initialize requests
• Accept initialize requests even when a stale session ID header is present (e.g., during client retries)
• Bump version to 1.3.2

Release v1.3.1

Version 1.3.1 - Added Gemini integration instructions to all documentation and web interface

VFB3-MCP Server v1.3.0

VFB3-MCP Server v1.3.0

MCP Registry Integration — Adds support for publishing and authenticating with the Model Context Protocol Registry.

Live endpoint: `https://vfb3-mcp.virtualflybrain.org\`

---

What's New

MCP Registry HTTP Authentication

• New Authentication Endpoint: `/.well-known/mcp-registry-auth` returns authentication proof for MCP Registry verification
• Environment Variable: `MCP_REGISTRY_AUTH` configures the authentication proof (optional)
• Registry Metadata: Updated `server.json` with MCP registry schema compliance, including remotes configuration
• Automated Publishing: New GitHub Actions workflow (`publish-mcp.yml`) that publishes to MCP Registry on version tag pushes
• Deployment Updates: Added `MCP_REGISTRY_AUTH` environment variable to Docker Compose and Kubernetes manifests

Deployment Configuration

• Docker Compose: Added optional `MCP_REGISTRY_AUTH` environment variable
• Kubernetes: Added secret-based `MCP_REGISTRY_AUTH` configuration in deployment manifest
• CI/CD: Automated MCP Registry publishing on tag creation with domain authentication

---

Backward Compatibility

Fully backward compatible — MCP Registry authentication is optional and doesn't affect existing functionality.

---

Full Changelog

Compare: `v1.2.4...v1.3.0`

New Features

• Add MCP Registry HTTP authentication support
• Add automated MCP Registry publishing workflow
• Update server.json with MCP registry metadata

Configuration

• Add MCP_REGISTRY_AUTH environment variable to deployments
• Update version to 1.3.0 across all manifests

---

About MCP Registry

The Model Context Protocol Registry provides a centralized directory for discovering and connecting to MCP servers. This integration allows users to easily discover and connect to the VFB3-MCP server through MCP-compatible clients.