Add title support via ToolAnnotations when reading OpenAPI specifications

Summary

Currently, when converting OpenAPI operations to MCP tools, the Tool.title field is not being set. This field is meant for human-readable display names in UI contexts, while the name field is for programmatic use.

Problem

Looking at the current implementation in src/server.rs:

Tool {
    name: metadata.name.clone().into(),
    description: Some(metadata.description.clone().into()),
    input_schema,
    output_schema,
    annotations: None,
    // title field is missing!
}

The MCP schema specification states that Tool.title is:

"Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology."

Proposed Solution

Use the OpenAPI summary field as the source for Tool.title. The summary field in OpenAPI operations is designed to be a short, human-readable title.

Examples from Pet Store OpenAPI:

  • Operation: findPetsByStatus → Title: "Finds Pets by status"
  • Operation: getPetById → Title: "Find pet by ID"
  • Operation: addPet → Title: "Add a new pet to the store"

Implementation Tasks

  • Add title: Option<String> field to ToolMetadata struct in src/server.rs
  • Update ToolGenerator::generate_tool_metadata() in src/tool_generator.rs to extract the summary field from OpenAPI operations
  • Update the From<&ToolMetadata> for Tool implementation to map the title field (via ToolAnnotations)
  • Update test snapshots to include title in ToolAnnotations
  • Update existing tests that create ToolMetadata instances to include the new field
  • Test with real OpenAPI specs (like Pet Store) to ensure the title field is properly displayed
  • Run cargo fmt, clippy, and build after each task
  • Update task lists in both issue and MR descriptions after each task
  • Add MR comments to explain work done after each task

Benefits

  • Better user experience with human-readable tool names in UI
  • Maintains backward compatibility (title is optional)
  • Leverages existing OpenAPI best practices
  • Clear separation between programmatic names (operationId) and display names (summary)
Edited by Wally The Wobot