case-studies

Search DataArt case studies

search_cases

Read-only

Search DataArt case studies by text query and/or tag IDs with pagination. The query can be keywords or a whole question: it is split into words, common words are ignored, whole words are matched in the title, description and tag names (British/American spelling and plurals are folded). Cases containing every word come first (allTermsTotal of them), then cases containing some of the words, best match first. Pass an empty query to browse all cases. Use get_case_tags to discover available tag IDs before filtering. Text and tags combine with AND. Multiple tags combine per tagMatch: "any" (default) or "all". Returns short records; use get_case with the id, slug or url of a result to get its full text.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No	Page number, 1-based. Default is 1.
`query`	Yes	Keywords or a question, e.g. "telemedicine" or "Have you built a trading platform?". Pass empty string to skip text filtering.
`tagIds`	No	Comma-separated tag IDs to filter by (e.g. "12,45"). Pass empty string to skip tag filtering.
`pageSize`	No	Items per page. Default is 20, maximum 50.
`tagMatch`	No	"any" (default) - case has at least one of the tags; "all" - case has every tag.	any

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / query / description

Previous value: -"Text to search in title and description. Pass empty string to skip text filtering."New value: +"Keywords or a question, e.g. \"telemedicine\" or \"Have you built a trading platform?\". Pass empty string to skip text filtering."

Changed1 schema field changedSep 24, 2026

addedInput schema / properties / tagMatch

Added value: +{
+  "default": "any",
+  "description": "\"any\" (default) - case has at least one of the tags; \"all\" - case has every tag.",
+  "type": "string"
+}

First observedSep 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover safety (readOnlyHint, openWorldHint), so the description carries the behavioral burden and does so richly: word splitting, stop-word removal, whole-word matching across title/description/tag names, British/American and plural folding, staged result ranking with allTermsTotal, AND combination of text+tags, and tagMatch semantics. It even states the return shape ('short records'), which is essential since there is no output schema.

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 overall tight, with no filler sentences. It is a dense single paragraph with several long clauses, so it is slightly harder to scan than an ideal definition, but nearly every clause conveys behavior an agent cannot get from the structured fields.

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 5-parameter search tool with no output schema, the description covers filtering, combination logic, ranking, pagination (via schema), and the return shape. It also links forward to the exact sibling needed to expand a result, leaving nothing an agent requires before calling it.

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 100%, so the baseline is 3 and the schema already documents page/pageSize/tagMatch defaults. The description adds real meaning beyond that: the ranking semantics of 'query', the empty-string browse behavior, that text and tags combine with AND, and how multiple tags interact via tagMatch.

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 DataArt case studies') plus the two filter dimensions (text query and/or tag IDs). It is immediately distinguishable from siblings get_case (fetch full text) and get_case_tags (discover tag IDs), which the description names explicitly.

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 concrete when-to-use routing: 'Use get_case_tags to discover available tag IDs before filtering' and 'use get_case with the id, slug or url of a result to get its full text.' It also gives a when-to-use-this-way case ('Pass an empty query to browse all cases'), so an agent needs no inference to pick the right tool.

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

All case-studies tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?