[REF] livekit-agent: derive tool schemas from signatures - #194
Merged
Conversation
The server declared four tools as hand-written JSON next to a name-dispatch table, so the contract and the code reading the arguments were two independent sources of truth with nothing reconciling them. Renaming an argument in one place left everything compiling and every test green. FastMCP builds the schema from the function signature, which makes that drift unrepresentable. It ships in the pinned mcp 1.x, so this needs no dependency move, and it is the same shape as the MCPServer API that replaces it in 2.0 — groundwork for #190 rather than a detour. Surface verified unchanged against the live server: same four names, same required arguments, every per-argument description preserved. structured_output is off so the wire response stays what it was. 61 lines shorter.
The ergonomic server API is FastMCP on mcp 1.x and MCPServer on 2.x. They are identical for what this file uses — same @tool parameters, same run_stdio_async, same emitted schema, verified by running one file under both. Importing whichever is present means the major can be switched from pyproject alone, so trying 2.0 costs one line and rolls back in one line, instead of riding on a rewrite that would have to be undone.
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
1 participant
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.
Pilot for #190, on the smallest of the three servers that still use the
decorator API mcp 2.0 dropped.
Why this is worth doing on its own
The four tools were declared as hand-written JSON schemas beside a
if name == ...dispatch table. The declared contract and the code readingargs.get(...)were two independent sources of truth, and nothing reconciledthem — rename an argument in one and everything still compiles, every test
still passes, and the agent gets an incomprehensible failure at runtime.
Deriving the schema from the signature makes that drift unrepresentable.
Why it does not need the 2.0 move
FastMCPships in the pinned mcp 1.x and mirrors theMCPServerAPI thatreplaces it in 2.0, so this lands today and shortens the eventual migration
instead of competing with it.
Verified against the live server, not by inspection
Same four names, same required arguments (
start_voice_call→user_id,end_voice_call→room_name,get_call_link→user_id,list_active_calls→ none), and every per-argument description preserved.structured_output=Falsekeeps the wire response exactly what it was.61 lines shorter.
Tests
Five, spoken over stdio through the gateway the way production does — they were
run against the real server, not mocked. One of them asserts every tool is named
in the provider allowlist, since a tool renamed on the server side otherwise
drops out of an agent's reach silently. They skip where the
livekitextra isabsent; CI installs it.