Claude를 모든 API에 연결하세요. JitAPI는 어떤 엔드포인트를 어떤 순서로 호출해야 하는지 자동으로 파악합니다.
JitAPI는 Claude가 OpenAPI 사양을 통해 모든 API와 상호작용할 수 있게 해주는 MCP 서버입니다. 수백 개의 엔드포인트를 컨텍스트에 덤프하는 대신, JitAPI는 의미론적 검색과 의존성 그래프를 사용하여 필요한 것만 노출하며, 이후 Claude가 호출을 계획하고 실행합니다.
https://github.com/user-attachments/assets/53f72f89-a41a-4a9c-a688-ec876ea05fbd
Stripe는 300개 이상의 엔드포인트를 가지고 있고, GitHub는 800개 이상입니다. 전체 사양을 Claude의 컨텍스트에 로드하면 토큰이 낭비되고 환각 현상이 발생합니다. 사용하는 모든 API에 대해 커스텀 MCP 서버를 작성하는 것은 확장성이 떨어집니다.
JitAPI가 이 문제를 해결합니다: OpenAPI 사양을 한 번 등록하면, 필요한 것을 자연어로 요청하기만 하면 됩니다. JitAPI가 올바른 엔드포인트를 찾고, 그들 간의 의존성을 해결하며, Claude가 호출을 실행할 수 있도록 합니다.
Related MCP server: OpenAPI to MCP
pip install jitapiClaude Code 설정(.mcp.json)에 추가하세요:
{
"mcpServers": {
"jitapi": {
"command": "uvx",
"args": ["jitapi"]
}
}
}이것으로 끝입니다. API 키가 필요 없습니다. JitAPI는 로컬 임베딩을 즉시 사용합니다.
그다음 Claude에서 다음과 같이 하세요:
You: Register the GitHub API from https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json
Claude: ✓ Registered GitHub v3 REST API — 1,107 endpoints indexed
You: List my repos
Claude: [searches for "list repositories for authenticated user" → finds GET /user/repos → executes]
Here are your repositories: ...핵심 기능: 여러 API를 등록하고 그에 걸친 질문을 하세요. JitAPI는 등록된 모든 API를 검색하고 Claude가 호출을 체인으로 연결합니다.
You: Register the TMDB API and OpenWeatherMap API
Claude: ✓ Registered both APIs
You: Find the top popular movie on TMDB, then get the weather where it was filmed
Claude: [searches TMDB → GET /movie/popular → GET /movie/{id} for production locations
→ searches OpenWeather → GET /data/2.5/weather with the city]
The #1 popular movie is "Inception", filmed in Los Angeles.
Current weather in LA: 72°F, partly cloudy.Register API Ask a question
│ │
▼ ▼
Parse OpenAPI spec Embed query → vector search
│ │
▼ ▼
Build dependency graph Find relevant endpoints
│ │
▼ ▼
Embed all endpoints Expand with dependencies
│ │
▼ ▼
Store in vector DB Return schemas → Claude executes등록 — OpenAPI 사양을 파싱하고, 의존성 그래프(어떤 엔드포인트가 다른 엔드포인트의 데이터를 필요로 하는지)를 구축하며, 모든 엔드포인트에 대해 검색 가능한 임베딩을 생성합니다.
검색 — 질문을 하면 JitAPI가 쿼리를 임베딩하고 코사인 유사도를 통해 가장 관련성 높은 엔드포인트를 찾습니다.
확장 — 의존성 그래프가 필요한 선행 엔드포인트를 추가합니다 (예: "POST /orders를 위해 먼저 GET /users를 호출하여 user_id를 얻어야 함").
실행 — Claude가 엔드포인트 스키마를 받아 API 호출을 수행하고 단계 간에 데이터를 전달합니다.
도구 | 설명 |
| OpenAPI 사양 URL에서 API 등록 |
| 등록된 모든 API와 엔드포인트 개수 나열 |
| 자연어를 사용하여 엔드포인트 전체 의미론적 검색 |
| 의존성 해결 및 전체 스키마와 함께 관련 엔드포인트 찾기 |
| 특정 엔드포인트의 전체 스키마 가져오기 |
| 인증, 경로 매개변수, 쿼리 매개변수 및 본문을 포함한 단일 API 호출 실행 |
| 인증 구성 (API 키, 베어러 토큰, 기본 인증) |
| 등록된 API 및 모든 데이터 삭제 |
프로젝트 디렉토리에 .mcp.json을 생성하세요 (전역 액세스를 위해서는 ~/.claude.json 사용):
{
"mcpServers": {
"jitapi": {
"command": "uvx",
"args": ["jitapi"]
}
}
}Claude Desktop 설정에 추가하세요:
OS | 설정 경로 |
macOS |
|
Windows |
|
Linux |
|
{
"mcpServers": {
"jitapi": {
"command": "uvx",
"args": ["jitapi"]
}
}
}JitAPI는 로컬 임베딩(fastembed)과 즉시 작동하며 API 키가 필요 없습니다. 대규모 API에서 더 나은 검색 품질을 원하시면 클라우드 임베딩 제공자를 추가할 수 있습니다:
제공자 | 품질 | 설정 |
로컬 (기본값) | 좋음 | 없음 — 즉시 작동 |
Voyage AI (권장) | 우수 |
|
OpenAI | 우수 |
|
Cohere | 매우 좋음 |
|
MCP 설정의 env 블록에 API 키를 설정하세요:
{
"mcpServers": {
"jitapi": {
"command": "uvx",
"args": ["jitapi"],
"env": {
"VOYAGE_API_KEY": "your-key-here"
}
}
}
}제공자는 사용 가능한 환경 변수에서 자동으로 감지됩니다. 우선순위: Voyage AI > OpenAI > Cohere > 로컬.
등록 후 API 인증을 구성하세요. 권장되는 방법은 환경 변수를 사용하는 것이며, 이를 통해 비밀 정보가 디스크에 기록되지 않습니다:
{
"mcpServers": {
"jitapi": {
"command": "uvx",
"args": ["jitapi"],
"env": {
"GITHUB_TOKEN": "ghp_...",
"OPENWEATHER_API_KEY": "your-key-here"
}
}
}
}그다음 Claude에게 환경 변수를 사용하도록 지시하세요:
You: Set bearer auth for GitHub using env var GITHUB_TOKEN
Claude: [calls set_api_auth with auth_type="bearer", env_var="GITHUB_TOKEN"]
✓ Auth configured for github (from env var $GITHUB_TOKEN)env_var를 사용하면 JitAPI는 요청 시 환경에서 비밀 정보를 읽습니다. 환경 변수 이름만 유지되며 자격 증명 자체는 절대 저장되지 않습니다.
자격 증명을 직접 전달할 수도 있습니다 (0600 권한으로 ~/.jitapi/auth.json에 저장됨):
You: Set API key auth for OpenWeather with param name "appid"
Claude: [calls set_api_auth with auth_type="api_key_query", credential="...", param_name="appid"]
✓ Auth configured for openweather지원되는 인증 유형: bearer, api_key_header, api_key_query, basic.
보안 참고:
env_var를 사용할 때 자격 증명은 런타임에 해결되며 파일 시스템에 절대 닿지 않습니다. 자격 증명을 직접 전달할 경우, 비밀 정보는~/.jitapi/auth.json에 일반 텍스트 JSON으로 저장됩니다 (파일 권한0600, 디렉토리0700). 프로덕션 환경에서는env_var방식을 권장합니다.
변수 | 필수 | 설명 |
| 아니오 | Voyage AI API 키 (권장 클라우드 제공자) |
| 아니오 | OpenAI API 키 (대체 클라우드 제공자) |
| 아니오 | Cohere API 키 (대체 클라우드 제공자) |
| 아니오 | 데이터 디렉토리 (기본값: |
| 아니오 | DEBUG, INFO, WARNING, ERROR (기본값: INFO) |
git clone https://github.com/nk3750/jitapi.git
cd jitapi
pip install -e ".[dev]"
pytest
ruff check src/MIT
Execute an API call. Make sure authentication is configured first.
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | The API identifier | |
| endpoint_id | Yes | The endpoint to call (e.g., 'GET /users/{id}') | |
| path_params | No | Path parameter values | |
| query_params | No | Query parameter values | |
| body | No | Request body for POST/PUT/PATCH |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the auth prerequisite but fails to disclose that this tool makes external network requests, may have side effects depending on the HTTP method (POST/PUT/DELETE), or describe the response format. Significant gaps remain.
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?
Two sentences with zero waste: first states purpose, second states prerequisite. Efficiently front-loaded and appropriately sized for the information provided.
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?
For a tool with 5 parameters, nested objects, no output schema, and zero annotations, the description is insufficient. It omits what the tool returns, error handling behavior, and whether operations are potentially destructive (mutations possible via POST/PUT in endpoint_id).
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 has 100% description coverage (all 5 parameters documented). The description adds no parameter-specific semantics, but baseline 3 is appropriate since the schema already comprehensively documents api_id, endpoint_id, path_params, query_params, and body.
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 uses specific verb 'Execute' and resource 'API call', clearly distinguishing this runtime/execution tool from sibling management tools like register_api, delete_api, and list_apis. However, it lacks explicit scope clarification (e.g., 'HTTP request to configured endpoints') that would make it a 5.
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 provides one critical prerequisite ('Make sure authentication is configured first'), implying it should be used after set_api_auth. However, it lacks explicit 'when to use vs when not to use' guidance or alternatives (e.g., 'use get_endpoint_schema to inspect before calling').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a registered API and all its data including endpoints, embeddings, dependency graph, and authentication credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | The API identifier to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses the destructive cascade (endpoints, embeddings, credentials). However, it omits critical mutation context such as irreversibility, permission requirements, or confirmation behavior.
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, front-loaded sentence with zero waste. Every clause earns its place by specifying the action and enumerating the cascading deletion scope 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?
For a single-parameter destructive operation with no output schema, the description adequately covers the deletion scope. It could be improved by mentioning return value indicators or confirmation requirements, but it satisfies the essential disclosure needs for this tool 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?
The input schema has 100% description coverage for the single 'api_id' parameter. The description does not add semantic detail beyond the schema's 'The API identifier to delete', meeting the baseline expectation when schema coverage is high.
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 provides a specific verb ('Delete') and resource ('registered API'), and explicitly distinguishes this from sibling tools by detailing the comprehensive scope of deletion ('all its data including endpoints, embeddings, dependency graph, and authentication credentials').
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 implies the tool is for permanent removal by enumerating what gets destroyed, but lacks explicit when-to-use guidance, prerequisites, or named alternatives (e.g., when to use this vs. simply unregistering or disabling).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full schema for a specific endpoint. Use this to get detailed parameter and response information.
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | The API identifier | |
| endpoint_id | Yes | The endpoint identifier (e.g., 'GET /users/{id}') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to indicate whether this is a safe/idempotent read operation, what format the schema is returned in, or whether there are rate limits or caching considerations. It only repeats the functional purpose.
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 consists of two efficient sentences with zero waste. It is front-loaded with the action ('Get the full schema') followed immediately by usage context, making it easy for an agent to parse quickly.
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?
Given the tool's simplicity (2 parameters, no nested objects) and 100% schema coverage, the description is minimally adequate. However, since no output schema exists, the description could have been more specific about the return structure beyond 'detailed parameter and response information.'
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?
The input schema has 100% description coverage ('The API identifier' and 'The endpoint identifier'), establishing a baseline of 3. The description adds minimal parameter semantics beyond referencing 'a specific endpoint,' relying entirely on the schema to document the parameter purposes and format.
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 the tool retrieves 'the full schema for a specific endpoint' with specific verb (get) and resource (schema). It implies distinction from sibling 'search_endpoints' by emphasizing 'full schema' and 'detailed' information versus listing, though it doesn't explicitly name the alternative.
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 second sentence provides implied usage guidance ('Use this to get detailed parameter and response information'), suggesting when to invoke it. However, it lacks explicit 'when not to use' guidance or comparison to siblings like 'call_api' or 'search_endpoints' that might be confused for this use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What you want to accomplish (e.g., 'create a user and place an order') | |
| api_id | Yes | The API to use | |
| max_steps | No | Maximum number of endpoints to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: returns 'search results expanded with their dependencies' and enables planning of 'API calls in the right order.' Missing minor details like rate limits or specific error conditions, but captures the essential read-only, planning-oriented nature.
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?
Three sentences with zero waste. Front-loaded with purpose ('Get relevant endpoints...'), followed by return value description, and closes with explicit workflow guidance. Every sentence earns its place.
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?
Despite no output schema and no annotations, the description adequately explains what the tool returns ('search results expanded with their dependencies') and the next step in the workflow. Sufficient for a discovery/planning tool, though explicit mention of output structure would improve this to a 5.
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 has 100% description coverage with clear examples (e.g., 'create a user and place an order'). The description mentions 'accomplishing a task' which conceptually maps to the 'query' parameter, but does not add syntax details or formatting rules beyond what the schema already provides. Baseline score appropriate for high schema coverage.
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?
States specific action ('Get relevant endpoints') with key features ('dependency resolution and full schemas') and scope ('accomplishing a task'). Clearly distinguishes from sibling 'call_api' by emphasizing planning versus execution, and from 'search_endpoints' by highlighting dependency resolution.
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?
Explicitly directs the workflow: 'After reviewing the results, use call_api to execute each step.' This creates clear separation between when to use this tool (planning/discovery) versus the sibling execution tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered APIs with their basic information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It confirms a read operation via 'List' but fails to specify what 'basic information' includes, whether pagination is supported, or any rate limiting concerns.
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?
Single sentence of 9 words is appropriately concise and front-loaded with the action verb. However, given the lack of annotations and output schema, the extreme brevity leaves significant gaps that additional context could have filled.
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?
While adequate for a zero-parameter tool, the description lacks sufficient detail given the absence of an output schema and annotations. It fails to clarify what constitutes 'basic information' or how this differs from the more detailed data returned by 'get_endpoint_schema'.
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?
The input schema contains 0 parameters, establishing a baseline of 4. The description does not need to compensate for missing parameter documentation, though it confirms the parameter-less nature by implying an unfiltered 'list all' operation.
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 uses a specific verb ('List') and clear resource ('registered APIs'), and specifies scope ('all' with 'basic information'). It implicitly distinguishes from 'search_endpoints' by suggesting unfiltered enumeration versus targeted search, though it doesn't explicitly clarify this distinction.
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?
No guidance provided on when to use this versus siblings like 'search_endpoints' (for filtering) or 'get_endpoint_schema' (for detailed specification). No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new API by ingesting its OpenAPI specification. This parses the spec, builds a dependency graph, and creates searchable embeddings.
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | Unique identifier for this API (e.g., 'stripe', 'github') | |
| spec_url | Yes | URL to the OpenAPI specification (JSON or YAML) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses internal side effects: parsing the spec, building a dependency graph, and creating searchable embeddings. However, it lacks explicit safety information (idempotency, error handling on duplicate api_id, or execution time expectations).
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?
Two efficient sentences with zero waste: the first establishes the primary action and method, while the second explains valuable internal processing mechanics. Information is front-loaded and appropriately sized.
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?
Given no output schema and no annotations, the description adequately covers the tool's purpose and internal mechanics (parsing, embeddings). It could be improved by clarifying idempotency behavior or return value structure, but the core functionality is well-documented given the 100% schema coverage.
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?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'OpenAPI specification' which maps to spec_url and implies api_id through 'new API', but does not add syntax details, format constraints, or examples beyond the schema definitions.
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 provides a specific verb ('Register') and resource ('API'), and clearly distinguishes this from sibling tools like delete_api, call_api, or list_apis by specifying this is for 'new' API ingestion via OpenAPI specification.
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 word 'new' implies this is for initial registration rather than updating existing APIs, but there is no explicit 'when to use' guidance, workflow context, or named alternatives to guide the agent in selecting this over siblings like set_api_auth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for API endpoints using natural language. Returns semantically similar endpoints based on the query.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language description of what you're looking for | |
| api_id | No | Optional: limit search to a specific API | |
| top_k | No | Number of results to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully explains the matching logic (semantic similarity) but omits operational details like auth requirements, rate limits, read-only status, error behaviors, or the structure/format of returned endpoint objects.
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?
Two sentences with zero waste. The first establishes the action and input method; the second establishes the return value. Information is front-loaded and every word earns its place.
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?
Given the tool's simple 3-parameter structure with complete schema documentation and no output schema, the description is sufficiently complete. It conceptually explains the return value (semantically similar endpoints), though it could benefit from describing the output structure or error scenarios.
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?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'natural language' which maps to the query parameter, but does not augment the schema with additional guidance like example queries, format constraints, or the relationship between api_id filtering and search scope.
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 the action (search), resource (API endpoints), and method (natural language/semantic similarity). It implicitly distinguishes from list_apis via the 'natural language' and 'semantically similar' qualifiers, but does not explicitly reference sibling tools to clarify when to use each.
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 implies usage context through 'natural language' (suggesting use when exact endpoint names are unknown), but provides no explicit when-to-use guidance, exclusions, or named alternatives like list_apis. The agent must infer when semantic search is preferred over listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | The API identifier | |
| auth_type | Yes | Type of authentication | |
| credential | No | The API key or bearer token. Not required when env_var is set. | |
| env_var | No | Environment variable name that holds the credential (e.g., 'GITHUB_TOKEN'). When set, the secret is read from this env var at request time and never written to disk. | |
| header_name | No | Header name for API key (default: X-API-Key) | |
| param_name | No | Query param name for API key auth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully discloses the critical security behavior that env_var credentials are 'never stored on disk' and resolved at request time. However, it omits other important behavioral traits for a configuration tool: whether this overwrites existing auth, validation behavior, and idempotency semantics.
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 consists of three tightly constructed sentences with zero waste: sentence 1 establishes purpose, sentence 2 enumerates capabilities, and sentence 3 provides critical security guidance. Information is front-loaded and every clause earns its place.
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?
Given the 100% schema coverage and lack of output schema, the description adequately covers the primary function. However, for a configuration/mutation tool with zero annotations indicating side effects or safety, the description should disclose overwrite behavior and validation semantics to be considered complete. As is, it leaves operational questions unanswered.
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?
While the schema has 100% coverage (baseline 3), the description adds meaningful semantic context beyond the schema. Specifically, it clarifies the security implication of the env_var parameter ('never stored on disk'), which is not explicitly stated in the schema's technical description of the parameter, and maps the auth types to their transport mechanisms (header vs query param).
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 the specific action ('Configure authentication') and resource ('for an API'), and enumerates supported auth types (API key header/query, bearer). It implicitly distinguishes from siblings like call_api or register_api by focusing specifically on auth configuration, though it could explicitly clarify this is a prerequisite for call_api.
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 provides internal guidance on parameter selection ('Use env_var to reference a secret'), helping users choose between credential and env_var parameters. However, it lacks explicit workflow guidance regarding when to use this tool versus siblings (e.g., 'use this before call_api') or prerequisites for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0call_apidelete_apiget_endpoint_schemaget_workflowlist_apisregister_apisearch_endpointsset_api_authScored 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.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Discover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
