Skip to main content
Glama
Sign In

naulon

by app.naulon
OverviewDiscussionsAdmin

Appraise candidates for a topic

naulon_appraise
Read-only

Score how relevant each candidate is to the topic, from its free teaser alone — a 0..1 relevance plus a one-line rationale. Pass the candidates you got from naulon_discover (or a curated subset), and pass them back WHOLE — matchedInBody / matchedSemantic tell the scorer WHY the search returned each one, and dropping them makes a body-matched source with a terse teaser look identical to a near-miss with a keyword-ish one. FREE: it reads the teaser and those flags, never paid content, and it fetches and pays for nothing. Use it to decide what is worth quoting.

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>",
      "candidates": "<candidates>"
    },
    "name": "naulon_appraise"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicYesThe research topic to score relevance against.
candidatesYesCandidates to appraise — pass naulon_discover's rows through unmodified.

Output Schema

NameRequiredDescriptionDefault
appraisedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description goes further with the cost model — it reads only the teaser and the flags, fetches nothing, and pays for nothing — which is not derivable from annotations. It also discloses a non-obvious behavioral trait: dropping matchedInBody/matchedSemantic degrades scoring because the scorer uses those flags as evidence, explaining exactly what breaks and why.

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 verb and output shape before the caveats, with zero filler. The second sentence is long and stacks the WHOLE warning, the FREE guarantee, and the downstream use; it stays readable but could shed the capitalized emphasis without losing meaning.

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 two-parameter scoring tool with a full output schema, the description covers everything an agent needs: where the input comes from, why fields must be preserved, what content is touched, and what the score is for. Return-value details are correctly left to the output schema.

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; the description earns above that by explaining the significance of the two optional flags rather than restating them — they encode why a source was returned, and stripping them collapses a body-matched source into looking like a near-miss. It also clarifies that a curated subset is acceptable despite the pass-through instruction.

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?

Opens with a specific verb and resource ("Score how relevant each candidate is to the topic") and states both the output form (0..1 plus a one-line rationale) and the input basis (the free teaser alone). The closing "Use it to decide what is worth quoting" positions it relative to downstream siblings naulon_quote and naulon_discover, so an agent can place it in the pipeline without opening the schema.

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 clear context-of-use: source the candidates from naulon_discover or a curated subset, and use the scores to triage what is worth quoting. It does not explicitly say when to skip this in favor of a sibling (e.g. when you need full text rather than a teaser score), though the FREE/teaser-only framing implies that boundary indirectly.

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

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