Skip to main content
Glama
edlovesjava

mcp-api-bridge

by edlovesjava
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
AWS_REGIONNoAWS region for Bedrock and other servicesus-east-1
CATALOG_TOKENNoAuthentication token for the catalog API, as specified in the config's auth block
BEDROCK_EFFORTNoBedrock reasoning effort (low, medium, high; defaults to low)
BEDROCK_REGIONNoOverride AWS region specifically for Bedrock
BEDROCK_MODEL_IDNoOverride the Bedrock model ID (defaults to anthropic.claude-opus-5)
AWS_ACCESS_KEY_IDNoAWS access key ID (if not using other credential sources)
AWS_SECRET_ACCESS_KEYNoAWS secret access key (if not using other credential sources)
MCP_API_BRIDGE_CONFIGYesPath to the catalog configuration YAML file

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_catalogsA

List the configured catalogs and the vocabulary each one accepts.

Returns every catalog's filter names, types, allowed values, and sort options. Call this before catalog_search so you filter with names the catalog actually exposes.

Filters marked accepts_name are keyed by an opaque id upstream but take a human name here — pass "Chicago", not a region id. Where the value set is closed it is listed in allowed_values; where it is open (performers, venues) any name is accepted and resolved on the way through.

catalog_searchA

Search a catalog with keywords and explicit structured filters.

Args: query: Keyword terms only. Put constraints in filters, not here — a phrase like "under $80" left in the query fights the filter. api: Which catalog to search. Optional when only one is configured. filters: Filter names from list_catalogs mapped to values. A list value means "any of these". For accepts_name filters pass the human name — the bridge resolves it to the upstream id and reports what it chose in resolutions. sort: A sort name from list_catalogs. Omit for catalog default. page: 1-based page number. page_size: Results per page. Defaults to the catalog's configured size.

catalog_get_itemA

Fetch a single catalog item by its id.

Args: item_id: The catalog's own identifier, as returned in a search result's id field. api: Which catalog to read from. Optional when only one is configured.

understand_queryA

Turn a natural-language query into a structured search plan, without searching.

Uses Bedrock to split a shopper's phrasing into keywords, structured filters, a sort, and synonyms — restricted to the vocabulary the target catalog actually exposes. Use this when you want to inspect or adjust the plan before running it; use smart_search to do both at once.

Args: query: The user's request, in their own words. api: Which catalog's vocabulary to plan against. Optional when only one is configured.

smart_searchA

Interpret a natural-language query with Bedrock, then run the search.

Returns both the plan and the results, so you can see which filters were inferred and re-run with catalog_search if the interpretation is off. If the results are thin, the plan's expansions are alternative terms worth retrying.

Args: query: The user's request, in their own words — no need to strip constraints out first. api: Which catalog to search. Optional when only one is configured. page: 1-based page number. page_size: Results per page. Defaults to the catalog's configured size.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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.4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct role: list_catalogs exposes metadata, catalog_search executes structured searches, catalog_get_item fetches a single item, understand_query only plans from natural language, and smart_search both plans and searches. The descriptions explicitly contrast the NL tools and the structured-search tool, eliminating ambiguity.

Naming Consistency3/5

Tool names mix conventions: list_catalogs and understand_query are verb-first, while catalog_search and catalog_get_item are noun-first, and smart_search is an adjective-noun compound. The inconsistency is noticeable but not chaotic, with a 'catalog_' prefix for search/get actions providing some order.

Tool Count5/5

Five tools is a well-scoped size for a catalog search bridge: metadata discovery, structured search, item retrieval, NL interpretation, and NL search. Each tool earns its place with no redundant coverage, making the set feel appropriately lean.

Completeness5/5

The surface covers the full query lifecycle: discover catalogs, run structured searches, retrieve individual items, and process natural language either as a plan or as a plan-plus-search. As a read-only bridge, missing create/update/delete operations are not gaps; no dead ends remain for the stated purpose.

Resources