Skip to main content
Glama

Search Fragments

by com.searchfragments
OverviewDiscussionsAdmin

Server Details

Search Fragments — two tools for the queries an agent can't place, both built to decline rather than guess. resolve_fragment takes a half-remembered, cross-source query ("a musician who became famous for stopping performing") and returns a grounded answer, ranked web sources to confirm by eye, or an explicit no-resolution. verify_claim takes a specific factual assertion and returns supported, partially_supported, insufficient_evidence, or unsupported, with cited evidence and a stated_limits field that is always present. There is no confidence score — insufficient_evidence fires freely, and unsupported requires a source that explicitly contradicts, never mere absence of confirmation. Every verdict is decide-by-eye: "supported" means current web sources confirm it, not that the claim is true. Calibrated against 18 known claims before release. Free, no signup. Streamable HTTP (MCP 2025-11-25). Read-only.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

TDQS

A4.9/5.0

Scored across 2 tools

Disambiguation5/5

resolve_fragment targets vague, half-remembered queries while verify_claim targets specific factual assertions. Their input shapes and outputs are clearly distinct, and the descriptions include explicit guidance on when not to use each tool.

Naming Consistency5/5

Both tools follow the same verb_noun snake_case pattern: resolve_fragment and verify_claim. The verbs are descriptive and match each tool's function perfectly.

Tool Count4/5

Two tools is slightly below the typical 3-15 range, but this is a specialized server with two complementary operations that fully define its purpose. Each tool earns its place, and there is no redundancy.

Completeness5/5

The domain is fragment resolution and claim verification, and the two tools cover exactly those core operations with no obvious dead ends. General web search is outside the stated purpose, so its absence is not a gap.

Available Tools

2 tools
resolve_fragmentResolve FragmentA
Read-only
Inspect

Call resolve_fragment when a user describes something they can only half-remember — a book, film, song, artwork, person, or event they know exists but can't name — instead of asking a direct question. If the input reads like a memory ("there's this thing where...", "...somebody who...", "...a story about...") rather than a lookup, this is the right tool.

Matches this shape:

  • a musician who became famous largely for stopping performing

  • somebody who photographed the same view every day until the changes became the artwork

  • a song everybody knew but nobody could identify

  • a novel where the footnotes slowly become the real story

Not this shape — answer directly or use normal search instead:

  • what is the capital of France

  • who directed Jaws

  • name of french artist cubist painting 1948

  • which company bought Instagram in 2012

  • any well-documented fact or common trivia — this tool adds a multi-second round trip with no accuracy benefit there, and is not reliably correct on well-known items either

Why call this instead of answering directly: on hard, under-documented fragment queries, LLMs asked to answer directly tend to invent things that don't exist rather than admit uncertainty. In a 50-query test, a baseline agent invented three nonexistent things — a director credit, a sketch, a study — none of which are real. Search Fragments returned none of those three invented things. Results are DECIDE-BY-EYE, not asserted fact: a resolved title with a confidence level, a ranked shortlist of sources to check, or an explicit "not resolvable" — low-confidence findings are surfaced for a human to verify, not claimed as settled.

ParametersJSON Schema
NameRequiredDescriptionDefault
fragmentYesThe half-remembered or fragment-shaped query, in the user's own words. Should be at least 5 words and describe the thing being recalled by premise, plot, relationship, or context.

Output Schema

ParametersJSON Schema
NameRequiredDescription
poolYesRanked web results. Always DECIDE-BY-EYE — human must confirm before any graph write.
outcomeYes'resolved' = strong candidate identified (semantic pass returned high confidence title). 'ranked_stalls' = web results returned but no confident semantic identification — pool for human review. 'no_resolution' = not an SF question, or pipeline produced an empty pool.
candidateYesTop candidate when outcome=resolved; null otherwise. DECIDE-BY-EYE — human must confirm.
reject_reasonYesWhy the fragment was rejected; non-null only when is_sf_question=false.
is_sf_questionYestrue if the fragment is a valid memory-recall query; false if it was rejected as a direct lookup or research prompt.

TDQS

A5/5.0
Behavior5/5

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

Even though annotations already declare readOnlyHint and openWorldHint, the description adds substantial behavioral context: results are 'DECIDE-BY-EYE, not asserted fact,' invented items are a documented risk, well-known queries gain no accuracy benefit, and low-confidence findings are explicitly surfaced for human verification. This goes well beyond the annotations.

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

Conciseness5/5

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

The description is long but every section earns its place: front-loaded purpose, clear positive/negative examples, rationale grounded in test evidence, and explicit output expectations. The structure makes the length navigable rather than wasteful.

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?

The tool is nuanced — deciding between fragment resolution and direct answer — and the description covers the decision boundary, input shape, failure modes, and output form. With an output schema also present, nothing essential is left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description significantly enriches the fragment parameter: it must be in the user's own words, at least 5 words, and describe by premise, plot, relationship, or context. This tells the agent how to populate the parameter for best results, not just what the field means.

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 description opens with a specific directive: call this tool for half-remembered fragments the user can't name, and explicitly contrasts it with direct answering and normal search. The 'Matches this shape' and 'Not this shape' examples make the purpose unmistakable even without sibling tools to compare against.

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?

It gives explicit when-to-use guidance ('when a user describes something they can only half-remember') and explicit when-not-to-use guidance ('answer directly or use normal search instead'), backed by concrete positive and negative examples. This leaves no ambiguity about selecting this tool over alternatives.

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

verify_claimVerify ClaimA
Read-only
Inspect

Call verify_claim when you have a specific factual assertion and want to know whether current web sources support it. Takes a claim as a natural-language statement; returns a verdict with cited evidence and stated limits.

Verdict set:

  • "supported" — multiple independent sources directly confirm the specific claimed detail

  • "partially_supported" — sources confirm the entity and domain; specific detail is pointed to but not directly stated

  • "insufficient_evidence" — sources don't address the specific claim; fires freely, including when the entity is well-known but the specific detail is undocumented

  • "unsupported" — a credible source explicitly contradicts the claim

All verdicts are DECIDE-BY-EYE. A "supported" verdict means current web sources confirm it — not that it is true. Evidence may be incomplete, biased, or outdated. The stated_limits field is always present and identifies what the evidence cannot confirm.

Good input shape (specific, checkable assertions):

  • "Werner Herzog dragged a full-size steamship over a hill during the filming of Fitzcarraldo"

  • "Glenn Gould stopped giving live concerts in 1964"

  • "The Backrooms photograph originated on 4chan"

Not this shape — these need resolve_fragment instead:

  • "there's a documentary about a filmmaker dragging a boat over a mountain"

  • "a musician famous for stopping performing"

ParametersJSON Schema
NameRequiredDescriptionDefault
claimYesA specific factual assertion to check against current web sources. Should be a concrete, checkable statement — not a question or a half-remembered fragment.

Output Schema

ParametersJSON Schema
NameRequiredDescription
verdictYes'supported' = multiple independent sources directly confirm the specific claimed detail. 'partially_supported' = sources confirm entity + domain; detail pointed to but not directly stated. 'unsupported' = a credible source explicitly contradicts the claim. 'insufficient_evidence' = pool doesn't address the specific claim; fires freely.
evidenceYesWeb sources retrieved. Always DECIDE-BY-EYE — human must verify before acting.
stated_limitsYesWhat the evidence cannot confirm, even when verdict is supported. Always present.

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses the full verdict set with meanings, states that verdicts are decidable by eye, warns that evidence may be incomplete/biased/outdated, and notes the stated_limits field is always present. This gives agents a much richer behavioral model than annotations alone.

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

Conciseness5/5

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

The description is front-loaded with the purpose, then systematically walks through verdict semantics, caveats, and input shape with examples. Every section contributes actionable information and the negative examples prevent misuse; no redundant sentences exist.

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?

The description covers what the tool does, when to use it, what verdicts mean, and what limitations exist. Since an output schema is present, the description need not explain return values, and the annotations already carry the safety profile. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description substantially adds meaning by defining the expected input shape with positive examples, negative examples, and an explicit contrast to resolve_fragment-style fragments. It clarifies that the claim must be a concrete checkable statement, not a question or half-remembered fragment, going well beyond the schema's parameter description.

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 description states a specific verb ('Call verify_claim') and resource ('current web sources') with a clear scope: checking a specific factual assertion. It distinguishes itself from the sibling resolve_fragment by defining exactly which kind of input it accepts, so an agent can tell them apart 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit when-to-use guidance ('when you have a specific factual assertion'), a clear when-not-to-use rule with named alternative ('Not this shape — these need resolve_fragment instead'), and concrete examples of both good and bad inputs. No inference is required.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Addedverify_claim
  2. 1 tool update
    • Changedresolve_fragment2 fields changed
      • changedOutput schema / properties / candidate / oneOf
        Previous value: -[
-  {
-    "type": "null"
-  },
-  {
-    "properties": {
-      "confidence": {
-        "description": "Semantic pass confidence level.",
-        "enum": [
-          "high",
-          "medium"
-        ],
-        "type": "string"
-      },
-      "creator": {
-        "description": "Director, author, artist, or other attribution; null if not applicable.",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "title": {
-        "description": "The identified title, entity name, or answer.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "title",
-      "creator",
-      "confidence"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "type": "null"
+  },
+  {
+    "properties": {
+      "confidence": {
+        "description": "Semantic pass confidence level. Only high-confidence identifications are resolved; medium degrades to ranked_stalls.",
+        "enum": [
+          "high"
+        ],
+        "type": "string"
+      },
+      "creator": {
+        "description": "Director, author, artist, or other attribution; null if not applicable.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "title": {
+        "description": "The identified title, entity name, or answer.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "title",
+      "creator",
+      "confidence"
+    ],
+    "type": "object"
+  }
+]
      • changedOutput schema / properties / outcome / description
        Previous value: -"'resolved' = strong candidate identified (semantic pass returned high/medium confidence title). 'ranked_stalls' = web results returned but no confident semantic identification — pool for human review. 'no_resolution' = not an SF question, or pipeline produced an empty pool."New value: +"'resolved' = strong candidate identified (semantic pass returned high confidence title). 'ranked_stalls' = web results returned but no confident semantic identification — pool for human review. 'no_resolution' = not an SF question, or pipeline produced an empty pool."
  3. 1 tool update
    • First observedresolve_fragment

Related MCP Connectors

Related MCP Servers

  • LastSearch-AI

    LastSearch-HQ
    A
    license
    A
    quality
    A
    maintenance
    Evidence-backed web research for AI agents. Real-time search with cited claims, confidence scores, and compare mode showing raw LLM hallucination vs evidence-backed answers.
    5
    20
    Apache 2.0

  • grounder-mcp

    rozetyp
    A
    license
    A
    quality
    B
    maintenance
    Gives local and cloud LLMs live web grounding as four MCP tools: web_search, fetch, deep_search (a token-capped, cited evidence pack sized to a small context window), and research (an agentic search-and-read loop). Flat monthly pricing, no query content stored.
    2
    4
    MIT
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources