Mostly Right

Start a bounded source inspection

start_source_inspection

Read-onlyIdempotent

Prepares an HTTPS source, opens a bounded research session and queues a source_inspect probe. Supply rights_claim.claim_note with the actual rights evidence or operator assertion; the service hashes its trimmed UTF-8 bytes and returns rights_claim with the real digest. Alternatively supply an already computed claim_evidence_digest; never fabricate a hash. A digest records the claim, not legal verification. Returns session_id, probe_id, source_id, question_id, rights_claim and limits; it does not write a recipe. To ask the prepared source more (sample rows, profile columns, evaluate an aggregate), call probe_source with its dataset_id, question_id and source_id. If uncertain, preserve the coordinates and call get_source_inspection; this tool never retries preparation. For an archive (ZIP) address, pass archive_members: true: the inspection lists the archive's member names, so you can pick one and write an archive.zip recipe whose member is that exact name. A refusal RANGED_READ_UNSUPPORTED means the host cannot serve byte ranges — choose another mirror or ask the person for one; ARCHIVE_FORMAT_UNSUPPORTED means the file is not a ZIP; ARCHIVE_DIRECTORY_LIMIT means its directory is too large to list; ARCHIVE_MEMBERS_UNAVAILABLE means this deployment has not enabled archive member listing, and every other inspection works as before.

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": {
      "dataset_id": "<dataset_id>",
      "question": "<question>",
      "source": "<source>"
    },
    "name": "start_source_inspection"
  }
}

Input Schema

Name	Required	Description	Default
`source`	Yes
`question`	Yes
`dataset_id`	Yes
`archive_members`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026
- addedInput schema / properties / archive_members
```
Added value: +{
+  "type": "boolean"
+}
```
Changed1 schema field changedOct 23, 2026
- changedInput schema / properties / source / properties / url / format
```
Previous value: -"uri"New value: +"starts_with"
```
Changed2 schema fields changedOct 14, 2026
- addedInput schema / properties / source / properties / rights_claim / properties / claim_note
```
Added value: +{
+  "maxLength": 4000,
+  "minLength": 1,
+  "type": "string"
+}
```
- changedInput schema / properties / source / properties / rights_claim / required
```
Previous value: -[
-  "claimed_basis",
-  "claim_evidence_digest"
-]New value: +[
+  "claimed_basis"
+]
```
AddedSep 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses that the service hashes the trimmed UTF-8 bytes of claim_note and returns the real digest, that a digest is a claim record and not legal verification, that preparation is never retried, and what each refusal code (RANGED_READ_UNSUPPORTED, ARCHIVE_FORMAT_UNSUPPORTED, ARCHIVE_DIRECTORY_LIMIT, ARCHIVE_MEMBERS_UNAVAILABLE) implies for the agent's next move.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the key rights_claim instruction are front-loaded, which is good, but the remainder is a single dense run-on paragraph in which four refusal codes are enumerated. The error catalog is actionable yet disproportionately long relative to the core call, and could be compressed or moved to structure.

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?

No output schema exists, so the description compensates by naming the returned fields (session_id, probe_id, source_id, question_id, rights_claim, limits). Combined with nested-object guidance, fallback routing, and refusal-code handling, an agent has everything needed to call it correctly and recover from failures.

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?

With 0% schema description coverage, the description carries the burden and does so for the ambiguous nested field: it distinguishes supplying claim_note (server-computed digest) from claim_evidence_digest (pre-computed) and warns against fabricating a hash, plus explains archive_members' purpose. dataset_id and question are only referenced in passing and their formats/semantics are left to 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 first sentence states concrete verbs and objects: prepares an HTTPS source, opens a bounded session, queues a source_inspect probe. It also carves out what it does not do ("does not write a recipe"), which separates it from recipe-writing siblings without the agent needing to open 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?

Explicit routing is given for both alternatives: use probe_source to ask follow-up questions with dataset_id/question_id/source_id, and use get_source_inspection when uncertain because this tool never retries preparation. It also conditions archive_members: true on the address being a ZIP and lists which refusal code should trigger which fallback.

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?