Which integrations are available for this server?

Allows AI agents to discover and resolve APIs for interacting with Reddit, such as summarizing posts or extracting data.

How do I use decixa-mcp?

1. Click on "Deploy 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., "@decixa-mcp find an API to summarize news articles" 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.

decixa-mcp

by koki-socialgist

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

decixa-mcp

Find the right API for your AI agent. 30,000+ listings tracked. 5,500+ verified live as of April 2026.

MCP Server for Decixa — The decision layer for AI Agents.

v0.1.7: intent-driven update. New resolve / discover tools replace search_apis / browse_apis (kept as deprecated aliases). See CHANGELOG.md for migration guide.

Quickstart

# Claude Code
npx decixa-mcp

// Claude Desktop — claude_desktop_config.json
{
  "mcpServers": {
    "decixa": {
      "command": "npx",
      "args": ["-y", "decixa-mcp"]
    }
  }
}

// Cursor / Windsurf — .cursor/mcp.json or .windsurf/mcp.json
{
  "mcpServers": {
    "decixa": {
      "command": "npx",
      "args": ["-y", "decixa-mcp"]
    }
  }
}

Related MCP server: Frostbyte MCP

What you can do

resolve({ intent: "get real-time BTC price" })
→ Returns top recommendation + up to 2 alternatives, ranked by Phase 3 vector + scoring

resolve({ intent: "summarize Reddit posts", budget: 0.005 })
→ Filters by cost, returns trust_evidence and latency tier

discover({ intent: "transcribe audio", budget: 0.01, sort: "price_asc" })
→ Returns multiple x402-verified candidates so the agent can choose

Why Decixa

Unlike x402.direct, Decixa verifies x402 compliance by actually probing each endpoint — not just metadata analysis.

	Decixa	x402.direct
Listings tracked	30,000+	~4,000
x402 verification	HTTP 402 probe (real)	Metadata scoring
Capability classification	9 verb-based axes	—
Intent → API resolution	`/api/agent/resolve`	—
MCP server	`npx decixa-mcp`	—

Tools

`resolve` (recommended, replaces `search_apis`)

Find the best API for a task using natural language. Returns top recommendation + up to 2 alternatives. Decixa uses Phase 3 vector + scoring (vector 0.70 + latency 0.05 + price 0.05 + tiebreak 0.20). When no candidate clears the similarity threshold, returns recommendation_status='no_match' with up to 2 suggestions.

Parameter	Type	Description
`intent` (required)	string	What you want to do (e.g. `"summarize news articles"`)
`budget`	number	Max USDC per call (e.g. `0.01`)
`latency`	string	`low` / `medium` / `high`
`min_similarity`	number	Similarity threshold (0.2–0.9, default `0.5`). Out-of-range → 400

Response includes recommendation_status ("resolved" or "no_match").

`discover` (recommended, replaces `browse_apis`)

List APIs ranked by intent. Returns multiple candidates so the agent can choose. Verified-x402 only.

Parameter	Type	Description
`intent` (required)	string	Natural-language intent (mapped to server's `task` query param)
`tag`	string	Filter by capability tag (e.g. `"Market Data"`, `"Risk Score"`)
`budget`	number	Max USDC per call
`latency_tier`	string	`low` / `medium` / `high`
`execution_mode`	string	`sync` / `async`
`pricing_model`	string	`per_call` / `subscription` / `hybrid`
`min_similarity`	number	Similarity threshold (0.2–0.9, default `0.3`). Out-of-range → 400
`sort`	string	`relevance` (default) / `price_asc` / `price_desc` / `latency_asc` / `trust` / `calls` (deprecated)
`limit`	integer	Results per page (1–50, default 20)
`offset`	integer	Pagination offset

Response includes search_mode, min_similarity_applied, no_match_reason, top_candidates_below_threshold.

`search_apis` (deprecated alias for `resolve`)

DEPRECATED in v0.1.7. Will be removed in v1.0.0. Use resolve instead. Shares schema and handler with resolve.

`browse_apis` (deprecated alias for `discover`)

DEPRECATED in v0.1.7. Will be removed in v1.0.0. Use discover instead. Shares schema and handler with discover.

`get_api_detail`

Get full details for a specific API by ID.

Parameter	Type	Description
`api_id`	string	API ID from `resolve` or `discover`

Returns: endpoint URL, pricing, capability, tags, agent_compatibility, schema info, use_cases, trust_evidence (score / uptime_7d / p95_latency_ms / payment_req_parsed / last_checked / last_probed_at), provider, and verified_live flag. Prefer trust_evidence.score over legacy trust_score for new clients.

`get_index`

Entry point for agents new to Decixa. Returns platform overview, endpoints, and usage guidance.

No parameters required.

Migration from v0.1.6

Old	New	Notes
`search_apis({intent, capability, agent_ready})`	`resolve({intent, min_similarity?})`	Drop `capability` / `agent_ready`. They are silently ignored server-side (D-059).
`browse_apis({task, capability, agent_ready, sort})`	`discover({intent, sort})`	`task` → `intent`, drop `capability` / `agent_ready`. Default sort changed `trust` → `relevance`.
`list_capabilities({})`	(removed)	Capability filtering is no longer needed. Pass intent text + optional `tag` filter.

Strict MCP clients note: if your MCP client validates additionalProperties: false, it will reject capability / agent_ready arguments at the client side. Tolerant clients let them through, but Decixa silently ignores them server-side. Either way, remove them.

See CHANGELOG.md for full details.

Claude Code setup

See docs/claude-code.md for step-by-step Claude Code integration.

Environment Variables

Variable	Default	Description
`DECIXA_API_URL`	`https://api.decixa.ai`	Decixa API base URL
`DECIXA_API_KEY`	(empty)	API key — reserved for future use

License

MIT

Available Tools

6 tools

browse_apisA

DEPRECATED in v0.1.7. Use 'discover' instead. This alias will be removed in v1.0.0. [Original behavior preserved in this version: List APIs ranked by intent.]

ParametersJSON Schema

Name	Required	Description
`tag`	No	Filter by capability tag (e.g. 'Market Data', 'Risk Score').
`sort`	No	Sort preset. 'relevance' uses Phase 3 normalized score. 'calls' is deprecated and will be removed in Phase 4. Default: relevance.
`limit`	No	Number of results per page. Default: 20
`budget`	No	DEPRECATED in v0.1.9. Prefer cost_max_per_call_usdc. Maximum USDC cost per call. Invalid values silently ignored. When both budget and cost_max_per_call_usdc are set, the stricter (smaller) value applies.
`intent`	Yes	Natural-language intent. Mapped to the server's 'task' query parameter.
`offset`	No	Pagination offset. Default: 0
`latency_tier`	No	Filter by latency tier
`pricing_model`	No	Filter by pricing model
`execution_mode`	No	Filter by execution mode
`min_similarity`	No	Similarity threshold for vector search. Default 0.3. Out-of-range returns 400.
`latency_p95_max_ms`	No	v0.1.9 (D-084): Maximum measured p95 latency in milliseconds. Invalid values (≤0, NaN) return 400. APIs with no measured p95_latency_ms are excluded from results when this filter is set.
`cost_max_per_call_usdc`	No	v0.1.9 (D-084): Maximum cost per call in USDC. Invalid values (negative, NaN) return 400. When both budget and this are set, the stricter (smaller) value applies.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the deprecated status and preserves original behavior as listing APIs ranked by intent, which is sufficient for a read-only tool. It does not contradict any annotations (none exist).

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 extremely concise, using only one sentence to convey the deprecation status, alternative, and core behavior. Every part is necessary and well-structured.

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 tool has 12 parameters, no output schema, and no annotations, the description is minimal. It does not explain the ranking algorithm, pagination behavior, or how filters interact. However, the schema is well-documented, and the tool is deprecated, which lowers the need for extensive documentation.

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%, so baselines at 3. The description does not add any parameter-specific information beyond what the schema already provides. It does not explain how parameters affect the result or provide usage examples.

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 explicitly states the tool lists APIs ranked by intent, which is a specific verb+resource. It also distinguishes itself from the sibling tool 'discover' by indicating it is deprecated, thereby clarifying its purpose and relationship.

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 description clearly states the tool is deprecated and provides an alternative ('Use 'discover' instead'), including a timeline for removal. This gives explicit guidance on when not to use this tool and what to use instead.

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

discoverA

List APIs ranked by intent. Returns multiple candidates so the agent can choose. Decixa uses Phase 3 vector + scoring to rank verified-x402 APIs. Use this when you want to see options — use resolve when you want a single recommendation.

ParametersJSON Schema

Name	Required	Description
`tag`	No	Filter by capability tag (e.g. 'Market Data', 'Risk Score').
`sort`	No	Sort preset. 'relevance' uses Phase 3 normalized score. 'calls' is deprecated and will be removed in Phase 4. Default: relevance.
`limit`	No	Number of results per page. Default: 20
`budget`	No	DEPRECATED in v0.1.9. Prefer cost_max_per_call_usdc. Maximum USDC cost per call. Invalid values silently ignored. When both budget and cost_max_per_call_usdc are set, the stricter (smaller) value applies.
`intent`	Yes	Natural-language intent. Mapped to the server's 'task' query parameter.
`offset`	No	Pagination offset. Default: 0
`latency_tier`	No	Filter by latency tier
`pricing_model`	No	Filter by pricing model
`execution_mode`	No	Filter by execution mode
`min_similarity`	No	Similarity threshold for vector search. Default 0.3. Out-of-range returns 400.
`latency_p95_max_ms`	No	v0.1.9 (D-084): Maximum measured p95 latency in milliseconds. Invalid values (≤0, NaN) return 400. APIs with no measured p95_latency_ms are excluded from results when this filter is set.
`cost_max_per_call_usdc`	No	v0.1.9 (D-084): Maximum cost per call in USDC. Invalid values (negative, NaN) return 400. When both budget and this are set, the stricter (smaller) value applies.

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Mentions 'returns multiple candidates' and ranking mechanism, but lacks details on rate limits, auth needs, or failure behavior. Adequate for a read-like tool but could be more transparent.

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?

Extremely concise (two sentences plus a comparison), front-loaded with the purpose, and every sentence is informative.

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 12 parameters and no output schema, the description only says 'returns multiple candidates' without explaining structure, pagination, or how to use results. Incomplete for rich decision-making.

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 has 100% description coverage for all 12 parameters, so baseline is 3. Description adds no extra context beyond the schema for any parameter.

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 'List APIs ranked by intent' with specific verb and resource. Explicitly differentiates from sibling tool 'resolve' by stating 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.

Usage Guidelines5/5

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

Explicitly tells when to use this tool ('when you want to see options') and when to use the alternative ('use resolve when you want a single recommendation'). Provides clear context.

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

get_api_detailA

Get full details for a specific API by its ID. Returns endpoint URL, pricing, capability, tags, agent compatibility, schema info, use cases, trust signals (trust_evidence), and provider. Prefer trust_evidence.score (with uptime_7d / p95_latency_ms / payment_req_parsed) over legacy trust_score for new clients. The top-level verified_live boolean indicates whether this API is verified to accept x402 payments; unlike resolve/discover, detail also returns APIs that are not yet verified. Use this after resolve or discover to inspect a specific API before calling it.

ParametersJSON Schema

Name	Required	Description	Default
`api_id`	Yes	The API ID returned by search_apis (recommended.id) or browse_apis (apis[].id)

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the tool returns full details including trust signals, verified_live boolean, and that it includes unverified APIs (unlike resolve/discover). This provides adequate behavioral context for a read operation, though no side effects are mentioned.

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?

Description is concise (5 sentences) with front-loaded purpose. Each sentence adds unique information without redundancy. No wasted words.

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?

Given the tool's simplicity (1 param, no output schema, no annotations), the description is thorough. It covers purpose, parameter usage, return fields, and differentiation from siblings. Sufficient for an agent to decide when to use and how to interpret results.

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

Parameters5/5

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

Schema coverage is 100% with a single parameter api_id described in schema. Description adds value by specifying the source of the API ID: 'returned by search_apis (recommended.id) or browse_apis (apis[].id)', which aids in correct invocation beyond schema alone.

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 'Get full details for a specific API by its ID' and lists returned fields including endpoint URL, pricing, capability, tags, agent compatibility, schema info, use cases, trust signals, and provider. It distinguishes from siblings by noting that unlike resolve/discover, detail also returns APIs not yet verified, and mentions trust_evidence and verified_live boolean.

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

Usage Guidelines4/5

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

Description advises to 'Use this after resolve or discover to inspect a specific API before calling it,' providing clear context. It also recommends preferring trust_evidence.score over legacy trust_score for new clients, but does not explicitly list scenarios where this tool should not be used.

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

get_indexA

Fetch the Decixa agent index — a machine-readable overview of the platform including available endpoints, total API count, and usage guidance for AI agents. Good starting point for agents new to Decixa.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description must disclose behavior. It states a fetch operation and what it returns, but does not explicitly confirm read-only nature or any side effects, leaving minor ambiguity.

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?

Two sentences, no fluff. First sentence provides core purpose, second gives usage guidance. Efficiently structured.

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

Completeness4/5

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

Tool has no output schema, so description must explain return value. It mentions included content (endpoints, API count, usage guidance), but lacks details on format (e.g., JSON structure). Nearly complete for a simple index fetch.

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?

No parameters, and schema coverage is 100%. Baseline for 0 params is 4, and description adds no extra param info, which is acceptable.

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 fetches the Decixa agent index, a machine-readable overview, distinguishing it from siblings like 'get_api_detail' or 'browse_apis'.

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

Usage Guidelines4/5

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

Explicitly says 'Good starting point for agents new to Decixa,' indicating when to use it. Does not mention when not to use or alternative tools, but context is clear.

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

resolveA

Find the best API for a task using natural language. Returns the top recommendation and up to 2 alternatives. Decixa uses Phase 3 vector + scoring to rank verified-x402 APIs by intent. When no candidate clears the similarity threshold, returns recommendation_status='no_match' with suggestions. Use this when you want Decixa to pick — use discover when you want to see the list.

ParametersJSON Schema

Name	Required	Description
`budget`	No	DEPRECATED in v0.1.9. Prefer cost_max_per_call_usdc. Maximum USDC cost per call (e.g. 0.01). Invalid values silently ignored. When both budget and cost_max_per_call_usdc are set, the stricter (smaller) value applies.
`intent`	Yes	What you want to do in natural language (e.g. 'summarize news articles', 'get token price')
`latency`	No	Required response latency tier
`min_similarity`	No	Similarity threshold for vector search. Default 0.5. Out-of-range returns 400.
`latency_p95_max_ms`	No	v0.1.9 (D-084): Maximum measured p95 latency in milliseconds. Invalid values (≤0, NaN) return 400. APIs with no measured p95_latency_ms are excluded from results when this filter is set.
`cost_max_per_call_usdc`	No	v0.1.9 (D-084): Maximum cost per call in USDC. Invalid values (negative, NaN) return 400. When both budget and this are set, the stricter (smaller) value applies.

TDQS

A4.6/5.0

Behavior5/5

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

No annotations provided, but description covers key behaviors: vector scoring, threshold, no_match return with suggestions. Transparent about recommendation logic without need for annotations.

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?

Three sentences, front-loaded with core purpose and result. No unnecessary words. Efficient and clear structure.

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

Completeness4/5

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

Covers recommendation logic, fallback behavior, and distinguishes from sibling tool. No output schema, but description explains return values. Could slightly improve by noting required parameter or error cases, but overall complete.

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 100%, baseline 3. Description adds minimal parameter-level context (only mentions 'intent' implicitly). Schema already defines all parameters with descriptions.

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 it finds the best API using natural language, returns top recommendation and alternatives. It distinguishes from sibling tool 'discover' by specifying 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.

Usage Guidelines5/5

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

Explicitly says 'Use this when you want Decixa to pick — use discover when you want to see the list', providing clear when-to-use and when-not-to guidance with named alternative.

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

search_apisA

DEPRECATED in v0.1.7. Use 'resolve' instead. This alias will be removed in v1.0.0. [Original behavior preserved in this version: Find the best API for a task using natural language.]

ParametersJSON Schema

Name	Required	Description
`budget`	No	DEPRECATED in v0.1.9. Prefer cost_max_per_call_usdc. Maximum USDC cost per call (e.g. 0.01). Invalid values silently ignored. When both budget and cost_max_per_call_usdc are set, the stricter (smaller) value applies.
`intent`	Yes	What you want to do in natural language (e.g. 'summarize news articles', 'get token price')
`latency`	No	Required response latency tier
`min_similarity`	No	Similarity threshold for vector search. Default 0.5. Out-of-range returns 400.
`latency_p95_max_ms`	No	v0.1.9 (D-084): Maximum measured p95 latency in milliseconds. Invalid values (≤0, NaN) return 400. APIs with no measured p95_latency_ms are excluded from results when this filter is set.
`cost_max_per_call_usdc`	No	v0.1.9 (D-084): Maximum cost per call in USDC. Invalid values (negative, NaN) return 400. When both budget and this are set, the stricter (smaller) value applies.

TDQS

A4.3/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 the full burden. It discloses deprecation status and version removal, but lacks details on side effects, authorization needs, or other behavioral traits. For a search tool, more transparency about the search process and result behavior would be helpful.

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 very concise, fitting essential information (deprecation status, alternative, original behavior) into a single sentence. It is front-loaded with the most critical point: deprecation.

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 description is complete regarding deprecation and usage guidance, but it does not cover return format, pagination, or other search-specific behavior. Given the tool is deprecated, this might be acceptable, but for a non-deprecated tool it would be insufficient.

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%, baseline 3. The description adds value by noting deprecation of 'budget' and the interaction between 'budget' and 'cost_max_per_call_usdc', as well as constraints on 'latency_p95_max_ms' and 'cost_max_per_call_usdc'. This provides additional context 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 it finds the best API for a task using natural language, with a specific verb and resource. It also immediately indicates deprecation and directs to the sibling 'resolve', distinguishing its purpose.

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?

Explicitly states the tool is deprecated and instructs to use 'resolve' instead, providing a clear alternative and 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.9Jul 11, 2026
- First observedbrowse_apis
- First observeddiscover
- First observedget_api_detail
- First observedget_index
- First observedresolve
- First observedsearch_apis

Deploy Server

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

TDQS

A4/5.0

Scored 2026-07-11 23:30 across 6 tools

Disambiguation3/5

The core tools (discover, resolve, get_api_detail, get_index) have distinct purposes, but the presence of deprecated aliases (browse_apis, search_apis) that mirror functionalities introduces ambiguity. The deprecation notices help, but agents may still select the wrong tool without careful reading.

Naming Consistency3/5

Tool names mix conventions: some are single verbs ('discover', 'resolve'), some use 'get_' prefix ('get_api_detail', 'get_index'), and others follow verb_noun pattern ('browse_apis', 'search_apis'). While still readable, the inconsistency could confuse agents expecting a uniform pattern.

Tool Count4/5

With 6 tools (2 deprecated), the effective count is 4 core tools, which is appropriate for API discovery and details. The scope is well-focused, and the tools are not excessive.

Completeness4/5

The set covers key operations: listing (discover), best-match selection (resolve), detailed information (get_api_detail), and platform overview (get_index). There are no obvious gaps for the stated purpose of API discovery and inspection.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Zyla API Hub A
com.zylalabs
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
Developer Tools
82
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
H-Index A
ai.xr-utilities
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search Documentation Access
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21

Related MCP Servers

opendexterofficial
Payments & Billing Cryptocurrency
Dexter-DAO
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI agents to search, pay for, and call paid APIs using the x402 protocol, with automatic USDC settlement.
Updated 11 days ago (2026-09-05 01:39 UTC)
2
MIT
Frostbyte MCP
Developer Tools Web Scraping Code Execution
Robocular
A
license
Not graded
quality
C
maintenance
A unified MCP server providing AI agents with 40+ developer APIs including geolocation, crypto prices, DNS lookup, and web scraping. Enables natural language access to various tools through a single gateway.
Updated 6 months ago (2026-03-05 18:28 UTC)
1
MIT
ClawQL
API Testing Developer Tools Search
danielsmithdevelopment
A
license
Not graded
quality
B
maintenance
An MCP server for API discovery and execution with a token-efficient search -> execute workflow over OpenAPI, Google Discovery, and optional native GraphQL and gRPC sources.
Updated a day ago (2026-09-15 11:39 UTC)
60 npm
12
Apache 2.0
api-docs-mcp
Documentation Access Developer Tools
DucDA177
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI agents to explore, search, and query API definitions from OpenAPI/Swagger JSON files.
Updated 8 months ago (2026-01-27 14:25 UTC)
10 npm
MIT

decixa-mcp

Quickstart

What you can do

Why Decixa

Tools

resolve (recommended, replaces search_apis)

discover (recommended, replaces browse_apis)

search_apis (deprecated alias for resolve)

browse_apis (deprecated alias for discover)

get_api_detail

get_index

Migration from v0.1.6

Claude Code setup

Environment Variables

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

opendexterofficial

`resolve` (recommended, replaces `search_apis`)

`discover` (recommended, replaces `browse_apis`)

`search_apis` (deprecated alias for `resolve`)

`browse_apis` (deprecated alias for `discover`)

`get_api_detail`

`get_index`