Aman-Amith-Shastry-scientific_computation_mcp

directional_deriv

Read-onlyIdempotent

    Computes symbolic directional derivative of scalar field along a vector direction.

    Args: f_str (str): Expression like "x*y*z". u (list[float]): Direction vector [vx, vy, vz]. unit (bool): True
    if u should be normalized before calculating directional derivative. Set to True by default.

    Returns:
        str: Symbolic result as string.

Input Schema

TableJSON Schema

Name	Required	Description
`u`	Yes	Direction as [vx, vy, vz]; trailing components may be omitted.
`unit`	No	Normalize the direction to unit length before differentiating.
`f_str`	Yes	Scalar function of x, y, z, e.g. "xyz".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 10, 2026
- addedInput schema / properties / f_str / description
```
Added value: +"Scalar function of x, y, z, e.g. \"x*y*z\"."
```
- addedInput schema / properties / u / description
```
Added value: +"Direction as [vx, vy, vz]; trailing components may be omitted."
```
- addedInput schema / properties / u / maxItems
```
Added value: +3
```
- addedInput schema / properties / u / minItems
```
Added value: +1
```
- addedInput schema / properties / unit / description
```
Added value: +"Normalize the direction to unit length before differentiating."
```
First observedJan 31, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the unit normalization default (unit=True) and that the result is a symbolic string, which are helpful behavioral details beyond annotations. It does not discuss limitations like variable assumptions or error handling, but these are minor for a pure computation tool.

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 description is compact, with clear docstring-like structure. It front-loads the main purpose, then lists parameters and return. Every sentence is informative, though the parameter listings partially mirror the schema, which is slightly redundant but not verbose.

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

Completeness4/5

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

Given the tool's moderate complexity, the output schema exists to describe return values, and the description covers the key inputs and behavior. It lacks deeper context like supported variable names or edge cases (e.g., zero vector), but for a symbolic math tool, the description is adequate. No major missing details for correct invocation.

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?

Schema coverage is 100%, so each parameter is already documented. The description adds the example expression "x*y*z" and the default for unit, but these are mostly redundant with schema descriptions. It does clarify that u is a direction vector and unit controls normalization, which aligns with schema. No significant additional meaning beyond schema.

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 clearly states it computes the symbolic directional derivative of a scalar field along a vector direction, specifying the math operation and the resource (scalar field). This distinguishes it from siblings like gradient, divergence, and curl, which are different vector calculus operations.

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

Usage Guidelines4/5

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

The description implies use for directional derivative calculations in vector calculus contexts; however, it does not explicitly state when to prefer this over siblings like gradient or when not to use it. The context of the tool name and the operation are clear enough for an agent to select it appropriately.

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

All Aman-Amith-Shastry-scientific_computation_mcp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.