Mostly Right

Search datasets

search

Read-onlyIdempotent

Search every public dataset on Mostly Right and return up to 20 matches, most relevant first, as {results: [{id, title, url, snippet, matching_table, why}]}, where id is the dataset slug, url its canonical page, and snippet, matching_table and why say what matched. No account needed. Example: {"query": "hourly airport weather observations"}. Pass a result's id straight to fetch for the full dataset document. This is the plain search-and-fetch pair; search_datasets is the richer, paged version with topics, publishers and summaries.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses a hard result cap of 20, relevance ordering, the absence of auth requirements, and the full response shape including the meaning of each field. It does not discuss pagination or what happens on zero matches, but the additive behavioral value over the annotations is already substantial.

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?

Information-dense and front-loaded with the action, the result cap and the alternative, with no filler sentences. It is a long single paragraph and the inline JSON response notation is slightly run-on, but every clause carries usable signal, particularly since no output schema exists.

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 one-parameter, read-only search tool with no output schema, the description supplies what would otherwise be missing: the return shape, field meanings, result limit, and the follow-up call to fetch. Nothing an agent needs in order to invoke it correctly or chain it is absent.

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 single query parameter has 0% schema description coverage, so the description must carry the meaning. It does so with a worked example ({"query": "hourly airport weather observations"}) that communicates free-text natural-language queries, though it never restates the 1-200 character length bound or whether boolean/field syntax is supported.

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 every public dataset on Mostly Right") and quantifies the result cap ("up to 20 matches, most relevant first"). It explicitly distinguishes itself from the sibling search_datasets as the "plain search-and-fetch pair" versus the "richer, paged version," so an agent can distinguish the two without opening either 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 routing guidance: use this for plain search, use search_datasets when topics, publishers or summaries are needed, and pass the returned id straight to fetch. It also states a precondition ("No account needed"), which removes a common reason an agent would hesitate or look for an auth flow.

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

All Mostly Right 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?