F
licenseNot graded
qualityD
maintenanceEnables searching for AI agents by keywords or categories, allowing users to discover tools like coding agents, GUI agents, or industry-specific assistants across marketplaces.
51
-
trustcase-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@trustcase-mcpFind a Trustcase use case for invoice follow ups with a trust score over 80."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Trustcase MCP server
A small, read-only MCP server that lets AI tools like Cursor and Claude search the Trustcase directory of practical AI agent use cases. Every result links back to https://trustcase.dev.
Published on npm as trustcase-mcp. Install with npx -y trustcase-mcp.
Tools
Tool | What it does |
| Search by words, with optional |
| Full entry by |
Both tools are marked read-only. The server never writes anything anywhere.
Related MCP server: Agent Index MCP Server
Data source
It reads the public feed at https://trustcase.dev/api/use-cases.json (cached for 1 hour). Point it somewhere else with TRUSTCASE_FEED_URL, which also accepts a local file path. test/feed.json is a snapshot built from the Trustcase repo (97 use cases).
Build and test
npm install
npm run build
npm test # end to end over stdio and streamable HTTP against test/feed.jsonUse it in Cursor
Add to ~/.cursor/mcp.json (or .cursor/mcp.json in a project):
{
"mcpServers": {
"trustcase": {
"command": "node",
"args": ["/absolute/path/to/trustcase-mcp/dist/index.js"]
}
}
}Once it is on npm this becomes "command": "npx", "args": ["-y", "trustcase-mcp"].
Use it in Claude Desktop
Edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"trustcase": {
"command": "node",
"args": ["/absolute/path/to/trustcase-mcp/dist/index.js"],
"env": { "TRUSTCASE_FEED_URL": "https://trustcase.dev/api/use-cases.json" }
}
}
}Restart Claude Desktop, then ask something like "Find a Trustcase use case for invoice follow ups with a trust score over 80."
Remote (streamable HTTP)
PORT=8787 node dist/index.js # or: node dist/index.js --httpThe endpoint is http://localhost:8787/mcp (stateless, POST). A hosted copy could live at something like https://mcp.trustcase.dev/mcp later.
Claude Code
claude mcp add trustcase -- node /absolute/path/to/trustcase-mcp/dist/index.jsAvailable Tools
2 toolsget_use_caseGet one Trustcase use caseARead-only
Get the full Trustcase entry for one AI agent use case by slug (from search_use_cases). Use it to answer whether a task is safe to hand to an agent, what could go wrong, what needs human approval, and how to set it up. Returns: the 0 to 100 trust score with its breakdown (access, human approval, undo and logs, scope, each with a reason), what the agent does on its own, what waits for a human yes, suggested tools, models and apps it works in, a copyable setup prompt, and the trustcase.dev link. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Use case slug from search_use_cases, for example 'lead-research-brief' |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint and openWorldHint, so the trailing 'Read-only' adds little. The real added value is the detailed disclosure of what the payload contains — trust score with per-dimension reasoning, autonomy vs. human-approval split, suggested tools, setup prompt, and external link.
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 purpose, then usage, then a structured 'Returns:' enumeration. The returns list is long but each item is a distinct content category an agent would otherwise have to discover by calling; only the redundant 'Read-only' clause is wasted.
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?
There is no output schema, so the description must describe the response — and it does so thoroughly, covering score breakdown, autonomy/approval split, recommendations, and prompt. Nothing material is missing for a single-parameter read tool.
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 already documents the slug with an example, so the schema carries the load. The description only adds the provenance hint that slugs originate from search_use_cases, which is marginal 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?
Specific verb and resource: 'Get the full Trustcase entry for one AI agent use case by slug'. It also distinguishes itself from the only sibling by noting the slug comes from search_use_cases, so an agent can route between retrieval and search without inspecting schemas.
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 concrete framing for when to reach for it: answering whether a task is safe to delegate, what could go wrong, what needs human approval, and setup. The alternative (search_use_cases) is referenced as the slug source but no explicit 'use X instead when...' exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_use_casesSearch Trustcase use casesARead-only
Search Trustcase, a directory of 97 practical AI agent use cases, each rated with a 0 to 100 trust score. Use this whenever the user asks about AI agent safety, trust or risk for a task, for example 'is it safe to let an agent change my live eBay prices', 'should I let AI reply to customers', 'what can go wrong if an agent does X', 'how do I set up an agent to do Y safely', what an agent should need approval for, or which tools or models to use for an agent task. Pass a few plain words for the task as query (for example 'ebay prices' or 'customer replies'). Returns, for each match: slug, title, category, summary, trust score and a trustcase.dev link. Then call get_use_case with the best slug for what the agent does alone, what waits for human approval and a setup prompt. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 10 | |
| query | No | Words to match, for example 'invoice follow up' or 'ebay' | |
| category | No | Sales, Support, Operations, Ecommerce and resale, Marketing, Engineering, Personal | |
| min_trust_score | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description reinforces read-only while adding context annotations cannot carry: corpus size, the meaning of the 0-100 trust score, and the exact fields returned (slug, title, category, summary, trust score, link). The trailing 'Read-only' sentence is redundant with the annotation, which keeps it just short of a 5.
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-loads what the tool is and how big the corpus is, then usage triggers, then the follow-up step. The long enumerated example list is the only padding, though each example does sharpen the trigger condition.
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 and does so by listing returned fields and pointing to the follow-up tool. It omits pagination behavior and the default limit of 10 that is only visible in the schema, a minor gap for a four-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the schema documents most parameters, but the description adds real guidance the schema lacks: pass a few plain words rather than a full question, with concrete query examples ('ebay prices', 'customer replies'). It says nothing extra about category, min_trust_score or limit beyond what the schema already provides.
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?
Names a specific verb and resource (search Trustcase use cases) and immediately characterizes the corpus: 97 use cases each with a 0-100 trust score. It also distinguishes itself from the sibling by stating that get_use_case is the follow-up call, so an agent can choose between them without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger conditions with four quoted example user questions, then states the exact next step: call get_use_case with the best slug. When-to-use and the alternative are both spelled out rather than implied.
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.
2 tool updates
v0.1.1- First observed
get_use_case - First observed
search_use_cases
TDQS
A4.4/5.0
Scored across 2 tools
Disambiguation5/5
The two tools form a clear search-then-detail workflow: search_use_cases returns candidate slugs, and get_use_case retrieves the full entry for one slug. Their descriptions explicitly state this sequence, so an agent should not confuse them.
Naming Consistency5/5
Both names follow the same snake_case verb_noun pattern: search_use_cases and get_use_case. The resource noun is consistent, making the pair predictable.
Tool Count4/5
Two tools is minimal but appropriate for a read-only directory lookup service with a search/detail split. It is slightly thin compared to richer API surfaces, but no tool appears redundant.
Completeness4/5
The surface covers the core workflow: find a use case by task description and retrieve its full trust assessment, approval boundaries, setup prompt, and link. Minor gaps exist, such as browsing by category or fetching an entry by slug without first searching, but these are workable.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Search a curated directory of agent tools, MCP servers, APIs, protocols and skills. No auth.
Read-only search of 2,189 AI agent tools (MCP servers, x402 APIs) with daily automated trust scores.
Read-only catalog of 1,500+ real, sourced AI agent use cases with tools, cost and setup prompts.
Find AI agent skills: public previews and source links. Read-only discovery; no account required.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceEnables users to search and discover over 500 AI agent endpoints and x402 APIs directly from MCP-compatible clients like Claude and Cursor. It provides tools to query endpoints by keyword, category, or capability while offering access to detailed provider statistics.-
- AlicenseAqualityAmaintenanceSearch and discover AI agents, skills, prompts, bundles and MCP connectors from the Spark catalog. Seven tools: search assets, get asset details and raw content, list popular assets and categories, check API key usage, and report the outcome of applying fetched content. No API key needed.510 npm4MIT
- AlicenseNot gradedqualityCmaintenanceEnables searching and retrieving details of 41,000+ agent skills, MCP servers, Claude Code plugins, and agentic loops from any MCP-capable agent.MIT