Ask runboth.dev in plain language: what RunBoth does, how to install it, and its limits.
Scored across 3 tools
Each tool has a clearly distinct purpose: ask queries the knowledge base, list_sites enumerates supported sites, and trust_lookup retrieves agent trust records. There is no overlap or ambiguity in their intended use.
Tool names are all lowercase snake_case, but their patterns differ: 'ask' is a bare verb, 'list_sites' is verb_noun, while 'trust_lookup' is reversed or compound. The set is readable but lacks a uniform verb-object convention.
With only 3 tools, the set is tightly focused and each clearly earns its place for the server's informational and trust-assessment purpose. The count is well within the 3-15 range for a well-scoped server.
For the stated domain (querying runboth.dev help, listing supported sites, and checking trust records), the surface is complete. An agent can discover the site, ask questions, and evaluate endpoint trust without dead ends.
Ask runboth.dev a question in plain language and get the answer from its own pages, with sources. RunBoth is a zero-dependency Python tool that finds out what a refactor actually changed by running the old and the new code on generated inputs and comparing seven behaviour channels, rather than reading the diff. Covers: detecting behavioural change from a Python refactor; differential execution and the seven channels it compares; installing RunBoth and running it as a commit hook or GitHub Action; what a CHANGED, NO CHANGE or ABSTAINED verdict means; how RunBoth was red-teamed and where its limits are. For example: How do I find out what my Python refactor actually changed in behaviour? Answers come back as ranked pages from runboth.dev with a URL, a score and a one-line reason each.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Optional list of sites to search. If not provided, searches all configured sites | |
| query | Yes | The question, in plain language. For example: How do I find out what my Python refactor actually changed in behaviour? | |
| generate_mode | No | The type of response to generate | list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that answers come as ranked pages from runboth.dev with a URL, a score, and a one-line reason, and that results are drawn only from RunBoth's own pages. This gives a clear picture of the tool's read/search behavior and output shape, though it does not discuss rate limits or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal, but every part earns its place: it front-loads the core purpose, then gives a useful topic list, an example, and the return format. The structure is a single block of text, but it is readable and not redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main use case well and explains the list-mode return format, but there is no output schema and the generate/summarize modes are not described. Since the tool has a param with three modes, an agent might not understand how the output differs across those modes. Sibling routing is also not addressed, though the context is otherwise fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a concrete example query and clarifies the plain-language nature of the query parameter, but it does not explain the generate_mode enum values or the exact interaction between site and query beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lets users ask runboth.dev a plain-language question and receive answers from its pages with sources. It is specific about the resource and action, and the coverage list makes it distinct from the sibling tools list_sites and who.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: asking natural-language questions about RunBoth's documentation and behavior. It enumerates the exact topics covered, which effectively tells an agent what kinds of queries belong here. It does not explicitly state when not to use it or name alternatives, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the sites this endpoint answers for (runboth.dev).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only listing operation but does not explicitly state safety, idempotence, or potential side effects. The phrase 'endpoint answers for' is vague and does not clarify the return format or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, but slightly under-specified; however, for a trivial listing tool, this is acceptable. It could be more informative without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is minimal and leaves key details ambiguous, such as what 'sites' refers to, what the output format is, and what 'this endpoint' means. An agent may not know how to interpret the results or when this tool is the right choice. The description is not complete enough for a non-trivial call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100%. According to the rubric, the baseline for 0 params is 4, and the description does not need to add parameter details. It appropriately says nothing about parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (the sites this endpoint answers for), with a specific domain (runboth.dev). It is not a tautology and is distinguishable from siblings like ask or who, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or related tools, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up what AI agents recorded after calling a website or an MCP endpoint: which capability they used, whether it worked, how long it took, and what they learned. Read-only, no key. Use it before you trust an endpoint you have never called, including this one.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | How many records to return, 1 to 25 | |
| target | Yes | A domain or endpoint URL, for example runboth.dev or https://host/mcp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It explicitly states 'Read-only, no key,' which is crucial safety information for an agent, and describes the content of the records. It does not disclose potential failure modes or rate limits, but for a read-only lookup with no authentication, this is a strong transparency disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and returned data are front-loaded, and the operational guidance ('Read-only, no key') is placed immediately after. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only lookup with no output schema, the description provides enough context to call it correctly: what it queries, what it returns, how to use it, and that it requires no key. The absence of an output schema is compensated by naming the record fields in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (target and top_k), including an example for target and a valid range for top_k. The description does not add parameter-specific semantics beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Look up') and resource ('what AI agents recorded after calling a website or an MCP endpoint'), and enumerates the returned dimensions: capability used, success, duration, and lessons learned. It clearly establishes the tool's role among siblings by framing it as a trust/verification lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: 'Use it before you trust an endpoint you have never called.' It also includes a memorable self-referential hint ('including this one'). However, it does not name alternative sibling tools or conditions for choosing one over the other, so the guidance is context-rich but not exclusion-based.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
whotrust_lookupask1 field changedInput schema / properties / query / descriptionPrevious value: -"The question or search query"New value: +"The question, in plain language. For example: How do I find out what my Python refactor actually changed in behaviour?"asklist_siteswhoAsk any GitHub repository a question. Get source-backed answers.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Scores whether AI assistants can read, understand and quote a public website. No account.
Ask your customer portal and CRM anything, in plain English
Add one secure layer between your agents and this server.
