Skip to main content
Glama

Aman-Amith-Shastry-scientific_computation_mcp

curl

Read-onlyIdempotent
    Computes the symbolic curl of a vector field, optionally evaluated at a point.

    Args:
        f_str (str): A string representing the vector field in list format (e.g., "[x+y, x, 2*z]").
        point (list[float], optional): A list of coordinates [x, y, z] to evaluate the curl numerically.

    Returns:
        dict: A dictionary with the symbolic curl as a string, and optionally the evaluated vector.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
f_strYesVector field in bracketed list form with components in x, y, z, e.g. "[x+y, x, 2*z]".
pointNoOptional [x, y, z] coordinates at which to evaluate the result numerically.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / f_str / description
      Added value: +"Vector field in bracketed list form with components in x, y, z, e.g. \"[x+y, x, 2*z]\"."
    • addedInput schema / properties / point / anyOf
      Added value: +[
      +  {
      +    "items": {
      +      "type": "number"
      +    },
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / point / description
      Added value: +"Optional [x, y, z] coordinates at which to evaluate the result numerically."
    • removedInput schema / properties / point / items
      Removed value: -{
      -  "type": "number"
      -}
    • removedInput schema / properties / point / type
      Removed value: -"array"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "curlDictOutput",
      +  "type": "object"
      +}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description only needs to add behavioral context. It adds that the curl is computed symbolically by default and can be numerically evaluated at a point, plus the return format is a dict with a string and optionally a numeric vector. This goes beyond the annotation coverage and gives useful insight.

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?

The first sentence is an effective, front-loaded purpose. The Args/Returns sections mirror the schema, which introduces minor redundancy, but the structure is clean and the text remains short. It could be trimmed to remove duplication, but overall it is well-organized.

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

Completeness5/5

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

Given the limited 2-param schema, full schema descriptions, and readOnly/idempotent hints from annotations, this description is sufficient. It mentions the symbolic versus numeric behavior, the Return dict, and doesn't need to explain return types because the output schema exists. There are no missing pieces for correct calling.

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

Parameters3/5

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

The input schema fully describes both parameters (coverage 100%), with the same explanations for f_str and point that appear in the description. The description repeats those semantics but adds no new meaning beyond the schema, so it stays at the baseline 3.

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

Purpose5/5

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

The description states a specific verb and resource – 'computes the symbolic curl of a vector field' – and clearly distinguishes this from the other vector calculus siblings (divergence, gradient, laplacian). It also mentions the optional numeric evaluation, which helps an agent understand the tool's unique capability.

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 description implies when to use the tool (whenever a curl of a vector field is needed), but it gives no explicit routing to alternatives such as divergence or gradient. An agent can infer usage from the purpose, but there is no explicit 'use this instead of' guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.