Add documentation search and SDK discovery tools for improved developer experience

[linben]

Problem Statement

Currently, users of the Teradata MCP server need to manually search external documentation sites (docs.teradata.com, developer portals, SDK references) when they have questions about Teradata features, APIs, or best practices. This creates friction in the development workflow and interrupts the conversational AI experience.

Current Limitations

• No real-time access to official Teradata documentation
• Users must context-switch to browsers to find SDK information, API references, or tutorials
• No integrated way to search for code examples or implementation guides
• Limited discoverability of Teradata features and capabilities

Proposed Solution

Add a doc tool that provides:

• Real-time search across official Teradata documentation sites
• API reference lookup with syntax and parameter information
• Contextual help based on user queries

Use Cases

• Developer onboarding: "How do I connect to VantageCloud Lake using Python?"
• Feature discovery: "What analytics functions are available for time series data?"
• Troubleshooting: "How do I resolve connection timeout errors?"
• Best practices: "What are the recommended data modeling patterns?"
• Architecture questions: "What's the difference between VantageCloud Enterprise and Lake?"

[dtehan-td]

Ben,
I have given this some thought. There might be two paths for this:

Path 1
It seems that we could add a tool that could do a focused web search on the Teradata documentation to retrieve appropriate context. https://docs.teradata.com/search/all?query={query}&content-lang=en-US
We would need to add some kind of web search library to the MCP server. I do have a concern that the returned content is not always relevant as the repository contains all versions of documentation.

Path 2
Would be to have a curated set of documentation for the customers system that we vectorize into Teradata and use similarity to return the appropriate context. This approach would work, but differently on the two main versions available today (17.20 and 20.0).

I like path 2 as it does not require a internet access from the MCP server to work. We have plenty of examples of vectorizing PDFs and already have a tool set for similarity search.

@remi-td anything you would like to add.

[linben]

Direct HTTP fetches will be quicker to iterate on and requires less maintenance. For prod, the vector db approach makes sense (faster queries, semantic search, offline capabilities).

Here's an example from the AWS Docs MCP server: https://github.com/awslabs/mcp/blob/main/src/aws-documentation-mcp-server/awslabs/aws_documentation_mcp_server/server_aws.py

Happy to collaborate on this.

[dtehan-td]

Ben,
I am having an internal conversation to ensure that this is not already on the radar for the people that manage the documentation repository. I will reach out once I understand the corporate POV