[HN Gopher] Adventures in Symbolic Algebra with Model Context Pr...
       ___________________________________________________________________
        
       Adventures in Symbolic Algebra with Model Context Protocol
        
       Author : freediver
       Score  : 76 points
       Date   : 2025-05-22 13:59 UTC (9 hours ago)
        
 (HTM) web link (www.stephendiehl.com)
 (TXT) w3m dump (www.stephendiehl.com)
        
       | behnamoh wrote:
       | So, we've come full circle to symbolic AI! This article
       | essentially suggests that LLMs could be effective translators of
       | our requests to command-line code or input to symbolic AI
       | software, which would then yield precise solutions. However, I
       | feel this approach is overly mechanical, and I don't believe AGI
       | would be achieved by creating thousands, if not millions, of MCP
       | servers on our machines. This is especially true because MCP
       | lacks scalability, and anyone who has had to send more than three
       | or four function schemas to a language model knows that excessive
       | JSON schema complexity confuses the model and reduces its
       | performance.
        
         | pona-a wrote:
         | I'm reminded of what happened in the later years of Cyc. They
         | found their logical framework didn't address certain common
         | problems, so they kept adding specialized hard-coded solutions
         | in Lisp. LLMs are headed for AI autumn.
        
       | arunbahl wrote:
       | Awesome stuff! We use a similar approach (without MCP) to great
       | effect with Prolog currently and feels like we're only just
       | starting to scratch the surface here.
       | 
       | A great paper from Nasim Borazjanizadeh and Steven Piantadosi at
       | UC Berkeley for those interested: Reliable Reasoning Beyond
       | Natural Language https://arxiv.org/abs/2407.11373
       | 
       | For anyone digging in who wants to hack on this: arun [at]
       | aloe.inc
        
       | tpurves wrote:
       | Wonderfully cheeky but also helpfully informative writeup. Also
       | appreciate the hat-tip to all the (as yet) unsolved security
       | issues. Clearly MCP is onto something important, although
       | undoubtedly the standard (or some replacement standard) will
       | mature a fair bit before we're done with it. The flip side to
       | that is, MCPs are probably as 'easier' to experiment with now
       | than they are ever going to be.
        
       | ash-ali wrote:
       | I think this is the proper way to use llms for tasks that require
       | high fidelity. currently im working on binary analysis using llms
       | for natural language and letting ghidra/codeql do the symbolic
       | work. scalability is a massive issue, perhaps the biggest besides
       | fidelity.
       | 
       | its interesting to see many people come to the same neuro-
       | symbolic conclusion around the same time.
        
       | amelius wrote:
       | How does the LLM know that it can use the factor tool to factor
       | integers? Just by looking at the string "factor an integer"?
        
         | manojlds wrote:
         | Yup
         | 
         | this is what the tools response for the mcp server looks like:
         | 
         | { tools: [ 0: { name: "factor" description: "Factor an integer"
         | inputSchema: { ... } 4 items } ] }
        
         | snek_case wrote:
         | They give it a list of tool commands it can use in the context
         | I believe.
        
         | svat wrote:
         | Yes, and I believe this is what the article is referring to
         | when it says _"a stochastic black box that communicates through
         | a complex web of JSON schemas attached to docstring
         | annotations"._ Specifically, in the function definition:
         | @mcp.tool()         def factor(a: int) -> int:
         | """Factor an integer"""             return factor_number(a)
         | 
         | the decorator `@mcp.tool()` does something behind the scenes to
         | set up the right thing using the docstring of the function.
         | 
         | The documentation and source code seem to be:
         | 
         | - (official SDK):
         | https://github.com/modelcontextprotocol/python-sdk/blob/e80c...
         | -> using the function's docstring:
         | https://github.com/modelcontextprotocol/python-sdk/blob/e80c...
         | 
         | - (v2?): https://gofastmcp.com/servers/tools#the-%40tool-
         | decorator and
         | https://github.com/jlowin/fastmcp/blob/998de22a6e76fc8ae323e...
         | -> using the function's docstring:
         | https://github.com/jlowin/fastmcp/blob/998de22a6e76fc8ae323e...
        
       | rjeli wrote:
       | _the implementations have a distinctly "I wrote this at a 3 AM
       | hackathon" vibe_
       | 
       |  _The LLM handles the natural language interaction and
       | orchestration, while the computer algebra system does what it
       | does best ... exact symbolic manipulation._
       | 
       | this smells like claude :D
        
       | jgalt212 wrote:
       | > But let's not let a potential rootkit get in the way of a fun
       | weekend experiment.
       | 
       | Great quote.
        
       | FilosofumRex wrote:
       | > So, we've come full circle to symbolic AI!
       | 
       | Yes, but from a business point of view, NLP based GUIs have been
       | the holy grail of marketing and customer support, especially in
       | STEM apps market.
       | 
       | Case in point, Wolfram Alpha is not much more than an attempt to
       | market Mathematica to lazy and failing college students. If that
       | cost, and localization, can be offloaded to LLMs as the universal
       | front end to technical software, it'd free up SWE resources to
       | focus on core functionality.
       | 
       | If Magma, my favorite math/cryptography tool, had an LLM
       | frontend, I could save time wasted onboarding new cryptographers.
       | 
       | https://magma.maths.usyd.edu.au/calc/
        
       | Iwan-Zotow wrote:
       | Curious if this could be done for Mathematica. SymPy is kind of
       | ...
        
       | Hugsun wrote:
       | I was very pleased to discover that Mistral's Le Chat has inbuilt
       | support for python code execution and sympy is importable.
       | 
       | It will regularly use it and reliably when asked to.
        
       | crystal_revenge wrote:
       | I really appreciate Stephen's mixture of skepticism combined with
       | genuine interest in experimenting with these tools. Most MCP
       | posts I've read have been so much hype I've been left with no
       | clue what MCP _actually_ does. This is the first article I 've
       | read on the topic that earnestly makes me want to start messing
       | around with MCP for fun (and makes it clear how to get started).
       | 
       | It's a bit unfortunate that the field is so dominated by extremes
       | of hype and skepticism, both of which aren't particularly helpful
       | to getting problems really solved.
        
         | beastman82 wrote:
         | It's just good writing. Funny, insightful, detailed.
        
       | mhh__ wrote:
       | I like this type of flow.
       | 
       | On tensor notation: Tensor indices aren't bad (a good notation
       | should guide a calculation and they do) but I can't help but feel
       | they're far too error prone.
       | 
       | What are the alternatives? Penrose diagrams?
        
       | 0cf8612b2e1e wrote:
       | Tangentially, are there any symbolic algebra systems that can
       | handle millions of equations?
       | 
       | I have never used a symbolic algebra system, but came across a
       | problem where I am trying to model a deterministic simulation
       | system. I can write out the computation graph (~20 million
       | equations for final state), but Sympy chokes on seemingly dozens
       | of symbols. No hope of processing the final state or being able
       | to express a simulation state in terms of my desired input
       | variables.
       | 
       | Not sure if my expectations are mismatched with reality, I am
       | hugely bungling the tool, or Sympy has laughable performance vs
       | the more capable commercial options.
        
         | 6gvONxR4sf7o wrote:
         | Presumably if you have 20 million equations, they came from a
         | program that's has fewer than 20 million moving parts, like if
         | they came from A x = b where the matrix A has 20M entries. The
         | gist is either exploit structure to make a massive number of
         | small equations or keep the symbols in their "natural" form
         | instead of reducing to scalars, and work with more advanced CAS
         | functionality (like, you might have to learn about
         | noncommutative variations on groebner bases). But also, yes
         | sympy is ultra slow with some things.
        
       ___________________________________________________________________
       (page generated 2025-05-22 23:01 UTC)