--- name: wolfram-essentials description: "How to use the Wolfram connector well and safely: choosing between the Wolfram Language evaluator, the WolframAlpha factual query tool and the WolframContext tool, phrasing input so results can be checked, and handling the free remote-only service when results look wrong or it is unreachable. Use when the user asks to compute, calculate, convert units, look up curated facts or data with Wolfram, or asks why a Wolfram result looks wrong or is not coming back." --- # Use the Wolfram connector The connector gives you three tools backed by Wolfram's computation engine and curated knowledgebase. Your job is to route each question to the right tool, keep the input readable so the user can validate it, and say plainly when a result is not trustworthy. Use it when accuracy matters more than fluency: exact arithmetic, symbolic algebra, unit conversions, dated or measured facts. ## 1. Decide whether the connector is needed at all Call Wolfram when the answer depends on computation or on a specific curated fact (a population, a physical constant, a date difference, an integral). Do not call it for opinion, writing, planning or anything you can state with certainty and no computation. Say briefly why you are using it. ## 2. Pick the right tool Match the question to the tool by what kind of answer is wanted: - **`WolframLanguageEvaluator`**: you need a computation or a small program. Exact symbolic maths, solving equations, plotting, number theory, simulations, data transformations. You write Wolfram Language code, so keep it short and self-contained. - **`WolframAlpha`**: you need a factual answer to a natural-language question about the world (places, people, chemistry, weather-like stats, conversions written in English). It returns curated data, so phrase it as a question or a short query, not as code. - **`WolframContext`**: use it to get background on how to frame a Wolfram request before calling the other two when you are unsure of the right input form. Do not use it as a source of final answers. If one tool returns nothing usable, try the other only when the question genuinely fits it. Do not loop through all three hoping one answers. ## 3. Phrase input so the result is checkable - Put the **exact quantity and unit** in the input ("3.2 kg in pounds", not "that weight in pounds"). - For computation, write **the expression itself** and state the variable you are solving for. Keep the code visible so the user can read what was evaluated. - For factual queries, **name the entity and the date or context** ("population of Lyon in 2020", not "population of Lyon"). - Quote the input you sent alongside the answer. Readable input is the main way the user can verify you. ## 4. Verify before you report - Sanity-check magnitude and units. An answer ten times too big or in the wrong unit is a sign of a bad input, not a surprising truth. - For algebra, substitute the result back or ask for a numeric check. - When two answers conflict, report both with their inputs and say which you trust and why. ## 5. Handle limits and failures - The service is **remote only** and needs internet access. If the call fails with a connection or timeout error, say so and do not invent the answer. - The free personal tier has usage limits. If results stop arriving or are refused, report the limit as the likely cause and suggest the user check their access, rather than retrying in a tight loop. - The service cannot upload or download files, cannot use local files and cannot hold a persistent session. Do not ask it to work on the user's documents or to remember earlier calls. - If a result looks wrong, rerun once with a clearer, more explicit input before concluding the service is at fault. ## Common patterns and traps - **Hallucinated precision**: a confident decimal with no input shown. Always show the input that produced it. - **Unit drift**: a bare number with no unit gets treated as dimensionless. Restate units in the input. - **Ambiguous names**: a place or person with several matches. Name the disambiguating country, year or field. - **Code that is too clever**: a long multi-step Wolfram Language program is hard to validate. Split it into steps the user can read. - **Treating a factual lookup as current**: curated data can be dated. State the date the figure refers to when it matters. - **Silent failure**: a timeout reported as "no answer" hides that the service was down. Name the failure. ## Output ``` Question: Tool: Input sent: Result: Check: Caveats: ``` ## Rules - Never present a Wolfram result without showing the input that produced it. - Never invent a number when the service fails, times out or refuses; say it is unavailable. - Do not send the user's private data, chat history or documents through the tools; send only the specific query needed. - Do not treat WolframContext output as a final answer. - Every tool here runs computations and queries only; none changes data. If a future request asks to write, save or change anything, wait for the user's explicit yes before doing it. ## Done when - The question was routed to the tool that fits its kind of answer, and the input is quoted. - The result has been sanity-checked, or the check is listed as not done. - Any failure, limit or ambiguity is stated plainly rather than hidden.