Skip to main content
Glama
Sign In
mathematica-skill

mathematica-skill

by 1837620622
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mathematica_plan

Parses task JSON and returns an execution plan without launching Mathematica, so agents can validate and structure Wolfram Language work before running computations.

Instructions

解析任务 JSON 并返回执行计划，不启动 Mathematica。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_path": "<task_path>"
    },
    "name": "mathematica_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden; it does disclose the key non-effect trait (no Mathematica process is launched), which is valuable. However, it says nothing about what the returned plan looks like, whether the task file is validated or modified, or how missing/invalid paths are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence that front-loads the core action and appends the key non-behavioral constraint; there is no filler. It is compact to the point of omitting information an agent needs, but nothing written is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameter that is fully undocumented and with no output schema and no annotations, the description is too thin. An agent must guess what to pass and cannot anticipate what the returned plan contains or how failures surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter, task_path, with 0% schema description coverage, so the description must compensate — and it does not. It never explains whether task_path is a file path, a directory, or a JSON string, nor what format the file must have.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and object: it parses a task JSON and returns an execution plan. It also explicitly rules out the execution behavior of siblings like mathematica_run and mathematica_compute ('does not start Mathematica'), which helps differentiate. What a 'task JSON' contains is left undefined, which slightly weakens the clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'does not start Mathematica' implies that this is a dry-run/planning step before running or evaluating, but the description never states when to prefer it over mathematica_build, mathematica_verify, or mathematica_run. Usage is only inferable, not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools