Open
Conversation
Enable the GET /api/v2/auditlog endpoint as an MCP tool so AI agents can query flag change history, filter by resource specifier, and paginate through audit log entries. Made-with: Cursor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related issues
This addresses a gap in the current MCP tool surface — the audit log API is already in the OpenAPI spec and has Speakeasy naming hints in
schemas/suggestions.yaml, but is not exposed as an MCP tool.Describe the solution you've provided
Adds a single entry to
schemas/mcp-enable-tools.yamlto enable theGET /api/v2/auditlogendpoint as a read-only MCP tool (get-audit-log-entries).The tool description includes practical guidance for AI agents:
proj/<projectKey>:env/<envKey>:flag/<flagKey>)before/afterUnix epoch timestampsNote: This PR only contains the overlay change. Since the codebase is generated by Speakeasy and external contributors cannot run
speakeasy runagainst the LaunchDarkly registry, the generated output (funcs, tools, models, server registration) will need to be produced by the maintainers.Describe alternatives you've considered
Context window optimization
Adding more tools increases the MCP context window footprint for all users, even those who don't need audit log access. The existing
--toolflag allows whitelisting specific tools, but there's no easy way to exclude a single tool without listing all the others.A few ideas worth considering (as a separate effort):
--exclude-toolflag — inverse of--tool, letting users opt out of specific tools without listing everything else.--tool-group flags,--tool-group audit-log,--tool-group ai-configs) — would let users selectively load categories of tools. This would be especially valuable since AI Configs alone accounts for 11 of the 20 current tools.--tooland--scope— these existing flags aren't mentioned in the README. Simply documenting them would help users who want to reduce context window usage today.Additional context
schemas/openapi.jsonwith operationIdgetAuditLogEntriesschemas/suggestions.yamlalready definesx-speakeasy-group: auditLogandx-speakeasy-name-override: listEntriesfor this endpointread-only