Skip to content

feat: expose variableNames to retrieve all parameters from UriTemplate #188

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Apr 7, 2025

Conversation

li-yechao
Copy link
Contributor

@li-yechao li-yechao commented Mar 13, 2025

Added support for retrieving all parameter names from a UriTemplate.

Motivation and Context

Currently, there is no built-in way to extract all parameter names from a UriTemplate. This feature enables developers to programmatically access all variable names within a template, making it easier to handle dynamic URL generation and validation.

How Has This Been Tested?

  • Added unit tests to verify that variableNames correctly extracts parameter names from various URI templates.
  • Tested in a real application scenario to ensure compatibility with existing URI parsing logic.

Breaking Changes

No breaking changes. This is a non-breaking enhancement.

Types of changes

  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

This feature is particularly useful for scenarios where developers need to inspect or manipulate URI templates dynamically.

Copy link
Member

@jspahrsummers jspahrsummers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@jspahrsummers jspahrsummers merged commit b5024bf into modelcontextprotocol:main Apr 7, 2025
2 checks passed
Pizzaface pushed a commit to RewstApp/mcp-inspector that referenced this pull request May 2, 2025
* This fixes modelcontextprotocol#188
* In App.tsx
  - import LoggingLevel from sdk
  - add [logLevel, setLogLevel] useState with value of type LoggingLevel initialized to "debug"
  - add useEffect that stores the new logLevel in localStorage as "logLevel"
  - added sendLogLevelRequest function that takes a level argument of type LoggingLevel and sends the appropriate request. It calls setLogLevel when done, to update the local UI
  - pass logLevel and sendLogLevelRequest to Sidebar component as props
* In Sidebar.tsx
  - Import LoggingLevel and LoggingLevelSchema from sdk
  - add props and prop types for  logLevel and sendLogLevelRequest and loggingSupported
  - add Select component populated with the enum values of LoggingLevelSchema, shown only if loggingSupported is true and connectionStatus is "connected"
*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants