Skip to main content
Glama

Search Fragments

Resolve Fragment

resolve_fragment
Read-only

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.

Input Schema

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault
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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema 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."
  2. First observed

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.

Try in Browser

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