Skip to main content
Glama
Sign In

Asterwise

by com.asterwise
OverviewDiscussionsAdmin

Number Meaning

asterwise_get_number_meaning
Read-onlyIdempotent

Returns dictionary-style numerology copy for a single integer, including interpretation, keywords, and stubbed extended fields.

WORKFLOW: BEFORE: None — standalone. AFTER: None.

INPUT CONTRACT: number must pass local guard: one of 1-9, 11, 22 or 33; any other value raises MCP INVALID_PARAMS before the HTTP call.

DO NOT CONFUSE WITH: asterwise_get_numerology_profile — computes personal numbers from name and date, not a static dictionary row. asterwise_get_lucky_numbers — personalised lucky list, not reference meanings.

Full output and error contract: https://docs.asterwise.com/mcp/tools/get-number-meaning/

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "number": "<number>"
    },
    "name": "asterwise_get_number_meaning"
  }
}

Input Schema

NameRequiredDescriptionDefault
numberYesNumber to interpret: 1-9, or a master number 11, 22 or 33.
response_formatNoOutput format: 'markdown' (default) for a readable report, or 'json' for the raw structured payload.markdown

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the local guard raises MCP INVALID_PARAMS before any HTTP call, and the output contains 'stubbed extended fields', which warns the agent some returned fields are placeholders.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-line purpose followed by clearly labeled WORKFLOW, INPUT CONTRACT and DO NOT CONFUSE WITH sections; every line carries actionable information. The docs link is the only mildly expendable element and it substitutes for a long error-contract dump.

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?

With an output schema present, the description need not explain return values, and it covers the remaining gaps: validation behavior, standalone workflow position, and disambiguation from the two closest siblings. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so the baseline is 3; the description nevertheless adds value by spelling out the guard contract for the number parameter and that out-of-range values fail pre-flight rather than at the API. The response_format enum is only documented in the schema, so it is not a full 5.

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?

States a specific verb and resource ('Returns dictionary-style numerology copy for a single integer') and enumerates what the payload contains (interpretation, keywords, extended fields). It explicitly names and contrasts two sibling tools, so the agent can distinguish it without opening any schema.

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

Usage Guidelines5/5

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

The 'DO NOT CONFUSE WITH' block names asterwise_get_numerology_profile and asterwise_get_lucky_numbers and states what each does instead, which is exactly the routing information an agent needs. The WORKFLOW BEFORE/AFTER lines confirm it is standalone with no prerequisite or follow-up step.

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

All Asterwise toolsInspect
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.

Resources