Skip to main content
Glama

Search Fragments

by com.searchfragments

Server Details

For queries a model can't confidently place: resolves or declines. Built to decline, not guess.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

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. Dates show when Glama detected each change.

  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

Frequently Asked Questions

Discussions

No comments yet. Be the first to start the discussion!

Login with GitHub to comment

Related MCP Connectors

Related MCP Servers

  • reflect-mcp

    jeffma8888
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables extraction of structured data from messy text with multi-model verification and human-in-the-loop review, surfacing only high-confidence results or flagging uncertain fields for confirmation.
    MIT

  • Router-MCP

    gungunj
    F
    license
    C
    quality
    D
    maintenance
    Routes natural language queries to appropriate MCP tools and planners with high-precision semantic matching and safety guardrails. Supports multi-intent detection, task planning, and strict role-based filtering to prevent misexecution or unauthorized access.
    7
    -

  • grounded-support-agent

    Ankit512
    A
    license
    Not graded
    quality
    A
    maintenance
    An MCP server that acts as a governed customer-support tool, resolving questions only when the knowledge base supports a cited, grounded answer and honestly escalating everything else with provenance and evidence.
    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.

TDQS

A4.9/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The tool's description explicitly delineates when to use it versus normal search, eliminating ambiguity about its purpose.

Naming Consistency5/5

The single tool name 'resolve_fragment' follows a clear verb_noun pattern, which is consistent with common MCP naming conventions. Even with one tool, the name is descriptive and predictable.

Tool Count4/5

A single tool for a highly specialized purpose—resolving half-remembered fragments—is reasonable and well-scoped. It is on the low end of tool counts, but the narrow domain justifies exactly one operation.

Completeness5/5

The tool fully covers its intended workflow: it returns resolved titles with confidence levels, ranked sources, or an explicit 'not resolvable' status. There are no obvious missing operations within the server's stated domain.

Resources