3 ms·

Help: Using reflection to discovery and invoke methods

2 points by ddddazed 3mo ago

Hi HN, I was working on different MCP project, every time I have to write MCP server as wrapper of methods\functions. Then I realize that with memory managed languages I can use reflection to scan methods directly insiede the application and then just fire. Yes, I still need to write json file with name,arguments and description but this is fine to me, there are already program to do this in automatic way. Now I was just wondering if some one else has already use this kind of pattern over MCP to avoid wrapper and unlock potential things: - Avoid update any part of the code, just update json. - Try to unlock potential thigs that are has not been scheduled on code, with this the agent has potentially access to any part of code. It's just an experiment to see how much potential it unlocks and whether it makes sense. Has anyone ever tried this technical approach? Any general feedback, or input from anyone who has already tried it?

jdw64 3mo ago
When I think about the structure, I automatically recall that when MCP calls are made, they do perform a search, but the model's tool descriptions and input/output are included together. So the list of tools becomes longer. Reflection might reduce the cost of writing wrappers, but it seems likely to use more tokens. There are also security concerns, and there are MCP host issues as well. I don't know exactly how the agent calls tools, and there's caching involved. The reason everyone is using similar techniques for these tools is probably that the harness environment surrounding agents differs from company to company, making it hard to specialize. It's good to come up with something new, but ultimately, industry standards are what matter
- ddddazed 3mo ago
  Thanks! It shows me that you really understood what I was trying to say. And yes, the issue of “security” is a concern I share in fact, it involves memory injection, and more than the cost on the JSON side, it’s this aspect that doesn’t quite convince me. I already have everything up and running (as an experiment), and the possibilities are expanding. Your second valid point is about standards, but here I’m sticking to my simple experiment, and I was interested in hearing perspectives like this—not to propose a new stack, but rather to explore whether a new layer could unlock new opportunities. Legacy software or the ability to modify graphics at runtime come to mind, this part has also been tested. It works, but I’ve never seen a real-world application for it, and it’s not my job to create products or identify market needs. The interesting part and the one I was seeking feedback and ideas on—was the technical aspect. Thank you so much for your response.

2 points by ddddazed 3mo ago

jdw64 3mo ago

When I think about the structure, I automatically recall that when MCP calls are made, they do perform a search, but the model's tool descriptions and input/output are included together. So the list of tools becomes longer. Reflection might reduce the cost of writing wrappers, but it seems likely to use more tokens. There are also security concerns, and there are MCP host issues as well. I don't know exactly how the agent calls tools, and there's caching involved. The reason everyone is using similar techniques for these tools is probably that the harness environment surrounding agents differs from company to company, making it hard to specialize. It's good to come up with something new, but ultimately, industry standards are what matter

ddddazed 3mo ago
Thanks! It shows me that you really understood what I was trying to say. And yes, the issue of “security” is a concern I share in fact, it involves memory injection, and more than the cost on the JSON side, it’s this aspect that doesn’t quite convince me. I already have everything up and running (as an experiment), and the possibilities are expanding. Your second valid point is about standards, but here I’m sticking to my simple experiment, and I was interested in hearing perspectives like this—not to propose a new stack, but rather to explore whether a new layer could unlock new opportunities. Legacy software or the ability to modify graphics at runtime come to mind, this part has also been tested. It works, but I’ve never seen a real-world application for it, and it’s not my job to create products or identify market needs. The interesting part and the one I was seeking feedback and ideas on—was the technical aspect. Thank you so much for your response.