Skip to main content
Glama
AIwithhassan

Scoped Support Tools Server

by AIwithhassan
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

Secure AI Application

This project demonstrates two versions of an AI customer support application that uses MCP tools with a LangChain agent:

  • unsecure-ai-agent: an MCP server with no authentication or per-tool authorization.

  • secure-ai-agent: an MCP server protected with Descope-issued JWTs and explicit scope checks on sensitive tools.

The app is intentionally small and uses an in-memory mock support database so the difference between insecure and secure tool access is easy to see.

What This Project Shows

The support agent can use MCP tools to answer customer support questions, look up customer data, look up orders, get product information, and process refunds.

The unsecure version exposes tools directly. Any client that can reach the MCP endpoint can call the tools exposed by the server.

The secure version protects the MCP endpoint with Descope JWT authentication. Tools require scopes, and the refund tool requires the additional refunds:create scope.

Related MCP server: Broker

Project Structure

.
├── pyproject.toml
├── uv.lock
├── unsecure-ai-agent/
│   ├── api/index.py
│   ├── customer_support_agent.py
│   ├── mcp_server.py
│   └── tools.py
└── secure-ai-agent/
    ├── api/index.py
    ├── customer_support_secure.py
    ├── secure_mcp_server.py
    └── tools.py

Main Components

MCP Servers

unsecure-ai-agent/mcp_server.py creates a FastMCP server named Support Tools Server and exposes these tools:

  • answer_user_query

  • process_refund

  • get_order_id

  • lookup_customer_info

  • list_customers

  • get_product_info

secure-ai-agent/secure_mcp_server.py creates a FastMCP server named Scoped Support Tools Server and protects it with Descope JWT verification. It exposes these scoped tools:

  • answer_user_query: requires support:tools

  • process_refund: requires support:tools and refunds:create

  • get_order_id: requires support:tools

  • lookup_customer_info: requires support:tools

  • get_product_info: requires support:tools

The secure version intentionally does not expose list_customers, which limits broad customer data access.

Agent Clients

unsecure-ai-agent/customer_support_agent.py connects to an MCP server using MCP_SERVER_URL, loads the available tools, and runs a LangChain/Groq support agent.

secure-ai-agent/customer_support_secure.py gets or uses a Descope access token, connects to the secure MCP server with an Authorization: Bearer <token> header, loads the scoped tools, and runs a LangChain/Groq support agent.

Mock Data

Both tools.py files use in-memory dictionaries for customers, orders, refunds, and products. Data resets when the server process restarts.

Requirements

  • Python 3.11 or newer

  • uv for dependency installation and running scripts

  • A Groq API key for the LangChain chat model

  • A Descope project and MCP application/server configuration for the secure version

  • Vercel account for deployment

Use this Descope setup link for this project:

https://descope.plug.dev/RPSqEGs

Install Dependencies

From the repository root:

uv sync

This installs the dependencies from pyproject.toml and uv.lock.

Local Environment Variables

Create a local .env file in the repository root for local runs.

Do not commit real secrets. If secrets have already been committed, rotate them in the provider dashboard.

Shared Local Variables

GROQ_API_KEY=your_groq_api_key
MCP_SERVER_URL=http://localhost:8000/mcp

GROQ_API_KEY is used by ChatGroq.

MCP_SERVER_URL is used by the unsecure client to connect to the MCP server. For a deployed server, set this to the Vercel /mcp URL.

Secure Local Variables

The secure MCP server requires these values:

DESCOPE_PROJECT_ID=your_descope_project_id
DESCOPE_MCP_SERVER_ID=your_descope_mcp_server_or_audience_id

Optional secure server overrides:

DESCOPE_BASE_URL=https://api.descope.com
DESCOPE_JWKS_URI=https://api.descope.com/<DESCOPE_PROJECT_ID>/.well-known/jwks.json
DESCOPE_ISSUER=https://api.descope.com/<DESCOPE_PROJECT_ID>

The secure client can also use:

DESCOPE_ACCESS_TOKEN=existing_access_token_for_testing
DESCOPE_TOKEN_ENDPOINT=https://your-token-endpoint

DESCOPE_ACCESS_TOKEN skips the client credentials request and uses the provided token directly.

DESCOPE_TOKEN_ENDPOINT overrides discovery from the OpenID configuration URL.

Run Locally

Run The Unsecure MCP Server

uv run python unsecure-ai-agent/mcp_server.py

The server exposes the MCP app at /mcp.

Run The Unsecure Agent Client

In another terminal, set MCP_SERVER_URL to the running MCP endpoint, then run:

uv run python unsecure-ai-agent/customer_support_agent.py

Run The Secure MCP Server

Set the required Descope variables first:

export DESCOPE_PROJECT_ID=your_descope_project_id
export DESCOPE_MCP_SERVER_ID=your_descope_mcp_server_or_audience_id
uv run python secure-ai-agent/secure_mcp_server.py

The server exposes the protected MCP app at /mcp.

Run The Secure Agent Client

Make sure the secure client has a valid Descope token flow or a DESCOPE_ACCESS_TOKEN, then run:

uv run python secure-ai-agent/customer_support_secure.py

Deploy To Vercel

The Vercel entrypoint for each server is the api/index.py file in that server directory:

  • unsecure-ai-agent/api/index.py imports app from mcp_server.py.

  • secure-ai-agent/api/index.py imports app from secure_mcp_server.py.

Deploy the secure and unsecure servers as separate Vercel projects so each deployment has its own root directory and environment variables.

Recommended setup:

  • Project 1 root directory: unsecure-ai-agent

  • Project 2 root directory: secure-ai-agent

  • Production endpoint path for both: /mcp

If Vercel does not automatically install dependencies from the root pyproject.toml, add a requirements.txt or configure the Vercel install command for the selected project.

Vercel Environment Variables

Set environment variables in Vercel from:

Vercel Project -> Settings -> Environment Variables

Add variables to the correct environments, usually Production, Preview, and Development if you use all three.

Required For The Secure Vercel MCP Server

These variables must be set on the Vercel project that deploys secure-ai-agent:

Variable

Required

Example

Description

DESCOPE_PROJECT_ID

Yes

Pxxxxxxxxxxxxxxxxxxxxxxxxxxx

Descope project ID used to build the default issuer and JWKS URL.

DESCOPE_MCP_SERVER_ID

Yes

RSxxxxxxxxxxxxxxxxxxxxxxxxxx

Expected JWT audience for this MCP server. This must match the audience/resource configured in Descope.

DESCOPE_BASE_URL

No

https://api.descope.com

Base Descope API URL. Defaults to https://api.descope.com.

DESCOPE_JWKS_URI

No

https://api.descope.com/<project-id>/.well-known/jwks.json

JWKS URL used to verify token signatures. Defaults from DESCOPE_BASE_URL and DESCOPE_PROJECT_ID.

DESCOPE_ISSUER

No

https://api.descope.com/<project-id>

Expected JWT issuer. Defaults from DESCOPE_BASE_URL and DESCOPE_PROJECT_ID.

The secure Vercel server will fail at startup if DESCOPE_PROJECT_ID or DESCOPE_MCP_SERVER_ID is missing.

Required For The Unsecure Vercel MCP Server

The unsecure MCP server does not currently require any environment variables on Vercel.

Variable

Required

Description

None

No

The server uses only the mock in-memory data from tools.py.

Variables For Running Agent Clients Against Vercel

These are needed wherever you run the client scripts. They are not required by the MCP server itself unless you also deploy the client logic.

Variable

Used By

Required

Description

GROQ_API_KEY

Both clients

Yes

API key used by ChatGroq.

MCP_SERVER_URL

Unsecure client

Yes

Full MCP endpoint, for example https://your-unsecure-project.vercel.app/mcp.

DESCOPE_ACCESS_TOKEN

Secure client

No

Existing bearer token. Useful for testing without requesting a new token.

DESCOPE_TOKEN_ENDPOINT

Secure client

No

Overrides token endpoint discovery.

The secure client also needs Descope client credentials and the well-known configuration URL. These values are loaded from environment variables and should be set locally in .env or in the environment where the client runs.

Recommended production secure-client variables:

DESCOPE_WELL_KNOWN_URL=https://api.descope.com/v1/apps/agentic/<project-id>/<server-id>/.well-known/openid-configuration
DESCOPE_REQUIRED_SCOPES=support:tools refunds:create
DESCOPE_TOKEN_RESOURCE=https://your-secure-project.vercel.app/mcp
DESCOPE_CLIENT_ID=your_descope_client_id
DESCOPE_CLIENT_SECRET=your_descope_client_secret

Descope Scope Configuration

Use this Descope setup link for the project configuration:

https://descope.plug.dev/RPSqEGs

The secure MCP server expects JWTs that satisfy these checks:

  • Token signature validates against the configured JWKS URI.

  • Token issuer matches DESCOPE_ISSUER.

  • Token audience matches DESCOPE_MCP_SERVER_ID.

  • Token includes support:tools for normal support tools.

  • Token includes both support:tools and refunds:create for process_refund.

When creating the Descope application or machine-to-machine client, make sure the issued token includes the scopes required for the tools you want the agent to call.

Security Notes

  • Never commit real API keys, client secrets, access tokens, or passwords.

  • Store production secrets in Vercel Environment Variables.

  • Rotate any secret that was accidentally committed or shared.

  • Use the secure MCP server for sensitive operations such as refunds.

  • Keep high-risk tools behind narrow scopes like refunds:create.

  • Avoid exposing broad tools such as list_customers unless the caller is explicitly authorized.

Troubleshooting

Missing required environment variable: DESCOPE_PROJECT_ID

Set DESCOPE_PROJECT_ID in Vercel or in your local shell before starting secure-ai-agent/secure_mcp_server.py.

Missing required environment variable: DESCOPE_MCP_SERVER_ID

Set DESCOPE_MCP_SERVER_ID in Vercel or in your local shell. This value must match the expected JWT audience.

401 Unauthorized Or Tool Calls Fail On The Secure Server

Check that the token was issued by the configured Descope issuer, uses the correct audience, and includes the required scopes.

Refund Tool Is Not Available

The access token probably does not include refunds:create. Add that scope in Descope and request it when getting the token.

Groq Authentication Fails

Set GROQ_API_KEY in the environment where the client script runs.

Useful Commands

uv sync
uv run python unsecure-ai-agent/mcp_server.py
uv run python unsecure-ai-agent/customer_support_agent.py
uv run python secure-ai-agent/secure_mcp_server.py
uv run python secure-ai-agent/customer_support_secure.py

Available Tools

6 tools
answer_user_queryB

Return a canned answer to a user's question.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries full burden for disclosing behavior. It only says 'canned answer' but doesn't state whether the answer varies, what happens for unknown queries, or whether it performs any side effects. This is minimal.

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 a single sentence with no fluff, perfectly sized for a simple tool. Every word earns its place and it is immediately clear.

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?

For a tool with one parameter and an output schema, the description is adequate in length but lacks usage context and behavioral details. It is minimal but not dangerously incomplete, given the simple schema.

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 description implies 'query' is the user's question, but does not elaborate on format, length, or examples. Since schema description coverage is 0%, the description should compensate, but it only provides a loose association between the parameter and its meaning.

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 uses a specific verb 'Return' and resource 'canned answer', clearly indicating this tool provides a static response to a user's query. However, it does not differentiate from sibling tools that also handle queries in specific domains, so it's not fully distinguished.

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?

No guidance is provided on when to use this tool versus the sibling tools (e.g., process_refund, get_product_info). The description only states what it does, not under what circumstances or when to prefer alternatives.

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

get_order_idA

Look up the order ID for a given customer ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
customer_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden. 'Look up' clearly indicates a read-only operation, but it does not disclose behaviors such as handling multiple orders, error cases for invalid/missing customer IDs, or whether it returns the most recent order. No contradiction with annotations since none are provided.

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 a single, front-loaded sentence that states the verb and resource immediately. It is concise with zero unnecessary words or repetition.

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 tool is simple with one parameter, and an output schema exists to handle return value details. The description adequately conveys the core purpose and input. Minor gaps include lack of guidance on edge cases and alternatives, but these do not severely impede usability for a straightforward lookup.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must add meaning. It merely restates the parameter by saying 'given customer ID' without explaining its format, constraints, or possible values. The schema already provides type and required status, so the description adds no extra semantic value.

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 uses a specific verb 'look up' and resource 'order ID' with an input 'customer ID', clearly distinguishing it from sibling tools like lookup_customer_info or list_customers. The purpose is unambiguous and directly tied to the tool name.

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 usage (when you need an order ID for a customer ID) but does not explicitly state when to use this tool over alternatives or provide exclusions for edge cases like multiple orders. No sibling tool mention is present, so guidance is only implicit.

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

get_product_infoA

Return product info (name, price) for a product ID or name (e.g. 'macbook', 'iPhone').

ParametersJSON Schema
NameRequiredDescriptionDefault
productYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 must convey behavioral traits. It states the tool returns product info and accepts an ID or name, but doesn't disclose behavior for invalid or non-existent products, error handling, or any side effects. This is adequate for a simple read-only tool but lacks depth.

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 a single concise sentence that front-loads the action and resource, then provides input details and examples. Every word contributes value, with no redundancy or filler.

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 simple one-parameter tool with an output schema, the description covers the core purpose and input semantics. It doesn't explain what happens when no product is found or if multiple matches exist, but these are minor gaps given the tool's simplicity and existing output schema.

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?

The schema provides only a parameter name 'product' with no description. The description compensates fully by explaining it accepts a product ID or name and giving examples ('macbook', 'iPhone'). This adds critical meaning beyond the structured 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 tool's purpose: 'Return product info (name, price) for a product ID or name'. It uses a specific verb ('Return') and identifies the resource ('product info'), distinguishing it from sibling tools like get_order_id or lookup_customer_info which operate on different entities.

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 provides clear context on when to use the tool: when product information is needed, specifying the input format (product ID or name). It doesn't explicitly mention when not to use it or name alternatives, but the implied usage is straightforward for a simple query tool.

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

list_customersA

Return a list of all customers.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It implies a read-only operation via 'Return a list,' but does not disclose details like pagination, ordering, or authorization requirements. This is a minimal but acceptable level for a simple list tool.

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 a single sentence with no unnecessary words, directly stating the purpose.

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?

Given the tool's simplicity (zero parameters) and the presence of an output schema, the description covers the core behavior. However, the lack of usage context prevents a perfect score.

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 input schema has zero parameters, so the description cannot add parameter-level details. Per the rubric, 0 params earns a baseline of 4.

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 'Return a list of all customers' uses a specific verb and resource, clearly indicating a list operation. It does not explicitly contrast with sibling tools like lookup_customer_info, so it misses the differentiation criterion.

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?

No guidance is provided about when to use this tool versus alternatives such as lookup_customer_info for individual customer details. The description simply states what it does without usage context.

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

lookup_customer_infoB

Return customer info for a given customer ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
customer_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It only states the basic action and does not disclose what happens for non-existent customer IDs, error behavior, or any side effects. The behavioral transparency is minimal.

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 concise sentence that is front-loaded with the action and resource, containing no redundant or irrelevant information.

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 tool has an output schema, so return values need not be described. However, the description omits any guidance on error handling or non-existent IDs. For a simple lookup tool, it is minimally complete but lacks edge-case context.

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

Parameters2/5

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

Schema description coverage is 0% and the description only says 'given a customer ID', which merely reiterates the schema's parameter name. No format, constraints, or examples are added, so the description fails to compensate for the low coverage.

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 states 'Return customer info for a given customer ID' with a specific verb 'return' and resource 'customer info'. It clearly distinguishes from siblings like list_customers (which likely lists all customers) by focusing on a single customer ID.

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 use when a specific customer ID is known, but provides no explicit guidance on when to use this tool vs alternatives such as list_customers or answer_user_query. It is clear but not explicitly differentiated.

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

process_refundB

Process a refund for a given order ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
order_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning irreversibility, financial impact, required authorization, or any side effects—a significant gap for a mutating tool.

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 one short, clear sentence with no redundancy. It is appropriately front-loaded and easy to parse.

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?

For a simple tool with one parameter and an output schema, the description covers the basics but omits important behavioral context such as refund processing results, reversibility, or error states. The mutation nature warrants more detail.

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 0%, but the description identifies 'order ID' as the parameter, adding meaning to the order_id field. No format or validation details are given, but with a single parameter this is minimally adequate.

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 verb 'process' and the resource 'refund', with the order ID as the target. It is distinct from sibling tools that handle queries, lookups, and customer information.

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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions. The sibling list does not clarify usage, leaving the context implied at best.

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. 6 tool updatesv0.1.0
    • First observedanswer_user_query
    • First observedget_order_id
    • First observedget_product_info
    • First observedlist_customers
    • First observedlookup_customer_info
    • First observedprocess_refund
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation4/5

Each tool targets a distinct resource/action: customer lookup, listing, order ID retrieval, refund processing, product info, and a generic answer fallback. The only potential overlap is answer_user_query, but its purpose as a canned-response fallback is clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., process_refund, get_order_id, list_customers). No mixed conventions or unclear verbs.

Tool Count5/5

With 6 tools, the server is well-scoped for a support-focused toolkit. The number is reasonable and each tool has a clear role without unnecessary redundancy.

Completeness4/5

Core support workflows are covered: customer lookup, product info, order ID retrieval, refund processing, and generic canned answers. Minor gaps exist (e.g., no order detail retrieval beyond ID), but these can be worked around with the existing tools.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • enterprise-auth-mcp-server

    AiAgentKarl
    A
    license
    A
    quality
    D
    maintenance
    MCP server for enterprise authentication and authorization — JWT validation, OIDC token inspection, OAuth 2.0 introspection, and role-based access control for AI agents.
    8
    MIT

  • Broker

    Abhishekvoid
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to securely perform privileged actions like creating GitHub issues by minting short-lived, single-purpose tokens on demand, with policy enforcement and audit logging.
    MIT

  • MCP Customer Support Example

    odelvalle
    F
    license
    A
    quality
    C
    maintenance
    Simulates a multi-tenant customer support backend with tools for profile, order, ticket, and refund management, demonstrating security controls like tenant isolation, role-based access, and input validation.
    6
    -

  • SecureAgentServer

    bhargavlukka
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables secure support-ticket and customer-account operations with signed JWT authentication, prompt-injection and tool-poisoning guardrails, and human-in-the-loop confirmation for destructive actions.
    MIT