convert_baseConvert an integer between numeral bases 2-36 (keyless, offline). E.g. number "ff" from_base 16 to_base 2 -> "11111111".
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The number as a string in `from_base`. | |
| to_base | Yes | Target base 2-36. | |
| from_base | Yes | Source base 2-36. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "from_base": 16,
+ "number": "ff",
+ "to_base": 2
+ },
+ {
+ "from_base": 2,
+ "number": "1010",
+ "to_base": 10
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds value by disclosing that the operation is keyless and offline, and that it works on integers. These behavioral traits are not present in the annotations and help the agent understand autonomy and data flow.
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 followed by an inline example. It is front-loaded with the core action and constraints (numeral bases 2-36, keyless, offline). Every word serves a purpose, and the example is illustrative without redundancy.
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 example clearly shows the output format (a string), compensating for the lack of an output schema. However, it does not mention error handling (e.g., invalid input, out-of-range bases) or explicitly state that the output is a string. Given the tool's simplicity, the description is mostly complete but could be slightly more explicit about return value type.
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?
Input schema covers all three parameters with descriptions and examples. The description does not add additional semantic detail beyond the schema, but the example usage reinforces the parameter relationships. Given 100% schema coverage, a score of 3 is appropriate.
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 converts integers between bases 2-36 with a concrete example. The verb 'convert' and resource 'integer between numeral bases' make the purpose unambiguous, and the example reinforces the operation. It distinguishes from sibling tools like 'from_roman' and 'to_roman' by specifying the base range.
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 mentions 'keyless, offline', which indicates no authentication or network required, but it does not explicitly state when to use this tool versus alternatives like 'number_to_words' or Roman numeral converters. The usage context is implied but not directly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have detailed descriptions that clearly delineate their purposes, but ask_pipeworx_beta is currently functionally identical to ask_pipeworx, and deep_research overlaps with ask_pipeworx for multi-part questions. The six polymarket_* tools also share related territory, though their boundaries are well-documented.
All names use snake_case, and domain prefixes like polymarket_, pipeworx_, and ask_ add predictability. However, the set mixes verb-led names (compare_entities, resolve_entity, search_within) with noun-led names (entity_profile, recent_changes, bet_research), so there is no single consistent verb_noun convention.
35 tools is well above the 15-25 'heavy' band and feels like a kitchen sink: the server bundles a data-research platform, prediction-market analysis, memory, subscriptions, number conversions, and web-dev utilities into one surface. Many of these are unrelated to the server's 'Numbers' identity.
The main subdomains are thoroughly covered: data lookup (ask_pipeworx variants, deep_research, validate_claim), prediction-market analysis (arbitrage, edges, fill risk, kalshi spread), memory (remember/recall/forget), and subscriptions (subscribe/list/unsubscribe/recent_alerts). Minor gaps exist, such as no subscription update operation, but core lifecycle coverage is strong.