jitapi
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COHERE_API_KEY | No | Cohere API key (alternative cloud provider) | |
| OPENAI_API_KEY | No | OpenAI API key (alternative cloud provider) | |
| VOYAGE_API_KEY | No | Voyage AI API key (recommended cloud provider) | |
| JITAPI_LOG_LEVEL | No | DEBUG, INFO, WARNING, ERROR (default: INFO) | INFO |
| JITAPI_STORAGE_DIR | No | Data directory (default: ~/.jitapi) | ~/.jitapi |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_apiA | Register a new API by ingesting its OpenAPI specification. This parses the spec, builds a dependency graph, and creates searchable embeddings. |
| list_apisB | List all registered APIs with their basic information. |
| search_endpointsA | Search for API endpoints using natural language. Returns semantically similar endpoints based on the query. |
| get_workflowA | Get relevant endpoints with dependency resolution and full schemas for accomplishing a task. Returns search results expanded with their dependencies so you can plan and execute the right API calls in the right order. After reviewing the results, use call_api to execute each step. |
| get_endpoint_schemaB | Get the full schema for a specific endpoint. Use this to get detailed parameter and response information. |
| call_apiB | Execute an API call. Make sure authentication is configured first. |
| set_api_authA | Configure authentication for an API. Supports API key (header or query param) and bearer token auth. Use env_var to reference a secret from an environment variable — the credential is then resolved at request time and never stored on disk. |
| delete_apiA | Delete a registered API and all its data including endpoints, embeddings, dependency graph, and authentication credentials. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| explore_api | Explore what an API can do |
| register_and_explore | Register a new API and explore its capabilities |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool has a clearly distinct purpose: register/delete/list for API lifecycle management, search_endpoints for discovery, get_endpoint_schema for detailed inspection, get_workflow for task planning with dependencies, set_api_auth for configuration, and call_api for execution. No overlapping functionality.
Consistent snake_case throughout with verb_noun pattern (call_api, delete_api, list_apis, register_api, search_endpoints, get_workflow, get_endpoint_schema, set_api_auth). All use standard CRUD-style verbs (get, list, search, call, set, register, delete).
8 tools is well-scoped for an API management server covering the full lifecycle: registration, listing, deletion, authentication, discovery (search), inspection (schema), planning (workflow), and execution. Each tool earns its place without redundancy.
Covers the core API lifecycle well (register, list, delete, auth, search, call) with helpful additions like workflow planning. Minor gaps: no get_api for specific API details (only list_apis), no update_api for refreshing specs without full deletion, and no way to remove auth without deleting the entire API.