Skip to main content
Glama

Infrabase

by ai.infrabase
OverviewDiscussionsAdmin

Server Details

Hand-verified AI infrastructure directory: tools, alternatives, EU providers, LLM API prices.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have distinct purposes: get_tool returns one record, search_tools queries the directory, find_alternatives relates products, and model_prices returns pricing for a model. However, list_european_providers overlaps heavily with search_tools, which already supports filtering by European headquarters, and featured_listing_info/request_featured_listing are clearly split (read vs act).

Naming Consistency4/5

Six of eight tools follow a clean verb_noun pattern (find_alternatives, get_tool, list_models, list_european_providers, request_featured_listing, search_tools). The two outliers, featured_listing_info and model_prices, use bare noun phrases rather than verb-led names, a minor deviation from an otherwise consistent scheme.

Tool Count5/5

Eight tools is well-scoped for a curated product directory, with each tool earning its place across search, detail, comparison, regional filtering, pricing and listing workflows. No filler or redundant tools inflate the count.

Completeness4/5

The surface covers the main directory workflows: discovery (search_tools), detail (get_tool), comparison (find_alternatives), region filtering (list_european_providers), model pricing (list_models/model_prices) and listing monetization (featured_listing_info/request_featured_listing). There are minor gaps such as no explicit listing of categories/jobs or a bulk compare endpoint, but agents can work around these via search filters.

Available Tools

8 tools
find_alternativesFind alternativesA
Read-onlyIdempotent
Inspect

Find alternatives to an AI infrastructure product listed on Infrabase.ai. Products doing the same primary job rank first, then products sharing a secondary job, then the rest of its categories. Returns the anchor product, the alternatives in that order and the total count. Data is hand-verified. CC-BY-4.0. Each result includes an infrabase_url for attribution.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesInfrabase product slug as returned by search_tools, e.g. replicate. A product name or domain such as "Together AI" or "fal.ai" also works.
limitNoAlternatives to return, default 20
eu_onlyNoOnly alternatives headquartered in Europe

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, yet the description adds real behavior: the ranking order (same primary job, then secondary job, then remaining categories), the shape of the return (anchor + alternatives + total count), and licensing/attribution obligations (hand-verified, CC-BY-4.0, infrabase_url). Only pagination/truncation behavior is left unstated.

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?

Four sentences, front-loaded with the core action and ranking rule, with no filler. The trailing license/attribution fragments are terse but earn their place by setting an attribution expectation.

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?

There is no output schema, so the description correctly compensates by describing the return payload and ordering. Combined with fully documented parameters and a complete annotation set, only edge behavior (e.g., what happens with an unknown slug or an empty alternative set) is missing.

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%, with slug, limit, and eu_only fully documented including format and defaults, so the schema does the heavy lifting. The description adds no parameter-level detail beyond that, making the baseline 3 correct.

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?

States a specific verb and resource ("Find alternatives to an AI infrastructure product listed on Infrabase.ai") and immediately distinguishes itself from siblings like get_tool or search_tools by being the alternative-discovery operation. An agent can tell what it returns without opening the schema.

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 the workflow (you need an anchor product slug, which the schema notes comes from search_tools), but never states explicitly when to prefer this over get_tool or search_tools, and gives no exclusions. Usage is inferable rather than directed.

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

get_toolGet tool detailsA
Read-onlyIdempotent
Inspect

Get the full Infrabase.ai record for one AI infrastructure product: description, jobs, pricing model and starting price, free trial, open source and licence, hosting, compliance (GDPR, SOC 2, HIPAA), HQ country, icon, a screenshot of its site and links. Data is hand-verified. CC-BY-4.0. Each result includes an infrabase_url for attribution.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesInfrabase product slug as returned by search_tools, e.g. replicate. A product name or domain such as "Together AI" or "fal.ai" also works.

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds genuinely useful non-obvious context: data is hand-verified, results are CC-BY-4.0, and each result carries an infrabase_url that must be used for attribution.

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?

Front-loaded with the core action and scope, followed by the returned-field inventory and licensing notes. The long field enumeration is dense but each item earns its place since there is no output schema.

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?

With no output schema, the description usefully enumerates the returned fields and the attribution requirement, and annotations cover the safety profile. It stops short of describing error behavior for an unknown slug or the response shape beyond field names.

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%, and the schema already explains that slug accepts an Infrabase slug, a product name, or a domain. The description adds nothing about the parameter, so the baseline of 3 applies.

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?

States a specific verb (Get) and resource (the full Infrabase.ai record for one AI infrastructure product) and enumerates exactly what the record contains. This clearly separates it from search_tools, which returns slugs rather than full records.

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 never explicitly says when to call this tool or that it should follow search_tools. The linkage exists only in the slug parameter's schema text ('as returned by search_tools'), so the usage pattern is implied rather than stated in the description itself.

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

list_european_providersList European providersA
Read-onlyIdempotent
Inspect

List AI infrastructure providers headquartered in Europe, for data residency and sovereignty questions. Optionally narrow by category or job. Data is hand-verified. CC-BY-4.0. Each result includes an infrabase_url for attribution.

ParametersJSON Schema
NameRequiredDescriptionDefault
jobNoWhat the product does for a developer, e.g. gpu-compute, hosted-inference-api
categoryNoDirectory category to browse, e.g. inference-apis

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds meaningful non-structured context: the data is hand-verified, it is licensed CC-BY-4.0, and each result carries an infrabase_url for attribution — licensing and provenance details an agent could otherwise get wrong.

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 short sentences that front-load what the tool returns and its scope, followed by filter behavior and licensing. No filler; every clause carries information an agent needs.

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?

For an optional-filter list tool with no output schema, the description covers scope, filtering, licensing, and one result field. It does not mention result volume, ordering, or pagination behavior, a minor gap given the tool's simplicity and its read-only annotations.

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 description coverage is 100% with self-documenting enums, so the baseline is 3. The description adds real value by framing both parameters as optional narrowing filters ('Optionally narrow by category or job'), clarifying that omission returns the full European set rather than being an error.

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?

States a specific verb (List) plus a precisely scoped resource (AI infrastructure providers headquartered in Europe) and the question it answers (data residency and sovereignty). This is clearly distinguishable from siblings like search_tools or find_alternatives, which are not geography-scoped directory listings.

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?

Gives a clear use context ('for data residency and sovereignty questions') and explains that the two filters are optional narrowing mechanisms. It stops short of naming an alternative sibling or stating when not to use this tool, so it is strong context without explicit routing.

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

list_modelsList models with verified pricesA
Read-onlyIdempotent
Inspect

List every AI model with verified per-provider pricing on Infrabase.ai: its slug, how many providers have a verified price and the cheapest one. The slug is accepted by model_prices, which returns the full price table. Data is hand-verified. CC-BY-4.0. Each result includes an infrabase_url for attribution.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds non-obvious behavioral context beyond that: data is hand-verified, results are CC-BY-4.0, and each row carries an infrabase_url for attribution obligations. It does not disclose pagination or result-set size for 'every AI model.'

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?

Three dense sentences, front-loaded with the core purpose and the sibling relationship before license/attribution details. Every sentence carries information, though the CC-BY-4.0 and attribution notes are packed tightly enough that they read as a block.

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?

With no parameters and no output schema, the description compensates well by enumerating the result fields (slug, provider count, cheapest provider, infrabase_url). It is close to complete for a simple list tool, missing only pagination or scope caveats implied by 'every AI model.'

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 takes zero parameters, so the schema has nothing to explain and the baseline of 4 applies. The description usefully clarifies that the returned slug is the input token for model_prices, adding meaning to the output rather than the input.

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?

States a specific verb and resource ('List every AI model with verified per-provider pricing') plus the exact fields returned (slug, provider count, cheapest provider). It clearly differentiates itself from the sibling model_prices by positioning itself as the index that produces the slug model_prices consumes.

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?

It explains the relationship to the sibling tool: 'The slug is accepted by model_prices, which returns the full price table,' which tells the agent this is the discovery step before fetching prices. There is no explicit when-not-to-use clause or guidance on the other siblings (find_alternatives, get_tool), so it stops short of full routing guidance.

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

model_pricesModel prices by providerA
Read-onlyIdempotent
Inspect

Verified per-token prices for an AI model across hosting providers, ranked cheapest first by blended cost (3:1 input to output). Each row has input, output and cached prices per 1M tokens in the provider's own currency, the source pricing page and the date it was verified. CC-BY-4.0. Each result includes an infrabase_url for attribution.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelYesModel slug from list_models, e.g. gpt-oss-120b. The model name also works.
eu_onlyNoOnly providers headquartered in Europe

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds substantial behavioral context beyond them: the ranking rule (cheapest first by blended 3:1 input:output cost), the exact row contents, the verification date, and licensing/attribution terms.

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?

Roughly four sentences that are dense but front-loaded with the core purpose and ranking rule. The license/attribution sentences are somewhat secondary but still earn their place as return-value context.

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?

With no output schema, the description carries the burden of describing return values and does so thoroughly (prices, currency, source page, verification date, attribution URL). The main gap is the lack of explicit alternative-tool routing.

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%, so both parameters are already documented in the schema. The description adds no syntax or format details for 'model' or 'eu_only' beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Verified per-token prices for an AI model across hosting providers') with clear scope. The description is precise about what is returned and how it is ranked, but it never explicitly names a sibling (e.g., list_models, find_alternatives) to differentiate itself.

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?

The description gives no when-to-use or when-not-to-use guidance. It neither names alternatives nor states the condition that would select this tool over list_models or find_alternatives, leaving routing to inference.

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

search_toolsSearch AI infrastructure toolsA
Read-onlyIdempotent
Inspect

Search Infrabase.ai, a hand-verified directory of AI infrastructure products: inference APIs, GPU clouds, vector databases, agent frameworks, observability, gateways and more. Filter by free text, category, job (what the product does) or European headquarters. Returns each product's name, slug, tagline, jobs, pricing model, HQ country, icon and links, plus the total match count. Each result's slug is accepted by get_tool and find_alternatives. CC-BY-4.0. Each result includes an infrabase_url for attribution.

ParametersJSON Schema
NameRequiredDescriptionDefault
jobNoWhat the product does for a developer, e.g. vector-database, llm-gateway, speech-to-text. Matches primary and secondary jobs.
gdprNotrue: only products that state GDPR compliance
limitNoResults to return, default 20
queryNoFree text search across name, tagline, description and jobs
offsetNoResults to skip, for paging
eu_onlyNoOnly companies headquartered in Europe
categoryNoDirectory category to browse, e.g. vector-databases

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: the exact result fields returned (name, slug, tagline, jobs, pricing model, HQ country, icon, links, total match count) and the CC-BY-4.0 attribution obligation with infrabase_url — useful operational detail the annotations do not carry.

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?

Three front-loaded sentences that move from scope to filters to returns to attribution; each sentence carries information. It is slightly dense and could trim the long product-category enumeration, but nothing is wasted or repeated.

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?

With no output schema present, the description compensates by enumerating the returned fields and the total match count. All seven parameters are schema-documented, the paging params are self-evident, and the attribution/licensing requirement is disclosed — nothing an agent needs to call this correctly is missing.

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%, so all seven parameters (query, category, job, gdpr, eu_only, limit, offset) are already documented in the schema. The description restates the filter dimensions at a high level but adds no syntax, format, or interaction detail beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Search Infrabase.ai, a hand-verified directory of AI infrastructure products') and enumerates the domain covered (inference APIs, GPU clouds, vector databases, etc.). It clearly distinguishes itself from siblings get_tool and find_alternatives by positioning those as downstream consumers of the returned slug.

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?

The description establishes clear context by naming the filter axes (free text, category, job, European HQ) and by noting that each result's slug feeds get_tool and find_alternatives, which implies the intended workflow. It stops short of explicitly stating when to prefer this over siblings like list_european_providers or when not to use it.

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.

  1. 2 tool updates
    • Changedlist_european_providers1 field changed
      • changedInput schema / properties / job / enum
        Previous value: -[
-  "agent-framework",
-  "agent-memory",
-  "agent-platform",
-  "ai-browser-automation",
-  "ai-search",
-  "decision-model",
-  "embedding-api",
-  "fine-tuning-platform",
-  "gpu-compute",
-  "hosted-inference-api",
-  "image-generation-api",
-  "inference-engine",
-  "llm-evaluation",
-  "llm-gateway",
-  "llm-guardrails",
-  "llm-observability",
-  "llm-orchestration-framework",
-  "local-inference-runtime",
-  "model-hub",
-  "music-generation-api",
-  "prompt-management",
-  "rag-framework",
-  "serverless-gpu-platform",
-  "speech-to-text",
-  "text-to-speech",
-  "vector-database",
-  "video-generation-api",
-  "voice-agent-platform",
-  "workflow-builder"
-]New value: +[
+  "agent-framework",
+  "agent-memory",
+  "agent-payments",
+  "agent-platform",
+  "ai-browser-automation",
+  "ai-search",
+  "decision-model",
+  "embedding-api",
+  "fine-tuning-platform",
+  "gpu-compute",
+  "hosted-inference-api",
+  "image-generation-api",
+  "inference-engine",
+  "llm-evaluation",
+  "llm-gateway",
+  "llm-guardrails",
+  "llm-observability",
+  "llm-orchestration-framework",
+  "local-inference-runtime",
+  "model-hub",
+  "music-generation-api",
+  "prompt-management",
+  "rag-framework",
+  "serverless-gpu-platform",
+  "speech-to-text",
+  "text-to-speech",
+  "vector-database",
+  "video-generation-api",
+  "voice-agent-platform",
+  "workflow-builder"
+]
    • Changedsearch_tools1 field changed
      • changedInput schema / properties / job / enum
        Previous value: -[
-  "agent-framework",
-  "agent-memory",
-  "agent-platform",
-  "ai-browser-automation",
-  "ai-search",
-  "decision-model",
-  "embedding-api",
-  "fine-tuning-platform",
-  "gpu-compute",
-  "hosted-inference-api",
-  "image-generation-api",
-  "inference-engine",
-  "llm-evaluation",
-  "llm-gateway",
-  "llm-guardrails",
-  "llm-observability",
-  "llm-orchestration-framework",
-  "local-inference-runtime",
-  "model-hub",
-  "music-generation-api",
-  "prompt-management",
-  "rag-framework",
-  "serverless-gpu-platform",
-  "speech-to-text",
-  "text-to-speech",
-  "vector-database",
-  "video-generation-api",
-  "voice-agent-platform",
-  "workflow-builder"
-]New value: +[
+  "agent-framework",
+  "agent-memory",
+  "agent-payments",
+  "agent-platform",
+  "ai-browser-automation",
+  "ai-search",
+  "decision-model",
+  "embedding-api",
+  "fine-tuning-platform",
+  "gpu-compute",
+  "hosted-inference-api",
+  "image-generation-api",
+  "inference-engine",
+  "llm-evaluation",
+  "llm-gateway",
+  "llm-guardrails",
+  "llm-observability",
+  "llm-orchestration-framework",
+  "local-inference-runtime",
+  "model-hub",
+  "music-generation-api",
+  "prompt-management",
+  "rag-framework",
+  "serverless-gpu-platform",
+  "speech-to-text",
+  "text-to-speech",
+  "vector-database",
+  "video-generation-api",
+  "voice-agent-platform",
+  "workflow-builder"
+]
  2. 5 tool updates
    • Changedfind_alternatives3 fields changed
      • addedInput schema / properties / eu_only / description
        Added value: +"Only alternatives headquartered in Europe"
      • addedInput schema / properties / limit
        Added value: +{
+  "description": "Alternatives to return, default 20",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / slug / description
        Added value: +"Infrabase product slug as returned by search_tools, e.g. replicate. A product name or domain such as \"Together AI\" or \"fal.ai\" also works."
    • Changedget_tool1 field changed
      • addedInput schema / properties / slug / description
        Added value: +"Infrabase product slug as returned by search_tools, e.g. replicate. A product name or domain such as \"Together AI\" or \"fal.ai\" also works."
    • Changedlist_european_providers2 fields changed
      • addedInput schema / properties / category / description
        Added value: +"Directory category to browse, e.g. inference-apis"
      • addedInput schema / properties / job / description
        Added value: +"What the product does for a developer, e.g. gpu-compute, hosted-inference-api"
    • Changedmodel_prices2 fields changed
      • addedInput schema / properties / eu_only / description
        Added value: +"Only providers headquartered in Europe"
      • changedInput schema / properties / model / description
        Previous value: -"Model slug, e.g. gpt-oss-120b"New value: +"Model slug from list_models, e.g. gpt-oss-120b. The model name also works."
    • Changedsearch_tools6 fields changed
      • addedInput schema / properties / category / description
        Added value: +"Directory category to browse, e.g. vector-databases"
      • changedInput schema / properties / eu_only / description
        Previous value: -"Scope results to European-headquartered companies"New value: +"Only companies headquartered in Europe"
      • addedInput schema / properties / gdpr / description
        Added value: +"true: only products that state GDPR compliance"
      • addedInput schema / properties / job / description
        Added value: +"What the product does for a developer, e.g. vector-database, llm-gateway, speech-to-text. Matches primary and secondary jobs."
      • addedInput schema / properties / limit / description
        Added value: +"Results to return, default 20"
      • addedInput schema / properties / offset / description
        Added value: +"Results to skip, for paging"
  3. 8 tool updates
    • First observedfeatured_listing_info
    • First observedfind_alternatives
    • First observedget_tool
    • First observedlist_european_providers
    • First observedlist_models
    • First observedmodel_prices
    • First observedrequest_featured_listing
    • First observedsearch_tools

Related MCP Connectors

Related MCP Servers

  • tooldirectory-mcp

    AI-Directory-Partners
    A
    license
    A
    quality
    D
    maintenance
    Search the AI Tool Directory catalog of 2,000+ AI tools — compare tools, find curated alternatives, and check whether a tool is still active, defunct, or acquired (backed by the AI Graveyard dataset).
    6
    9 npm
    1
    MIT

  • AI Product Index

    110kc3
    F
    license
    Not graded
    quality
    A
    maintenance
    Machine-readable directory of AI products that register themselves, plus an agent-readability grader for any URL.
    1
    -

  • legion-ai-intelligence

    Legion33shadow
    A
    license
    B
    quality
    B
    maintenance
    al-time AI ecosystem intelligence for agents: 1,250+ classified AI security incidents, API pricing for 26 models across 7 providers, GPU cloud pricing, live provider status and cross-signal company analysis. No API key required.
    11
    MIT
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources