Skip to main content
Glama
Sign In
mcp-abacus

mcp-abacus

by laszlopere
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

help

Return mcp-abacus reference text for one section, to drive the evaluator.

Instructions

Return mcp-abacus reference text for one section, to drive the evaluator.

Sections: 'types' (the numeric types this build supports), 'language' (the expression grammar — operators, precedence, literal forms), 'functions' (the callable functions and their argument counts), 'solver' (the solver tool — solving / optimising one variable over a bracket), and 'fit' (the curve_fit tool — fitting curve forms to paired (x, y) data). section is restricted to these five names — advertised as a schema enum — so any other value is rejected with the valid list.

search_filter, when given, narrows the section to the lines that contain it as a case-insensitive substring; a filter that matches nothing says so. details expands the 'functions' section into per-function cards (signature, arity, description).

Input Schema

NameRequiredDescriptionDefault
detailsNoWhen true, expands the 'functions' section: each matching function is shown as a card with its signature, arity, and description instead of a one-line row. Combine with 'search_filter' to detail one function. No effect on the other sections.
sectionYesWhich reference section to return: 'types', 'language', 'functions', 'solver', or 'fit'.
search_filterNoOptional case-insensitive substring; keeps only the section's lines that contain it (e.g. 'sin' over 'functions' returns the sin/asin/asinh/sinh rows). Omit or leave empty to return the whole section.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / details
      Added value: +{
+  "default": false,
+  "description": "When true, expands the 'functions' section: each matching function is shown as a card with its signature, arity, and description instead of a one-line row. Combine with 'search_filter' to detail one function. No effect on the other sections.",
+  "title": "Details",
+  "type": "boolean"
+}
    • addedInput schema / properties / search_filter
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional case-insensitive substring; keeps only the section's lines that contain it (e.g. 'sin' over 'functions' returns the sin/asin/asinh/sinh rows). Omit or leave empty to return the whole section.",
+  "title": "Search Filter"
+}
    • changedInput schema / properties / section / description
      Previous value: -"Which reference section to return: 'types', 'language', 'functions', or 'solver'."New value: +"Which reference section to return: 'types', 'language', 'functions', 'solver', or 'fit'."
    • changedInput schema / properties / section / enum
      Previous value: -[
-  "types",
-  "language",
-  "functions",
-  "solver"
-]New value: +[
+  "types",
+  "language",
+  "functions",
+  "solver",
+  "fit"
+]
  2. Changed2 schema fields changedv0.2.0
    • addedInput schema / properties / section / description
      Added value: +"Which reference section to return: 'types', 'language', 'functions', or 'solver'."
    • addedInput schema / properties / section / enum
      Added value: +[
+  "types",
+  "language",
+  "functions",
+  "solver"
+]
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does a decent job: it discloses that out-of-enum values are rejected with the valid list, that a non-matching filter returns an explicit 'no match' message, and that details only affects the functions section. It does not describe size or pagination of the returned text, which is a minor residual gap.

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?

Front-loads the core purpose in one sentence, then handles sections and each parameter in tight, separated statements. The only slightly wasteful element is the meta-phrase 'to drive the evaluator', which does not help an agent decide how to call the tool.

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?

An output schema exists, so return-value formatting need not be explained. Given three parameters and 100% schema coverage, the description supplies the remaining behavioral context (enum rejection, filter matching, details scoping) and is nearly complete; only the absence of guidance relative to the info sibling keeps it from a 5.

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

Parameters4/5

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it documents the enum-rejection behavior for section, the case-insensitive substring semantics and example for search_filter, and the 'no effect on other sections' constraint for details.

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?

States a concrete verb and resource (return mcp-abacus reference text for one section) and enumerates all five valid sections with a parenthetical gloss of each, so the agent knows exactly what content it can retrieve. It does not, however, differentiate itself from the sibling 'info' tool, leaving an ambiguity an agent must resolve elsewhere.

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 implicitly conveys the usage context ('to drive the evaluator') and explains when to combine search_filter and details, but never states when to call help versus the sibling info tool or when each section is appropriate. Usage is implied rather than explicitly framed as when-to-use/when-not.

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