naulon

Browse sources for a topic (free)

naulon_discover

Read-only

Browse a TOPIC: list candidate articles by title and teaser, with no verdict on whether any of them answers a question. Returns FREE public teasers only — slug, title, and summary — with no content and no payment. Call this first to see what is available before appraising or quoting. A candidate may carry WHY it matched: matchedInBody means your terms are inside the paid text but NOT in the title or teaser (strong — the teaser just does not show it), matchedSemantic means only that it is near your query in meaning and your terms are absent (weak: judge the teaser, and set aside one that is off-topic). NEITHER flag set means one of two opposite things, so read it against the rest of the response: if any OTHER candidate here carries a flag, this source searches, and no flag is the STRONGEST result of all — your terms matched the title or teaser, which is why no body-only or semantic explanation was needed. If NO candidate in the response carries a flag, the source does not search (a plain RSS feed), and the absence says nothing at all — judge every candidate on its teaser. Discovery returns the best available matches, never a promise that any of them answers your question.

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": {
      "topic": "<topic>"
    },
    "name": "naulon_discover"
  }
}

Input Schema

Name	Required	Description	Default
`topic`	Yes	The research topic to find candidate sources for.

Output Schema

Name	Required	Description
`note`	No	Present when refused — explains why, and where to go instead.
`refused`	No	True if the server refused to run discovery at all (e.g. a hosted ask-only mount) — see note. Never set alongside real candidates.
`candidates`	Yes	Free teasers; the agent has paid for nothing at this stage.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnly, openWorld and non-destructive, and the description usefully adds that only free public teasers are returned with no paid content. The bulk of the text is devoted to interpreting matchedInBody/matchedSemantic flags, which arguably belongs to output documentation rather than call-time behavior, and its dense conditional rule (what a missing flag means depending on other candidates) is hard to apply reliably.

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

Conciseness2/5

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

The purpose is front-loaded, but the definition runs long for a one-parameter read-only list tool, and the middle passage is a single sprawling sentence with nested conditionals and all-caps emphasis that is difficult to parse. That material would be far clearer as bullets or left to the output schema.

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?

Given one required parameter, a full output schema and rich annotations, the description covers everything needed to call it correctly and warns against over-reading results ('never a promise that any of them answers your question'). It is complete, though it spends disproportionate effort on result-interpretation prose rather than call guidance.

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 coverage is 100% for the single 'topic' parameter, so the schema already carries its meaning; the description adds no format or constraint detail beyond it. Baseline 3 applies when the schema does the heavy lifting.

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 ('Browse a TOPIC: list candidate articles') and describes the exact return shape ('slug, title, and summary'). It explicitly positions itself ahead of 'appraising or quoting', which maps to the naulon_appraise and naulon_quote siblings, so an agent can tell them apart without opening 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 a clear sequencing rule ('Call this first to see what is available before appraising or quoting'), which is genuine when-to-use guidance tied to named alternative actions. It lacks explicit when-not-to-use conditions, e.g. when to skip discovery and go straight to a targeted search.

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

All naulon 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.