Skip to main content
Glama
flo7up

AIUseCaseHub MCP

by flo7up
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

AIUseCaseHub MCP

Search source-linked enterprise AI deployments from your agent. Find examples by company, industry, technology, cloud provider and reported outcomes, then retrieve the underlying case for evidence and context.

Website · MCP documentation · Get an API key · Official registry record

This repository contains an optional runnable stdio adapter, integration examples and registry metadata for the hosted service. Connecting directly to the existing endpoint requires no server installation, hosting account or npm package.

Connect

  1. Choose a client supporting Streamable HTTP.

  2. Add the endpoint below with no authentication to try the public preview. No registration or key is needed.

  3. For full results, sign in to AIUseCaseHub's API page, generate a personal key and send it as X-API-Key.

https://basic-backend713-dsd8hygyfkc8d8f5.swedencentral-01.azurewebsites.net/api/mcp

Public preview configuration for clients using an mcpServers map:

{
  "mcpServers": {
    "aiusecasehub": {
      "url": "https://basic-backend713-dsd8hygyfkc8d8f5.swedencentral-01.azurewebsites.net/api/mcp"
    }
  }
}

Optional full-access configuration:

{
  "mcpServers": {
    "aiusecasehub": {
      "url": "https://basic-backend713-dsd8hygyfkc8d8f5.swedencentral-01.azurewebsites.net/api/mcp",
      "headers": {
        "X-API-Key": "<YOUR_PERSONAL_API_KEY>"
      }
    }
  }
}

Use your client's secret storage or environment-variable support for personal keys. Omit the entire authentication header for a free preview; an empty or invalid key remains an authentication error. Configuration formats vary by client.

The service supports the July 2026 stateless protocol and the older initialization handshake over Streamable HTTP (2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25). Current clients send request metadata on each POST; older clients negotiate through initialize. The direct endpoint offers an anonymous preview and optional personal API-key authentication.

Related MCP server: aipatterns-mcp-server

Run the stdio adapter

For clients and directory scanners that require a local process, this repository provides a stdio adapter using mcp-remote. It forwards requests to the real hosted MCP and returns its live tool definitions and results. It requires outbound HTTPS access to the endpoint above; it does not include a local database or the hosted backend.

With Node.js 22 or newer:

git clone https://github.com/flo7up/aiusecasehub-mcp.git
cd aiusecasehub-mcp
npm ci --ignore-scripts
node server.mjs

The process waits for MCP JSON-RPC on stdin. In a client configuration, use node as the command and the absolute path to server.mjs as its argument. Use node server.mjs directly rather than npm start in MCP clients, so npm's banner cannot enter the protocol stream.

Alternatively, build and run the container:

docker build -t aiusecasehub-mcp:local .
docker run --rm -i aiusecasehub-mcp:local

No key is required to start, initialize, list tools or use the limited preview. For full access, set AIUSECASEHUB_API_KEY in your client's secret environment; with Docker, add -e AIUSECASEHUB_API_KEY to forward an already-set environment variable. The adapter sends it as X-API-Key. An explicitly empty key fails locally; an invalid key remains an upstream authentication error. Omit the variable entirely for the preview.

The Docker image runs as a non-root user and installs locked dependencies during build. It publishes no HTTP port. The transport bridge is pinned to mcp-remote 0.8.2; its qs dependency is overridden to patched version 6.16.0.

To verify initialization, four live tool definitions and ping without using preview attempts:

node examples/verify-stdio.mjs
node examples/verify-stdio.mjs --docker

Add --exercise to either command to perform one real search and detail lookup (two anonymous preview attempts). This verifier always omits personal keys. CI builds the container and checks both transports without consuming tool-call credits.

Glama build configuration

Submit this public repository as AIUseCaseHub MCP. glama.json declares flo7up as the maintainer. The checked-in Dockerfile is runnable without credentials. If Glama asks for build configuration in its Dockerfile admin page, use Node.js 24, build command npm ci --omit=dev --ignore-scripts, and command arguments ["node", "server.mjs"] from the repository root. Leave API-key configuration unset for evaluation. All four tools are discovered from the hosted service, not from a static server card.

Free preview and full access

Public preview

Personal API key

Registration

Not required

Required

Search results

Up to 3

Up to 20

Case content

Source/context fields; descriptions up to 360 characters

Full published case data

Tool-call credits

0

2 per search; 1 per detail lookup

Preview allowance

10 tool-call attempts per IP per UTC hour

Does not consume the preview allowance

The anonymous service has a shared budget of 200 tool-call attempts per UTC hour. The limits are stored centrally and remain effective across workers and restarts. Shared gateways may share an IP allowance. Discovery and tool listing do not consume it. Rate-limit errors include retry guidance and a link to full access; a storage failure closes the preview temporarily instead of allowing unlimited calls.

Four tools

Tool

Use

Required argument

Credits with a personal key

search_usecases

General natural-language search with hybrid ranking

search_term

2

hybrid_search_usecases

Hybrid search with company, industry, geography, provider and technology filters

query

2

vector_search_usecases

Semantic similarity search

query

2

get_usecase_details

Retrieve a case returned by search

row_key

1

Search tools accept limit from 1 to 20, capped at 3 for public previews. Hybrid search also supports industry, country, technologies_used, cloud_provider, customer_name, partner_name, and boolean case-type filters such as isAgentCase and isRag. See the complete tool reference.

Search payloads include items, total, searchMode, dataSnapshot, and _mcp credit metadata. Pass an item's RowKey to get_usecase_details. Parse the MCP text content as JSON; use the source links and evidence fields when interpreting reported outcomes. A deployment example is not a guarantee of the same results elsewhere.

Example prompts:

  • Find AI deployments in insurance that report measurable claims-processing outcomes. Retrieve the most relevant cases and cite their sources.

  • Find manufacturing examples using retrieval-augmented generation, and compare their implementation approaches.

  • Search for a company's AI deployments, retrieve the supporting case records, and separate reported outcomes from missing evidence.

Verify your connection

The included Node.js 20+ script uses built-in APIs and needs no package installation. By default it uses the anonymous preview. For full access it reads a personal key from a local text file or the AIUSECASEHUB_API_KEY environment variable. It never prints the key.

# Free discovery and all four tool definitions.
node examples/verify-connection.mjs

# Free search and abbreviated detail lookup; uses 2 preview attempts.
node examples/verify-connection.mjs --exercise

# Discovery and tool listing only; no tool-call credits are consumed.
node examples/verify-connection.mjs --key-file 'C:\private\aiusecasehub-key.txt'

# One search followed by one detail lookup: 3 credits on successful completion.
node examples/verify-connection.mjs --key-file 'C:\private\aiusecasehub-key.txt' --exercise

The script verifies all four tool names and stops on HTTP, protocol or tool errors. Its output describes the checks actually completed; it does not imply that a different client or gateway was tested.

Registry metadata

Glama also lists the hosted connector, with a Healthy status and all four tools verified on September 6, 2026.

The service is also listed on Smithery. Its optional configuration collects each user's personal AIUseCaseHub key; leave it unset for the preview. A public-preview search and detail lookup through Smithery's connection API were verified on September 6, 2026.

Smithery CLI 1.2.0 currently defaults to a gateway address that returned 404 during verification. If affected, use Smithery's documented API base for connections in the current PowerShell session:

$env:SMITHERY_CONNECT_BASE_URL = 'https://api.smithery.ai/connect'
smithery mcp add flo7up/aiusecasehub --id aiusecasehub
smithery tool list aiusecasehub

Smithery requires its own sign-in for gateway connections. Connecting directly to the hosted endpoint above requires no account for the preview.

The official MCP Registry name is io.github.flo7up/aiusecasehub, version 1.1.1. server.json declares an optional secret header without embedding a credential.

smithery-config.json declares the optional personal API-key header for Smithery's configuration UI. Free previews use no key; full-access users supply their own. Publication and working connections are verified separately.

Credits, data and support

The adapter code and documentation in this repository are MIT licensed. The hosted service, its private implementation and the case dataset are not part of this repository or that license; service access remains subject to the linked terms and preview/credit limits.

With a personal key, successful searches cost 2 credits and detail lookups cost 1. The public preview, discovery and listing do not deduct credits. The response's _mcp object describes preview limits or reports credits used and remaining. Account allowances and purchases are managed on the API page.

Methodology · Privacy · Terms · Report an integration issue

Available Tools

4 tools
get_usecase_detailsRead an AI deployment caseA
Read-only

Fetch detailed information for a single AI use case by RowKey/id.

ParametersJSON Schema
NameRequiredDescriptionDefault
idNoAlias for row_key.
row_keyYesThe RowKey/id returned by search tools.

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns 'detailed information' for a single record but does not describe the response structure, fields, or any constraints beyond identification.

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?

A single, focused sentence that states the purpose in a front-loaded manner. There is no filler, irrelevant repetition, or unnecessary detail.

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?

For a simple read-only fetch with one required parameter and clear annotations, the description is complete enough for an agent to select and invoke it correctly. The absence of an output schema is not a gap here, since the tool's purpose is self-explanatory.

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?

The input schema provides 100% coverage of both parameters, including an alias relationship between id and row_key. The description's mention of 'by RowKey/id' simply mirrors the schema and adds no deeper semantic or formatting guidance.

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 action ('Fetch detailed information'), the resource ('a single AI use case'), and the identifier needed ('by RowKey/id'). This distinguishes it from the search-related sibling tools, which are for discovering rather than reading a specific record.

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 makes it clear this tool is for retrieving a specific use case when a RowKey/id is already known, implicitly distinguishing it from the search siblings. However, it does not explicitly state when not to use it or name those alternatives.

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

hybrid_search_usecasesSearch AI deployments with filtersA
Read-only

Search AI use cases with hybrid full-text and vector ranking. Supports provider, industry, geography, technology, customer, partner, and boolean case-type filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
isRagNoFilter for retrieval-augmented generation deployments.
limitNoMaximum results requested. Public previews return at most 3; personal-key access permits up to 20.
queryYesNatural-language query.
countryNoFilter by country code, for example US or GB.
isVoiceNoFilter for voice AI deployments.
industryNoFilter by the deployment industry.
isAvatarNoFilter for AI avatar deployments.
isVisionNoFilter for computer vision deployments.
isCopilotNoFilter for copilot deployments.
isAgentCaseNoFilter for AI agent deployments.
isFineTuningNoFilter for model fine-tuning deployments.
partner_nameNoFilter by implementation partner.
customer_nameNoFilter by the company adopting AI.
cloud_providerNoMicrosoft, AWS, GCP, or comma-separated values.
isMultiAgentCaseNoFilter for multi-agent deployments.
isMicrosoftFabricNoFilter for Microsoft Fabric deployments.
technologies_usedNoFilter by technology name.
isSustainabilityCaseNoFilter for sustainability use cases.

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare the tool read-only and non-destructive. The description adds meaningful behavioral context by disclosing the hybrid ranking mechanism, which is not visible in the annotations or schema. It does not cover rate limits or result shape, but the read-only annotation lowers the burden for safety-related details.

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 tight sentences with no fluff: the first fronts the core action and ranking behavior, the second summarizes the available filter dimensions. Every phrase earns its place.

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?

The rich schema fully documents all 18 filter parameters, including the limit nuance about public previews. The absence of an output schema is acceptable because 'Search AI use cases' clearly implies a list of matching use cases. The main missing piece — explicit routing against sibling tools — is already accounted for in the usage-guidelines dimension.

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 the schema already documents every parameter. The description only summarizes filter categories at a high level and adds no syntax, format, or default information beyond the schema, keeping it at the baseline of 3.

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 states a specific action ('Search AI use cases') with a clear resource, and the phrase 'hybrid full-text and vector ranking' distinguishes it from the sibling tools. The title reinforces scope with 'with filters'.

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?

Usage guidance is implied by the phrase 'hybrid full-text and vector ranking' — this suggests it is the choice when both retrieval modes are wanted. However, the description never explicitly tells an agent when to choose this tool over search_usecases or vector_search_usecases, nor does it name alternatives.

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

search_usecasesSearch enterprise AI deploymentsA
Read-only

Search curated AI use cases using the default hybrid ranking. Use this when an agent has a natural-language search term.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results requested. Public previews return at most 3; personal-key access permits up to 20.
queryNoAlias for search_term.
search_termYesNatural-language search term.

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds that it uses default hybrid ranking and searches curated content. It does not disclose limits, rate constraints, or other behavioral details, but it does not contradict the 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?

The description is two sentences with no filler: the first states the action and method, the second gives the usage trigger. Every word contributes to agent decision-making.

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 a read-only search tool with fully documented parameters, this description covers core usage and ranking behavior adequately. It lacks explicit guidance for choosing this over the sibling hybrid_search_usecases, but that is not critical for correct invocation.

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?

The input schema covers 100% of parameters with descriptions, so the description does not need to explain parameters in depth. The phrase 'natural-language search term' aligns with search_term but adds no new semantic information 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 the action ('Search'), the resource ('curated AI use cases'), and the specific method ('default hybrid ranking'), which distinguishes it from the vector and hybrid sibling tools. It is specific and actionable.

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 explicitly says 'Use this when an agent has a natural-language search term,' providing a clear trigger for when to select this tool. It does not explicitly mention alternatives or exclusions, so it stops short of a full 5.

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

vector_search_usecasesFind semantically similar AI deploymentsA
Read-only

Semantic vector search for AI use cases using the meaning of the query text.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results requested. Public previews return at most 3; personal-key access permits up to 20.
queryYesNatural-language query.

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the tool read-only and non-destructive. The description adds useful behavioral context by clarifying that it performs vector-based semantic matching rather than keyword or hybrid search. No contradictions or hidden side effects are present.

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?

The description is a single, front-loaded sentence with no filler. The only minor inefficiency is that 'semantic' and 'using the meaning' overlap slightly, but the statement remains clear and compact.

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 a two-parameter, read-only search tool, the description plus schema provides enough information to invoke it correctly: a natural-language query and an optional limit. The title and description clarify that the result is a set of similar AI deployments, so no critical invocation detail 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?

The input schema fully documents both parameters—query and limit—so the description does not need to repeat them. It adds no additional parameter-level meaning, but with 100% schema coverage, the baseline score of 3 is appropriate.

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?

The description identifies a specific operation—semantic vector search—and a clear resource (AI use cases). It also indicates the matching is based on meaning, which helps distinguish it from keyword search, though it does not explicitly name the sibling tools.

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 phrase 'using the meaning of the query text' implies semantic-similarity use, but the description does not explicitly state when to prefer this tool over search_usecases or hybrid_search_usecases. Usage guidance is thus more implied than explicit.

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. 4 tool updatesv1.1.1
    • First observedget_usecase_details
    • First observedhybrid_search_usecases
    • First observedsearch_usecases
    • First observedvector_search_usecases
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

A3.9/5.0

Scored across 4 tools

Disambiguation2/5

search_usecases and hybrid_search_usecases are nearly the same operation—both perform hybrid full-text/vector ranking—and the only clear distinction is that the latter adds filters. An agent will struggle to know which to choose. vector_search_usecases and get_usecase_details are distinct, but the overlapping search tools create real ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: search_usecases, hybrid_search_usecases, vector_search_usecases, get_usecase_details. The prefixes and suffixes are predictable and readable.

Tool Count4/5

Four tools is a reasonable size for a focused use-case search and detail server. However, one of the four tools is largely redundant with another, so the count is slightly padded rather than perfectly minimal.

Completeness4/5

The server covers the core workflow of discovering AI use cases via search and then fetching full details. It lacks an explicit browse/list-all or filter-only endpoint, but the search tools likely handle most discovery needs, so the gaps are minor.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers