Both tools accept either path: use_reflection asks the server to describe itself, while proto_files and import_paths cover a target that has reflection turned off, which production services frequently do. The scope is deliberately narrow — grpc_call is documented for unary methods, so streaming is not what this is for. Within that scope the pairing is complete: grpc_describe tells you the message shape, grpc_call sends one built to match, and headers, plaintext and timeout_ms handle the parts of a real connection that a schema does not describe.
A gRPC client exposing 2 tools: one that describes services, methods and message symbols, and one that invokes a unary method from a JSON request body.
- Discovery before invocation: grpc_describe resolves a service, a method or a message symbol so the request shape is known before anything is sent.
- Calls written as JSON: grpc_call takes request_json and a fully qualified method, returning the response without any generated stub in between.
- Either source of schema: both tools work from server reflection with use_reflection, or from local proto_files resolved against import_paths.
- The connection details a real target needs: headers carries whatever metadata the service authenticates on, plaintext covers a target without TLS, and timeout_ms bounds the call.
Nothing to configure for the server itself. Reaching a target needs either reflection enabled on it or the .proto files and their import paths present on the machine the server runs on, plus whatever credential that service expects, which travels in headers rather than in configuration.
One command — npx -y @grulex/grpc-invoke-mcp@latest