How do I use astrovisor-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@astrovisor-mcp Calculate my current transits" 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.

astrovisor-mcp

by rokoss21

Overview Schema Related Servers Score Discussions

JavaScript

Remote

AstroVisor MCP

npm version License: MIT Node.js

AstroVisor MCP connects MCP-compatible AI clients to the complete AstroVisor API. It supports local stdio and production Streamable HTTP, discovers operations from the live OpenAPI document, and returns large calculation results through a compact, queryable response layer.

This repository is the protocol and server layer. For reusable personal workflows, private people profiles, interactive credential setup, and safe AI request construction, install the separate AstroVisor Skill.

IMPORTANT

AstroVisor calculations require a personal dashboard API key beginning withpk-. Anonymous calculation requests are not supported. Create an account and get your API key at astrovisor.io, then provide it to your MCP client through a secure environment variable or the AstroVisor Skill private credential setup.

Configure the API key

For a direct MCP connection, make the key available to the client process:

export ASTROVISOR_API_KEY="pk-..."

For the safer profile-aware setup, install AstroVisor Skill and use its hidden key prompt:

npx --yes --package=astrovisor-skill@1.0.1 -- \
  astrovisor-skill install --target both

node "$HOME/.agents/skills/astrovisor/scripts/astrovisor-skill.mjs" \
  config set-key

node "$HOME/.agents/skills/astrovisor/scripts/astrovisor-skill.mjs" \
  doctor --json

You can also ask your agent:

Use $astrovisor. Help me securely configure my AstroVisor API key, keep it out of
chat and client configuration, then verify the MCP connection.

The agent should guide you to the hidden terminal prompt rather than asking you to paste the full key into the conversation.

AstroVisor Skill (optional workflow layer)
    ↓
AstroVisor MCP (this repository)
live OpenAPI · authentication · API calls · result retrieval
    ↓
AstroVisor API

Highlights

Six compact MCP tools covering 456 current API operations.
Live OpenAPI discovery instead of hundreds of hardcoded tool definitions.
Stdio support for Claude Desktop, Claude Code, Codex, and other local clients.
Authenticated Streamable HTTP at https://mcp.astrovisor.io/.
Exact operationId, path, query, and JSON body serialization.
Common core and birth_* request-profile normalization.
Compact, full, and summary response views with token budgets.
Filtering, projection, sorting, pagination, and targeted path retrieval.
Temporary result storage isolated by caller API key.
Optional full mode with one generated tool per OpenAPI operation.

Capabilities include natal astrology, transits, progressions, solar returns, synastry, compatibility, Jyotish, BaZi, Human Design, Gene Keys, numerology, Tarot, Lenormand, astrocartography, horary, electional, and every other operation published by the live AstroVisor OpenAPI schema.

Related MCP server: OpenAPI MCP Server

Choose your integration

Need	Recommended setup
Personal assistant with reusable profiles	AstroVisor Skill
Cloud or generic MCP client	Remote Streamable HTTP
Claude Desktop or local stdio client	`npx astrovisor-mcp`
Backend/operator deployment	Internal JSON-RPC adapter plus public gateway
Direct Node.js dependency	`npm install astrovisor-mcp`

Requirements:

Node.js 20 or newer for local stdio;
an AstroVisor dashboard API key beginning with pk-;
an MCP client supporting stdio or Streamable HTTP.

Quick start

Remote Streamable HTTP

Endpoint:

https://mcp.astrovisor.io/

Authenticate with either:

Authorization: Bearer pk-...

or:

X-API-Key: pk-...

The compatibility endpoint https://mcp.astrovisor.io/mcp is also available. Health:

https://mcp.astrovisor.io/health

Local stdio

Run without a global installation:

ASTROVISOR_API_KEY="pk-..." \
npx --yes --package=astrovisor-mcp@5.0.0 -- astrovisor-mcp

Or install globally:

npm install --global astrovisor-mcp@5.0.0
ASTROVISOR_API_KEY="pk-..." astrovisor-mcp

For personal use, prefer the private launcher included in AstroVisor Skill. It avoids putting the key in MCP configuration or shell history.

Client configuration

Codex and ChatGPT desktop

Remote HTTP using an environment variable:

[mcp_servers.astrovisor]
url = "https://mcp.astrovisor.io/"
bearer_token_env_var = "ASTROVISOR_API_KEY"
startup_timeout_sec = 30
tool_timeout_sec = 120

Codex CLI, the IDE extension, and ChatGPT desktop share Codex MCP configuration on the same host. Verify with:

codex mcp list

In the interactive client, use /mcp.

For profile-aware workflows and generated secret-free configuration, follow the AstroVisor Skill Codex setup.

Official documentation: Codex MCP.

Claude Code

Remote HTTP:

claude mcp add --transport http --scope user astrovisor \
  https://mcp.astrovisor.io/ \
  --header "Authorization: Bearer pk-..."

Local stdio:

claude mcp add --transport stdio --scope user \
  --env ASTROVISOR_API_KEY=pk-... \
  astrovisor -- \
  npx --yes --package=astrovisor-mcp@5.0.0 -- astrovisor-mcp

Verify:

claude mcp get astrovisor
claude mcp list

Remote HTTP is the preferred transport for a cloud-hosted server. For personal credentials, the AstroVisor Skill launcher keeps the key outside Claude configuration and shell history.

Official documentation: Claude Code MCP.

Claude Desktop

Direct stdio configuration:

{
  "mcpServers": {
    "astrovisor": {
      "command": "npx",
      "args": [
        "--yes",
        "--package=astrovisor-mcp@5.0.0",
        "--",
        "astrovisor-mcp"
      ],
      "env": {
        "ASTROVISOR_API_KEY": "pk-...",
        "ASTROVISOR_URL": "https://astrovisor.io",
        "ASTROVISOR_TOOL_MODE": "compact"
      }
    }
  }
}

Restart Claude Desktop after changing claude_desktop_config.json.

For a configuration with no embedded API key, use the AstroVisor Skill Claude Desktop setup.

Compact toolset

Compact mode is the default. It keeps tool definitions small while preserving access to every live API operation.

Tool	Purpose
`astrovisor_conventions`	Read global request, alias, and response conventions
`astrovisor_openapi_search`	Search operations by intent or keyword
`astrovisor_openapi_list`	List operations by tags, path, method, or page
`astrovisor_openapi_get`	Inspect one canonical operation and request schema
`astrovisor_request`	Execute any operation by `operationId`
`astrovisor_result_get`	Retrieve a stored result or a narrow fragment

The correct discovery chain is:

astrovisor_conventions
    ↓
astrovisor_openapi_search / astrovisor_openapi_list
    ↓
astrovisor_openapi_get
    ↓
astrovisor_request
    ↓
astrovisor_result_get (when a stored or narrower result is needed)

Never guess an operation id or request body. astrovisor_openapi_get returns:

canonical operationId;
HTTP method and path;
path and query parameters;
requestBodySchema;
aliases;
required body fields;
an LLM-oriented example body.

Request contract

Call astrovisor_request with this outer envelope:

{
  "operationId": "<canonical operation id from astrovisor_openapi_get>",
  "path": {},
  "query": {},
  "body": {},
  "response": {
    "view": "compact",
    "tokenBudget": 12000,
    "store": true
  }
}

Rules:

put URL-template variables only in path;
put query-string values only in query;
put the API JSON request only in body;
preserve booleans, numbers, arrays, and objects as JSON types;
do not wrap body in data, payload, or request unless the live schema requires it;
do not send empty strings as substitutes for required fields;
use the live schema when it differs from examples or cached knowledge.

The MCP normalizes common aliases between:

datetime, latitude, longitude, location, timezone

and:

birth_datetime, birth_latitude, birth_longitude,
birth_location, birth_timezone

Normalization is a compatibility feature, not a reason to skip live schema inspection.

For a strict personal and multi-person workflow, use the AstroVisor Skill request contract.

Large results and precision retrieval

Every compact response uses the astrovisor.serialized.v2 envelope and can include:

meta.query.totalBefore, totalMatched, offset, limit, and nextCursor;
meta.availablePaths for discoverable follow-up paths;
meta.pathFound for path validation;
meta.truncated when additional retrieval is appropriate;
summary.source and summary.selected;
a temporary resultId;
token-optimized data.

Response controls:

Field	Purpose
`responsePath`	Select a subtree before other processing
`select`	Project specific fields
`where`	Filter using field/operator expressions
`sort`	Apply deterministic ordering
`cursor`	Continue cursor pagination
`responseOffset` / `responseLimit`	Offset pagination
`include` / `exclude`	Keep or omit paths
`maxItems`	Bound large arrays
`tokenBudget`	Bound serialized output
`store`	Keep the full response temporarily

Example:

{
  "operationId": "<operation id>",
  "body": {
    "<required field>": "<confirmed value>"
  },
  "response": {
    "view": "compact",
    "responsePath": "data.items",
    "select": ["date", "strength", "theme"],
    "where": {
      "strength_gte": 0.75
    },
    "sort": ["-strength", "date"],
    "responseLimit": 20,
    "tokenBudget": 12000,
    "store": true
  }
}

Retrieve the next fragment without recalculating:

{
  "resultId": "<result id>",
  "response": {
    "view": "compact",
    "responsePath": "data.items",
    "cursor": "<next cursor>",
    "select": ["date", "strength", "theme"],
    "responseLimit": 20,
    "tokenBudget": 12000
  }
}

Supported where suffixes:

_eq _ne _gt _gte _lt _lte
_in _nin
_contains _startswith _endswith
_exists _regex

If meta.pathFound is false, select a path from meta.availablePaths instead of repeating the same request.

Full tool mode

Set:

export ASTROVISOR_TOOL_MODE=full

Full mode creates one MCP tool per OpenAPI operationId and accepts several legacy operation aliases. It is useful for specialized clients but can consume too much context in clients with strict tool-definition limits. Compact mode is recommended for general use.

Environment variables

Stdio and internal adapter

Variable	Default	Purpose
`ASTROVISOR_API_KEY`	required	Dashboard API key
`ASTROVISOR_URL`	`https://astrovisor.io`	API base URL
`ASTROVISOR_OPENAPI_URL`	`<ASTROVISOR_URL>/openapi.json`	OpenAPI override
`ASTROVISOR_TOOL_MODE`	`compact`	`compact` or `full`
`ASTROVISOR_RESPONSE_VIEW`	`compact`	Default response view
`ASTROVISOR_DEFAULT_TOKEN_BUDGET`	implementation default	Serialized byte budget
`ASTROVISOR_RESULT_TTL_MS`	`1800000`	Result cache TTL
`ASTROVISOR_RESULT_MAX_ENTRIES`	`128`	Maximum cached results

Public gateway

Variable	Default	Purpose
`MCP_PUBLIC_HTTP_HOST`	`127.0.0.1`	Gateway bind host
`MCP_PUBLIC_HTTP_PORT`	`3002`	Gateway bind port
`INTERNAL_MCP_URL`	`http://127.0.0.1:3001/mcp`	Internal adapter URL
`API_KEY_VALIDATION_PATH`	`/internal/mcp/validate-api-key`	Non-billable key validation endpoint
`API_KEY_VALIDATION_CACHE_MS`	`60000`	Validation cache time
`MCP_INTERNAL_VALIDATION_TOKEN`	required	Internal validation credential

Self-hosting

The production topology is:

Remote MCP client
    ↓ TLS
Reverse proxy
    ↓ loopback
Public Streamable HTTP gateway
    ↓ loopback
Internal JSON-RPC adapter
    ↓
AstroVisor API

Build and start the two Node services:

npm ci
npm run build
npm run start:jsonrpc
npm run start:public

Operational requirements:

keep the AstroVisor API, internal adapter, and public gateway on loopback;
terminate TLS at a reverse proxy;
require MCP_INTERNAL_VALIDATION_TOKEN for key validation;
ensure key validation does not record billable API usage;
apply process supervision, memory limits, and restart policies;
never log raw caller API keys or full private request bodies.

Development

git clone https://github.com/rokoss21/astrovisor-mcp.git
cd astrovisor-mcp
npm ci
npm run build
npm run test:unit

Production OpenAPI smoke test:

ASTROVISOR_URL=https://astrovisor.io npm test

Stdio end-to-end test:

ASTROVISOR_API_KEY=pk-... npm run test:e2e:stdio

Remote end-to-end test:

MCP_URL=https://mcp.astrovisor.io/ \
ASTROVISOR_API_KEY=pk-... \
npm run test:e2e:remote

Security check:

npm audit --omit=dev

Migration from 4.3.x

AstroVisor Skill now has its own canonical repository and npm package:

GitHub: rokoss21/astrovisor-skill
npm: astrovisor-skill

Install it directly:

npx --yes --package=astrovisor-skill@1.0.1 -- \
  astrovisor-skill install --target both

Version 5.0.0 removes the bundled astrovisor-skill binary. This avoids npm binary-name collisions and gives each project a single release lifecycle. Replace commands that install the skill through astrovisor-mcp with the standalone package command above. The MCP tool and transport contracts are unchanged.

AstroVisor Skill — profiles, onboarding, request workflows, and responsible interpretation.
AstroVisor — API, dashboard, and product.

License

MIT

Available Tools

6 tools

astrovisor_conventionsA

Get MCP interoperability conventions and parameter profiles for LLM clients.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must bear the full burden for behavioral disclosure. It only states 'Get', implying read-only, but offers no details about return format, size, authentication needs, or any side effects. For a tool with no annotations, this is insufficient.

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?

Single sentence, no unnecessary words. Front-loaded with the verb and resource. Every word earns its place.

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

Completeness3/5

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

The tool is simple with no parameters and no output schema. The description gives a minimal but clear purpose. However, it does not specify what exactly is returned (e.g., format or fields), which could leave an agent uncertain about the output. Adequate for a basic getter but could be more helpful.

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?

The tool has zero parameters, and the schema coverage is 100%. Per guidelines, zero parameters baseline is 4. The description does not add parameter information, but none is needed.

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 the tool retrieves 'MCP interoperability conventions and parameter profiles for LLM clients'. It uses specific verb and resource, and is distinct from sibling tools like astrovisor_request or astrovisor_openapi_search, which serve different purposes.

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it should be used to retrieve conventions before making requests, but lacks clear when-not-to-use or alternative names.

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

astrovisor_openapi_getB

Get OpenAPI metadata for a specific operationId (method/path/params/requestBody).

ParametersJSON Schema

Name	Required	Description	Default
`operationId`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. However, it only states the basic action and does not mention read-only nature, error handling, or authentication requirements.

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?

The description is a single concise sentence that immediately conveys the tool's purpose without extraneous words.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description covers purpose but lacks details on error handling, return structure, and usage context, making it minimally adequate.

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

Parameters2/5

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

The input schema has one parameter (operationId) with 0% description coverage. The description does not add any extra meaning, format, or example for this parameter, failing to compensate for the schema's lack of documentation.

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 the tool retrieves OpenAPI metadata for a specific operationId, listing what that metadata includes (method, path, params, requestBody). This distinguishes it from sibling tools like astrovisor_openapi_search or astrovisor_openapi_list.

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 implies usage when a specific operationId is known, but does not explicitly state when to use it versus alternatives or provide any when-not-to-use guidance.

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

astrovisor_openapi_listA

List OpenAPI operations with pagination and optional filters.

ParametersJSON Schema

Name	Required	Description
`tag`	No	Optional tag filter (exact match).
`limit`	No	Max items (default 50).
`method`	No	Optional HTTP method filter (GET/POST/PUT/PATCH/DELETE).
`offset`	No	Start index (default 0).
`pathPrefix`	No	Optional path prefix filter, e.g. /api/tarot

TDQS

A3.7/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. It discloses that the tool performs a listing operation with pagination and optional filters, implying a read-only behavior. This sufficiently communicates the primary behavioral trait, though it does not strictly state that it is idempotent or safe.

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?

The description is a single concise sentence with no unnecessary words. It front-loads the primary action and includes key features (pagination, filters). Every word earns its place.

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

Completeness3/5

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

Given the complexity (5 optional parameters, no output schema), the description is adequate but incomplete. It does not specify the return format (e.g., array of operations, metadata) or ordering. With no output schema, the agent may need additional context about the result structure.

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% with parameter descriptions in the schema. The description adds a high-level summary ('pagination and optional filters') but no additional semantic detail beyond what each parameter's description already provides. Baseline 3 is appropriate.

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 the tool lists OpenAPI operations, with pagination and filters. This distinguishes it from sibling tools like astrovisor_openapi_get (single operation) and astrovisor_openapi_search (search). It identifies a specific verb and resource.

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

Usage Guidelines2/5

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

No usage guidance is provided. The description does not indicate when to use this tool versus siblings like astrovisor_openapi_search or astrovisor_openapi_get. It lacks context on when to prefer pagination vs search, and no when-not 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.

astrovisor_openapi_searchA

Search AstroVisor OpenAPI operations by text (operationId/summary/path/tag). Returns top matches.

ParametersJSON Schema

Name	Required	Description
`q`	No	Search text.
`tag`	No	Optional OpenAPI tag filter.
`limit`	No	Max results (default 10).

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states it returns top matches but does not disclose pagination, sorting, or behavior for no results. It is adequate but minimal beyond what the schema provides.

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?

The description is a single concise sentence that is front-loaded with the key action and scope. No extraneous information.

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

Completeness3/5

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

With no output schema, the description could better indicate the return structure (e.g., list of operations). For a search tool, it is functional but leaves the agent inferring the response format. Adequate but with room for more completeness.

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?

The schema already provides 100% description coverage for parameters. The description adds value by specifying the searchable fields (operationId, summary, path, tag) and clarifying that results are top matches, enhancing understanding beyond the 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 the tool searches AstroVisor OpenAPI operations by text across multiple fields (operationId, summary, path, tag) and returns top matches. It distinguishes from sibling tools like astrovisor_openapi_list (list all) and astrovisor_openapi_get (get specific) by focusing on search.

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 implies usage for searching operations by text, but does not explicitly state when to use versus alternatives or provide when-not guidance. It is adequate for basic understanding but lacks explicit context.

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

astrovisor_requestB

Call any AstroVisor API operation by operationId. Supports compact serialization and follow-up retrieval by resultId.

ParametersJSON Schema

Name	Required	Description
`body`	No	JSON request body.
`path`	No	Path params for templates like /api/foo/{id}.
`query`	No	Query string params.
`method`	No	Optional disambiguation if operationId is not unique.
`response`	No
`operationId`	Yes	OpenAPI operationId to call.
`pathTemplate`	No	Optional disambiguation if operationId is not unique.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description must carry burden of behavioral disclosure. It mentions compact serialization and follow-up retrieval by resultId, but does not explain side effects, authentication requirements, or error behavior. Major gaps for a mutation-capable 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?

Two focused sentences with no fluff. First sentence captures primary purpose; second adds key features. Could benefit from brief usage note but remains efficient.

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

Completeness2/5

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

Given tool complexity (7 parameters, nested response options, no output schema), description is too brief. Does not explain response format, pagination, or how to combine operationId with path/method. Leaves significant gaps 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 description coverage is high (86%), so baseline is 3. Description adds context about compact serialization and resultId retrieval, but does not detail parameter semantics beyond what the schema provides. Adequate but not enhancing.

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?

Description clearly states the tool calls any AstroVisor API operation by operationId, which is a specific verb-resource combination. It distinguishes from sibling tools like astrovisor_openapi_search (search) and astrovisor_result_get (retrieval) as the generic gateway.

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?

No explicit guidance on when to use this tool versus siblings. The description implies general-purpose use but does not state preferred alternatives for common operations (e.g., use astrovisor_openapi_get for specific endpoints). Use case is implied but not clarified.

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

astrovisor_result_getB

Get stored full result by resultId with optional selective serialization.

ParametersJSON Schema

Name	Required	Description	Default
`response`	No
`resultId`	Yes	Result ID returned by astrovisor_request meta.resultId.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It mentions 'optional selective serialization' but does not disclose behavioral traits such as error handling, required prerequisites, or the effect of serialization parameters. The tool has many complex parameters but the description provides no additional behavioral context beyond the basic operation.

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 a single, front-loaded sentence (10 words) that conveys the core purpose. While very concise, it earns its place; however, given the tool's complexity, a slightly longer description could be justified. Score 4 for efficient structure.

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

Completeness2/5

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

The description lacks context about the return value (no output schema), the relationship to astrovisor_request (resultId origin), and typical usage scenarios. For a tool with rich serialization options, more guidance on when to use them would improve completeness.

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 description coverage is high (nearly all properties have descriptions). The tool description adds only 'optional selective serialization' which is a general characterization, but does not provide specific semantics for parameters beyond what the schema already documents. Baseline 3 is appropriate.

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?

Description clearly states the action (Get), the resource (stored full result), the key identifier (resultId), and the optional feature (selective serialization). This distinguishes it from siblings like astrovisor_request (creates a request) and astrovisor_openapi_* (API schema tools).

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description implies it follows astrovisor_request (since resultId comes from there), but this is not stated. No exclusions or when-not-to-use are provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv5.0.0Jul 29, 2026
- First observedastrovisor_conventions
- First observedastrovisor_openapi_get
- First observedastrovisor_openapi_list
- First observedastrovisor_openapi_search
- First observedastrovisor_request
- First observedastrovisor_result_get

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose: one for executing API calls, three for exploring OpenAPI specs, one for retrieving results, and one for conventions. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent 'astrovisor_<action>' pattern using snake_case, making them predictable and easy to understand.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose of interacting with an API explorer and executor. Neither too few nor too many.

Completeness4/5

The tool set covers the core workflow: exploring operations, retrieving metadata, executing requests, and fetching results. A minor gap is the lack of a way to list stored results, but this is acceptable given the design.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
com.skopik
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Agent Orchestration Knowledge & Memory Search
2
Agent Router C
io.github.Tim-Projekt
Discover and call AI agents via MCP. Supports A2A agents and platform agents with async tasks.
Agent Orchestration Autonomous Agents
252
CraloOAuth
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
mcphost A
dev.mcphost
Hosted MCP runtime where the agent is the operator: sign up by tool call, publish your own tools.
171

Related MCP Servers

OpenAPI MCP Server
API Testing Documentation Access Developer Tools
teddy258
A
license
Not graded
quality
D
maintenance
Exposes OpenAPI specifications as MCP tools, enabling AI assistants to explore and understand API structures, endpoints, schemas, and documentation through semantic queries.
Updated 4 months ago (2026-05-18 05:35 UTC)
19
MIT
OpenAPI MCP Server
API Testing Developer Tools AI & Machine Learning
lotusbaba
F
license
Not graded
quality
D
maintenance
Dynamically exposes any OpenAPI/Swagger API as tools for AI assistants, automatically generating MCP tools from OpenAPI specs with authentication support.
Updated a year ago (2025-07-28 20:08 UTC)
-
aqc-mcp
Research & Data Open Data
inoribea
A
license
Not graded
quality
D
maintenance
MCP server that provides tools to query 17+ astronomical databases (e.g., SIMBAD, VizieR, Gaia) via HTTP/TAP APIs, enabling AI applications to access astronomical data through natural language.
Updated 5 months ago (2026-04-08 08:14 UTC)
13
2
BSD 3-Clause
yellow-pages
RAG Systems Developer Tools
ethank64
F
license
A
quality
D
maintenance
Exposes two MCP tools (discover and execute) that enable agents to query an OpenAPI schema via natural language and execute matched API operations.
Updated 6 months ago (2026-03-18 21:41 UTC)
2
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rokoss21/astrovisor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

AstroVisor MCP

Configure the API key

Highlights

Choose your integration

Quick start

Remote Streamable HTTP

Local stdio

Client configuration

Codex and ChatGPT desktop

Claude Code

Claude Desktop

Compact toolset

Request contract

Large results and precision retrieval

Full tool mode

Environment variables

Stdio and internal adapter

Public gateway

Self-hosting

Development

Migration from 4.3.x

Related projects

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API