Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scicalc-mcp solve the linear system 2x+3y=5, x-2y=4"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
一个提供数学与科学计算能力的 MCP（Model Context Protocol）服务，底层使用 NumPy、pandas、SciPy 和 Matplotlib。可在本地通过 stdio 供 Kiro 使用，也可以 容器化后部署到 Google Cloud，供 Kiro 通过 HTTPS 远程访问。远程部署提供两种方式： 以 Kubernetes（GKE）部署，或在单台虚拟机上用 docker-compose 搭配 Caddy 自动 HTTPS。
共注册 19 个工具，按领域划分：
线性代数（NumPy）：matrix_multiply、matrix_inverse、determinant、
solve_linear_system、eigen
统计（NumPy/SciPy）：describe、correlation、t_test、linear_regression
科学计算（SciPy）：integrate_function、find_root、minimize_function、
interpolate_values
数据处理（pandas）：dataframe_describe、dataframe_groupby_aggregate、
dataframe_correlation_matrix
绘图（Matplotlib，返回 PNG）：plot_line、plot_function、plot_histogram
涉及函数表达式的工具（积分、求根、绘图等）使用受限的安全求值器，仅允许 白名单内的数学函数与常量，避免任意代码执行。
Related MCP server: Math-MCP
# 创建并激活虚拟环境（若尚未创建）
python -m venv .venv
.\.venv\Scripts\Activate.ps1
# 安装项目及依赖
python -m pip install -e .
# 冒烟测试：列出已注册的工具
python scripts\smoke_test.py默认传输方式为 stdio，适合本地在 IDE 中直接调用。
编辑用户级或工作区级的 mcp.json（用户级路径：~/.kiro/settings/mcp.json）：
{
"mcpServers": {
"scicalc": {
"command": "d:\\dev\\Python\\python_mcp\\.venv\\Scripts\\scicalc-mcp.exe",
"args": [],
"env": { "MCP_TRANSPORT": "stdio" },
"disabled": false,
"autoApprove": []
}
}
}保存后在 Kiro 的 MCP Server 视图中重新连接即可。
# 构建镜像
docker build -t scicalc-mcp:latest .
# 本地以 HTTP 传输方式运行（映射到 8000 端口）
docker run --rm -p 8000:8000 scicalc-mcp:latest容器默认使用 streamable-http 传输，端点为 http://<host>:8000/mcp。
前置条件：已安装 gcloud、kubectl，并已创建 GKE 集群与 Artifact Registry 仓库。
# 1) 设置变量（按需替换）
$PROJECT_ID = "your-project-id"
$REGION = "asia-east1"
$REPO = "mcp"
$IMAGE = "$REGION-docker.pkg.dev/$PROJECT_ID/$REPO/scicalc-mcp:latest"
# 2) 配置 Docker 认证并构建、推送镜像
gcloud auth configure-docker "$REGION-docker.pkg.dev"
docker build -t $IMAGE .
docker push $IMAGE
# 3) 获取集群凭据
gcloud container clusters get-credentials <CLUSTER_NAME> --region $REGION --project $PROJECT_ID
# 4) 将 k8s/deployment.yaml 中的镜像地址替换为 $IMAGE，然后应用清单
kubectl apply -f k8s\deployment.yaml
kubectl apply -f k8s\service.yaml
kubectl apply -f k8s\ingress.yaml
# 5) 查看 Ingress 分配的外部 IP
kubectl get ingress scicalc-mcpIngress 就绪后，MCP 端点为 http://<EXTERNAL_IP>/mcp。
生产环境建议启用 HTTPS：预留全局静态 IP、创建
ManagedCertificate，并在k8s/ingress.yaml中取消对应注释。此外应在服务前增加鉴权（例如网关层的 认证、IAP 或 API 网关），因为该服务本身不含访问控制。
如果不需要 Kubernetes，只想在一台虚拟机（如 GCE 实例）上快速跑起来并让
Kiro 通过 HTTPS 远程访问，用 docker-compose 搭配 Caddy 反向代理是最简单的方式。
项目根目录已提供 docker-compose.yml 与 Caddyfile。
Kiro 出于安全考虑，远程 MCP 服务的地址必须是 https:// 或 localhost，
纯 http://<公网IP> 会被直接忽略并提示：
Remote MCP Servers must use https or localhost, ignoring.这带来两个要求：需要一个域名 + 需要 TLS 证书。下面用免费方案同时解决。
Let's Encrypt 之类的证书颁发机构不会给裸 IP 签发证书，必须有域名。而 nip.io 提供了一个巧妙的免费泛解析服务，把任意 IP 直接变成域名， 无需注册、无需配置 DNS。它的解析规则是：
<IP>.nip.io → 自动解析回该 IP例如服务器公网 IP 是 34.4.106.148，那么 34.4.106.148.nip.io 会自动解析到
34.4.106.148。这样就有了一个可用于申请证书的合法域名，且完全免费。
Caddy 是一个反向代理，最大的便利是自动向 Let's Encrypt 申请免费 TLS 证书并自动续期，无需手动操作 certbot。工作流程如下：
公网请求 https://<IP>.nip.io/mcp
│
▼
Caddy (443) ── 首次启动时通过 80 端口的 HTTP-01 验证向 Let's Encrypt 申请证书
│ 证书持久化在 caddy_data 卷中，90 天有效期到期前自动续期
▼
scicalc-mcp:8000 (仅在 compose 内部网络暴露，不直接对公网开放)Caddyfile 的核心配置就是把域名指向内部服务：
34.4.106.148.nip.io {
reverse_proxy scicalc-mcp:8000
}Caddy 看到这个域名后会自动完成"申请证书 → 启用 HTTPS → 反向代理"整个链路。
前置条件：服务器已安装 Docker 与 docker compose，且 GCP 防火墙已放通 80 端口（Let's Encrypt 证书验证与续期所需）与 443 端口（对外 HTTPS 服务）。 8000 端口无需再对公网开放，流量统一经由 Caddy 的 443。
# 1) 把 Caddyfile 中的 IP 换成你服务器的实际公网 IP
# 34.4.106.148.nip.io → <你的IP>.nip.io
# 2) 构建并启动（scicalc-mcp + caddy 两个容器）
docker compose up -d --build
# 3) 查看状态，两个容器都应为 Up；caddy 日志中出现证书申请成功信息
docker compose ps
docker compose logs caddy
# 4) 验证 HTTPS 链路（返回 406 属正常，说明服务健康）
curl -i https://<你的IP>.nip.io/mcpWindows 上用 curl 若报
schannel ... 0x80092013 吊销功能无法检查吊销， 是本地无法联系 CA 的证书吊销检查服务所致，与服务器无关。加--ssl-no-revoke参数即可跳过该检查进行验证。
配置 mcp.json，URL 使用 nip.io 域名的 HTTPS 地址：
{
"mcpServers": {
"scicalc-remote": {
"url": "https://<你的IP>.nip.io/mcp",
"disabled": false,
"autoApprove": []
}
}
}保存后在 Kiro 的 MCP Server 视图中重新连接。
安全提醒：该服务本身不含任何鉴权，一旦经 HTTPS 暴露到公网，任何人都能 调用并消耗算力。建议将 443 端口的防火墙来源限制为你自己的公网 IP（同时保留 80 端口开放以便证书续期），或在 Caddy 层增加认证。
Scientific-computing-MCP/
├── src/scicalc_mcp/
│ ├── server.py # 服务入口，选择传输方式并注册工具
│ ├── safe_eval.py # 数学表达式安全求值器
│ └── tools/ # 按领域拆分的工具模块
│ ├── linear_algebra.py
│ ├── statistics.py
│ ├── scientific.py
│ ├── dataframe.py
│ └── plotting.py
├── scripts/smoke_test.py # 列出已注册工具的冒烟测试
├── k8s/ # GKE 部署清单
│ ├── deployment.yaml
│ ├── service.yaml
│ └── ingress.yaml
├── docker-compose.yml # 单机部署：scicalc-mcp + Caddy 自动 HTTPS
├── Caddyfile # Caddy 反向代理与 nip.io 域名的 TLS 配置
├── Dockerfile
├── pyproject.toml
└── requirements.txt计算两个样本之间的相关系数。
参数: x: 第一个样本。 y: 第二个样本（长度与 x 相同）。 method: 'pearson' 或 'spearman'。
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| method | No | pearson |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It fails to explain output format (single number), edge cases (e.g., different lengths, missing values), or assumptions (linearity). The method options are listed but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for the purpose plus a brief parameter list. No redundancy, and the key action (compute correlation) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description covers inputs and purpose but omits output details and constraints (e.g., data must be numeric, equal length). It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). The description adds essential meaning: x and y are samples, must have same length, and method takes 'pearson' or 'spearman'. This compensates for the schema gap, though it could detail method behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compute the correlation coefficient between two samples', specifying the verb (compute) and resource (correlation coefficient) with explicit method options. It distinguishes itself from siblings like 'dataframe_correlation_matrix' which operates on dataframes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or exclusions. The description only explains parameters, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回数值列之间的皮尔逊相关系数矩阵。
| Name | Required | Description | Default |
|---|---|---|---|
| csv_text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose all behavioral traits. It only states the output type but omits assumptions (e.g., handling of non-numeric columns, missing data, required data format).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that directly conveys the tool's function without any extraneous words. It is appropriately sized for the simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about input format expectations, output structure, and error handling. Given no output schema and low complexity, it still leaves gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the tool description does not explain the single parameter 'csv_text' (format, encoding, required structure). The description adds no value beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a Pearson correlation coefficient matrix for numerical columns, using a specific verb and resource. It is distinct from sibling tools like 'correlation' which may handle single pairs or different methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'correlation' or 'dataframe_describe'. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
解析 CSV 文本并返回各列的汇总统计。
参数: csv_text: 包含表头行的原始 CSV 内容。
返回: 包含 'shape'、'columns'、'dtypes' 以及 'describe' （DataFrame.describe 的结果）的字典。
| Name | Required | Description | Default |
|---|---|---|---|
| csv_text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions the output structure but does not disclose potential errors, assumptions about CSV format (e.g., missing values), or computational limits. Very minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and clearly separates parameter and return value descriptions. Every sentence is informative and non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately explains the output structure (shape, columns, dtypes, describe). Missing details on error handling or performance, but sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'csv_text' has no schema description (0% coverage), but the tool description adds that it should contain a header row. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it parses CSV text and returns summary statistics for each column. It uses a specific verb ('解析') and resource ('CSV 文本'), and is distinct from siblings like 'describe' and 'dataframe_groupby_aggregate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like 'describe' or 'dataframe_correlation_matrix'. There is no when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按某列分组并对某个数值列做聚合。
参数: csv_text: 包含表头行的原始 CSV 内容。 group_by: 用于分组的列名。 value_column: 需要聚合的数值列。 agg: 'mean'、'sum'、'min'、'max'、'count'、'median'、'std' 之一。
| Name | Required | Description | Default |
|---|---|---|---|
| agg | No | mean | |
| csv_text | Yes | ||
| group_by | Yes | ||
| value_column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides basic behavioral context (grouping and aggregation), lists allowed aggregate functions, but does not disclose edge cases, handling of missing values, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with one line for purpose and a list of parameters. It is front-loaded with the main action. Minor improvement could be better separation of purpose and details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the output format or return value. Since there is no output schema, the description should at least hint at what the result looks like, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description thoroughly explains each parameter: csv_text as raw CSV with header, group_by as column name, value_column as numeric column, and agg as one of the listed functions. This adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (group and aggregate) and the resource (dataframe columns). It distinguishes from sibling tools like dataframe_describe by specifying the grouping and aggregation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The allowed aggregation functions are listed, but context on optimal usage or exclusions is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回数值样本的汇总统计量。
包含样本数、均值、标准差（样本）、方差、最小值、最大值、 中位数以及第 25/75 百分位数。
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists the statistics returned, including sample standard deviation and variance, which are behavioral choices. However, it does not mention edge cases (e.g., empty array, NaN handling) or performance characteristics. With no annotations, the description carries the full burden and is only partially adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line stating the purpose and one line listing the statistics. Every word is useful, front-loaded, and no unnecessary information. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description covers the essential behavior: what it expects and what it returns. It could include examples or error behavior, but for a simple descriptive statistics tool, this level of completeness is adequate. The sibling tools suggest a statistical context, and the description fits well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not add any semantic detail beyond the schema type for the 'data' parameter. It does not explain input constraints, format, or acceptable ranges, which is insufficient for a parameter with no schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns summary statistics for a numeric sample, listing specific measures. The verb 'describe' matches the output. However, it does not explicitly differentiate from sibling tools like 'dataframe_describe', though the input type (array) implies a different use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'dataframe_describe' for tabular data or other statistical tools. The description assumes the user knows the context, providing no when-to-use or when-not-to-use hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算方阵的行列式。
| Name | Required | Description | Default |
|---|---|---|---|
| matrix | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It fails to mention what happens if the matrix is not square (likely an error), numerical stability, or any side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is extremely concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown), the description is just barely adequate. It identifies the tool's purpose but lacks details on input validation, output format, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description should compensate. It adds the critical constraint that the matrix must be square, which is not in the schema. However, it does not explain the format or type constraints beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compute the determinant of a square matrix,' which is a specific verb (compute) and resource (determinant of a square matrix). It distinguishes this tool from sibling tools like matrix_multiply or matrix_inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to choose determinant over other matrix operations. The description offers no context for usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算方阵的特征值与特征向量。
返回包含 'eigenvalues' 和 'eigenvectors' 的字典（每一列为一个特征向量）。 复数结果以 [实部, 虚部] 的数对形式返回。
| Name | Required | Description | Default |
|---|---|---|---|
| matrix | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details output format (dict with eigenvalues and eigenvectors, complex numbers as pairs), which adds behavioral context beyond the bare function. However, it does not disclose limitations such as requiring a square matrix or potential numerical stability issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (2 sentences) and front-loaded with the purpose. It is efficient but could be slightly more structured (e.g., bullet points for output format).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mathematical tool with one parameter, the description covers basic output but lacks critical context like input constraints (matrix must be square) and return value interpretation (e.g., ordering of eigenvectors).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage, and the tool description adds no meaning beyond the schema's type definition. The parameter 'matrix' is not explained in terms of its expected shape or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'compute eigenvalues and eigenvectors of a square matrix', providing a specific verb and resource. This clearly distinguishes it from sibling tools like 'determinant' or 'matrix_inverse'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'determinant' or 'solve_linear_system'. Also no mention of prerequisites (e.g., matrix must be square).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在初始猜测附近求解 f(x) = 0 的根。
参数: expression: 以 'x' 为变量的数学表达式。 guess: 求解器的起始点。
| Name | Required | Description | Default |
|---|---|---|---|
| guess | No | ||
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, and description does not disclose convergence criteria, error handling, or behavior for multiple roots or no root.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus parameter list, no wasted words. Front-loads purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations. Lacks information on return value, errors, or algorithm assumptions. For a mathematical tool, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains expression as mathematical expression in x and guess as starting point, adding meaning beyond the schema which has no descriptions. However, no further details on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it solves for root of f(x)=0 near initial guess. Verb and resource are specific. Distinct from siblings like integrate_function or solve_linear_system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. Does not mention limitations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对单变量函数在区间 [lower, upper] 上做数值积分。
参数: expression: 以 'x' 为变量的数学表达式，例如 "sin(x) * x**2"。 支持标准数学函数与常量（pi、e）。 lower: 积分下限。 upper: 积分上限。
返回: 定积分的值以及绝对误差估计。
| Name | Required | Description | Default |
|---|---|---|---|
| lower | Yes | ||
| upper | Yes | ||
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (value and error estimate) and input format, but it does not specify the numerical method used, potential failure cases, or performance characteristics. With no annotations, the description carries the full burden but only provides basic behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a clear header and bullet-like parameter explanations. Every sentence adds value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), the description covers input, output, and constraints adequately. It mentions supported functions and constants, and the return format. Minor gaps include lack of algorithm details or error handling, but overall it provides a complete enough picture for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description fully explains each parameter: 'expression' is a math expression in x with examples and supported functions/constants, 'lower' and 'upper' are integration limits. This adds significant meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs numerical integration of a univariate function over an interval, using specific verbs and resource. It distinguishes the tool from sibling tools like find_root, minimize_function, and determinant, which perform different mathematical operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks context about prerequisites, such as the function being integrable or continuous, and does not mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在指定查询点上进行插值求值。
参数: x: 已知的 x 坐标（需严格递增）。 y: 已知的 y 坐标。 query: 需要求值的 x 位置。 kind: 'linear'、'quadratic' 或 'cubic'。
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| kind | No | linear | |
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that x must be strictly increasing, which is a key behavioral constraint. However, lacks details on error handling, output format, or behavior for invalid inputs. With no annotations, the description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Succinct two-sentence description followed by a clear parameter list. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mathematical nature and presence of an output schema, the description is mostly complete. Explains all parameters and a key constraint. Output format is not described but likely inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter: x (known, strictly increasing), y (known), query (positions), and kind (linear/quadratic/cubic). Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: interpolate values at specified query points. While it doesn't explicitly differentiate from siblings, the purpose is distinct among the provided tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like linear_regression or integrate_function. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
拟合简单线性回归 y = slope * x + intercept。
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden, but it only states the formula. It does not disclose the return type (e.g., slope and intercept, R-squared), error handling, or constraints like equal-length arrays. This minimal disclosure leaves significant uncertainty about tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that delivers the core purpose with no superfluous words. It is front-loaded with the key information. However, adding structured details about parameters or output would improve completeness without breaking conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and zero schema description coverage, the description is insufficient. It only provides the basic purpose, leaving out critical information about expected inputs (e.g., data length, format) and outputs (e.g., what values are returned). A more complete description is needed for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds only the contextual hint that y = slope * x + intercept, which implies x and y are numeric arrays. However, it does not specify that they must be of equal length, the order of elements, or any formatting requirements. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fits a simple linear regression with the explicit formula y = slope * x + intercept. It specifies the verb '拟合' (fit) and the resource '线性回归' (linear regression), and it distinguishes itself from sibling tools like correlation or t_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it is limited to simple linear regression, nor does it exclude multiple regression or suggest other tools for more complex modeling. There is no context about prerequisites or data assumptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
计算方阵的逆矩阵。
当矩阵奇异或非方阵时抛出清晰的错误。
| Name | Required | Description | Default |
|---|---|---|---|
| matrix | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses error behavior for singular/non-square matrices, which is valuable. However, it fails to mention other traits like immutability, precision, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two sentences with no wasted words. It front-loads the core operation and adds critical error information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention that the tool returns the inverse matrix. For a simple tool, this is a minor gap; overall it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description does not add meaning to the 'matrix' parameter beyond its type (already visible in schema). No constraints like real-valued or size requirements are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the inverse of a square matrix, distinguishing it from sibling tools like determinant and solve_linear_system. It also mentions error handling for singular or non-square matrices, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for computing inverses but offers no explicit guidance on when to use this vs alternatives like solve_linear_system. It lacks when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
矩阵相乘 A (m x n) 与 B (n x p)。
参数: a: 左矩阵，按行组成的列表。 b: 右矩阵，按行组成的列表。
返回: 乘积矩阵 A @ B，按行组成的列表。
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior. It describes inputs and output but does not mention dimension mismatch errors or other edge cases. The behavioral disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, each carrying essential information. It is front-loaded with a clear title-like statement and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a standard matrix multiplication tool, the description covers purpose, parameters, and return format adequately. The presence of an output schema reduces the need to document return structure. Minor omissions like error cases lower completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description provides essential meaning: a is left matrix and b is right matrix, both specified as lists of rows. This adds clarity beyond the schema's generic array type, though it omits dimensional alignment details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs matrix multiplication, specifying the dimensions (m x n and n x p) and the output is the product matrix. This distinctively separates it from sibling tools like determinant or matrix_inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for multiplying two matrices but provides no explicit guidance on when to use this tool versus alternatives like solve_linear_system or eigen. It lacks context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在初始猜测附近求单变量函数的局部极小值。
参数: expression: 以 'x' 为变量的数学表达式。 guess: 优化器的起始点。
| Name | Required | Description | Default |
|---|---|---|---|
| guess | No | ||
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention the algorithm used, convergence criteria, limitations, or error handling. Agents are left unaware of potential issues like non-convergence or local vs. global minima.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences and a parameter list. Every sentence adds value, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mathematical optimization) and the lack of output schema or annotations, the description is somewhat minimal. It covers purpose and parameters adequately but omits return values, potential errors, and algorithmic details, which could be important for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 0%, the description adds meaning beyond types: 'expression' is a mathematical expression in variable 'x', and 'guess' is the starting point with a default of 0. This clarifies key details not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds the local minimum of a univariate function near an initial guess. It uses a specific verb ('求' meaning 'find') and resource ('局部极小值'), which distinguishes it from siblings like find_root or integrate_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For instance, it does not explain that this tool is for minimization, while find_root is for root-finding. There are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在区间 [start, stop] 上绘制单变量函数曲线。
参数: expression: 以 'x' 为变量的数学表达式，例如 "sin(x)/x"。 start: 定义域左边界。 stop: 定义域右边界。 points: 采样点数（2-5000）。 title: 可选的图标题。
| Name | Required | Description | Default |
|---|---|---|---|
| stop | Yes | ||
| start | Yes | ||
| title | No | ||
| points | No | ||
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions the sampling point range (2-5000) but omits side effects, return type, or safety considerations. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a header and parameter list. It is reasonably concise, though it could be more terse. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should be more thorough. It does not describe the return value (e.g., a plot image) or error handling. However, it covers the main purpose and parameters adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds significant value by explaining each parameter, e.g., '以 'x' 为变量的数学表达式' for expression. This helps an AI agent understand parameter usage beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '绘制单变量函数曲线' (plot univariate function curve) and specifies the interval [start, stop]. This distinguishes it from sibling tools like plot_line and plot_histogram, which handle data points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. No explicit context, exclusions, or hints about when not to use it are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
绘制数值样本的直方图，返回 PNG 图像。
| Name | Required | Description | Default |
|---|---|---|---|
| bins | No | ||
| data | Yes | ||
| title | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic operation and output format, omitting details like automatic scaling, outlier handling, or side effects. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: a single sentence that immediately states the verb and resource. No words are wasted, though critical information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain required vs optional parameters, data constraints, or how the output is generated. Essential context for correct invocation is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), yet the tool description adds no explanation for any of the three parameters (bins, data, title). The user must infer meaning from parameter names alone, which is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a histogram of numerical samples and returns a PNG image. The verb '绘制' (draw) and resource '直方图' (histogram) are specific and differentiate it from sibling tools like plot_line and plot_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or limitations. It does not specify data type requirements or address when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据 x/y 数据绘制折线图，返回 PNG 图像。
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| title | No | ||
| xlabel | No | x | |
| ylabel | No | y |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the output format (PNG image) but omits behavioral traits such as handling of missing data, axis scaling, or default styling. This insufficiently informs the agent of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, it lacks structure and barely covers essential details. It is adequate in length but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema or annotations, the description is incomplete. It does not specify input constraints (e.g., matching array lengths), output characteristics, or any additional context needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 5 parameters with 0% coverage (no descriptions). The description does not explain any parameter, not even the required x and y arrays. Although parameter names are somewhat suggestive, the description should add meaning beyond the schema, which it fails to do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool draws a line chart from x/y data and returns a PNG image, using specific verb (绘制) and resource (折线图). It distinguishes from sibling plotting tools like plot_function and plot_histogram by its focus on line charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided. Description does not indicate when to use this tool vs alternatives, nor when not to use it. Sibling tools exist for other plot types, but the description lacks explicit differentiation or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
求解线性方程组 A x = b 得到 x。
参数: a: 系数矩阵 (n x n)。 b: 长度为 n 的右端向量。
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose the solution method, behavior for singular matrices, error handling, or any side effects. This is insufficient for a tool that can encounter mathematical edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown), the description need not detail return values. However, it lacks completeness on edge cases (e.g., singular matrices, overdetermined systems) and does not mention that the matrix must be square. For a simple tool, it is minimally adequate but could be more robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning: clarifies that 'a' is an n x n coefficient matrix and 'b' is a right-hand side vector of length n. This provides dimensional constraints and mathematical role beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool solves a linear system A x = b to find x, using specific verb 'solve' and specific resource 'linear system'. It distinguishes from siblings like determinant, matrix_inverse, and eigen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., matrix_inverse) or under what conditions (e.g., matrix must be square and non-singular). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 t 检验。
若提供 sample_b，则执行独立双样本 t 检验； 否则对 sample_a 与 popmean 执行单样本 t 检验。
| Name | Required | Description | Default |
|---|---|---|---|
| popmean | No | ||
| sample_a | Yes | ||
| sample_b | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. It discloses the one-sample vs two-sample conditional logic but omits details about assumptions (e.g., normality, equal variance), output (e.g., t-statistic, p-value), and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only two sentences—with no redundant information. The key conditional logic is front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should at least hint at the return value (e.g., test statistic, p-value). It does not. The conditional logic is clear, but critical information about what the tool actually returns is missing, making it incomplete for a statistical function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the role of sample_b in switching tests and implicitly defines popmean as the population mean for one-sample tests. However, sample_a and sample_b are not explicitly described beyond their types, and popmean lacks explicit definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a t-test, and distinguishes between one-sample and independent two-sample based on the presence of sample_b. This is specific and helps differentiate from sibling statistical tools like correlation or linear_regression.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditional usage: use sample_b for two-sample test, otherwise one-sample. It does not mention when to avoid this tool or compare to other statistical tests, but the conditional logic is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0correlationdataframe_correlation_matrixdataframe_describedataframe_groupby_aggregatedescribedeterminanteigenfind_rootintegrate_functioninterpolate_valueslinear_regressionmatrix_inversematrix_multiplyminimize_functionplot_functionplot_histogramplot_linesolve_linear_systemt_testEach tool targets a distinct operation in its domain (e.g., determinant vs. matrix multiply, t_test vs. linear_regression, integrate_function vs. find_root). Even similar-sounding tools like describe and dataframe_describe have clearly different inputs and purposes.
All tool names follow a consistent snake_case pattern (e.g., matrix_multiply, solve_linear_system, dataframe_groupby_aggregate). The naming is descriptive and predictable, with no mixing of conventions.
With 19 tools, the server covers linear algebra, statistics, calculus, data frame operations, and plotting—an appropriate breadth for a scientific calculator. The count is well-scoped without being overwhelming.
The tool set covers core linear algebra, basic statistics, calculus, data frame summarization, and plotting. However, it lacks matrix operations like transpose or decomposition, and statistical tests like ANOVA, leaving minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/k-ming/Scientific-computing-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
