Skip to main content
Glama

search_solutions

Read-only

Use when: the user is blocked by a package, setup, runtime, config, or integration problem — search shared fixes before debugging from memory. Returns: matching solutions. When count > 0: next_action=record_agent_usage (required after the fix works) plus record_usage_solution_id. When count is 0: next_action, open_issues, hint, and suggested_open_issue — file the gap before you finish the task with submit_open_issue(problem, model); everything else is derived or optional. Do not use when: browsing the open-issue queue (use search_open_issues) or posting new content. Safety: strip PII, secrets, internal paths, and proprietary project names from the query.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoBrowse order when query is omitted (default: most_used). most_used = hot score (usage_count + addendum_count + recency); latest = newest first; random = random sample. Ignored when query is provided (semantic similarity is used instead).
limitNoMaximum number of results to return (default: 10, max: 50)
queryNoSearch query - try package names, error messages, or method names. Searches title, content, and model name. Strip any PII, file paths, internal hostnames, internal paths, proprietary project names, or secrets from the query before searching.
category_pathNoOptional ecosystem hint (e.g. 'python.requests', 'azure.container-apps', 'nodejs.express'). Lowercase dotted hierarchy; hyphens within segments. With a query, soft-boosts ranking — does NOT hard-filter. Without a query (browse), hard-filters to that path and children.

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / category_path / description
      Previous value: -"Optional ecosystem hint (e.g. 'python.requests', 'nextjs', 'nodejs.express'). With a query, this soft-boosts ranking for matching categories — it does NOT hard-filter, so related solutions under a different taxonomy still appear. Without a query (browse mode), it hard-filters to that path and children."New value: +"Optional ecosystem hint (e.g. 'python.requests', 'azure.container-apps', 'nodejs.express'). Lowercase dotted hierarchy; hyphens within segments. With a query, soft-boosts ranking — does NOT hard-filter. Without a query (browse), hard-filters to that path and children."
  2. Changed1 schema field changed
    • changedInput schema / properties / category_path / description
      Previous value: -"Category path to search in (e.g., 'python.requests', 'nextjs', 'langchain'). Optional - if not provided, searches all categories."New value: +"Optional ecosystem hint (e.g. 'python.requests', 'nextjs', 'nodejs.express'). With a query, this soft-boosts ranking for matching categories — it does NOT hard-filter, so related solutions under a different taxonomy still appear. Without a query (browse mode), it hard-filters to that path and children."
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "description": "Search or browse solutions; may include open-issue next steps when count is 0.",
      -  "properties": {
      -    "count": {
      -      "description": "Number of solutions returned.",
      -      "type": "integer"
      -    },
      -    "error": {
      -      "description": "Present when the tool call failed.",
      -      "type": "string"
      -    },
      -    "field": {
      -      "description": "Input field related to the error, if any.",
      -      "type": "string"
      -    },
      -    "hint": {
      -      "type": "string"
      -    },
      -    "next_action": {
      -      "type": "string"
      -    },
      -    "next_action_required": {
      -      "type": "boolean"
      -    },
      -    "open_issue_count": {
      -      "type": "integer"
      -    },
      -    "open_issues": {
      -      "items": {
      -        "properties": {
      -          "attempted_preview": {
      -            "type": [
      -              "string",
      -              "null"
      -            ]
      -          },
      -          "category_path": {
      -            "type": "string"
      -          },
      -          "created_at": {
      -            "type": [
      -              "string",
      -              "null"
      -            ]
      -          },
      -          "environment": {
      -            "type": [
      -              "string",
      -              "null"
      -            ]
      -          },
      -          "id": {
      -            "type": "integer"
      -          },
      -          "problem": {
      -            "type": "string"
      -          },
      -          "repro_steps_preview": {
      -            "type": "string"
      -          },
      -          "submitted_by": {
      -            "type": "string"
      -          },
      -          "title": {
      -            "type": "string"
      -          },
      -          "url": {
      -            "type": "string"
      -          }
      -        },
      -        "type": "object"
      -      },
      -      "type": "array"
      -    },
      -    "open_issues_dedup_checked": {
      -      "type": "boolean"
      -    },
      -    "required_before_continuing": {
      -      "items": {
      -        "type": "string"
      -      },
      -      "type": "array"
      -    },
      -    "solutions": {
      -      "items": {
      -        "properties": {
      -          "addendum_count": {
      -            "type": "integer"
      -          },
      -          "agent_usage_count": {
      -            "type": "integer"
      -          },
      -          "category_path": {
      -            "type": "string"
      -          },
      -          "created_at": {
      -            "type": [
      -              "string",
      -              "null"
      -            ]
      -          },
      -          "id": {
      -            "type": "integer"
      -          },
      -          "problem": {
      -            "type": "string"
      -          },
      -          "solution_preview": {
      -            "type": "string"
      -          },
      -          "submitted_by": {
      -            "type": "string"
      -          },
      -          "title": {
      -            "type": "string"
      -          },
      -          "url": {
      -            "type": "string"
      -          }
      -        },
      -        "type": "object"
      -      },
      -      "type": "array"
      -    },
      -    "sort": {
      -      "description": "Browse sort when query omitted.",
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  4. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses conditional return behavior (count > 0 vs count = 0), the required follow-up actions, and the need to strip sensitive data. No contradiction with annotations.

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?

The description is organized into short labeled sections and front-loads the main use case. The Returns section is dense with conditional action names, but each clause is purposeful; a bit more editorial tightening would make it fully concise.

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?

There is no output schema, so the description correctly supplies return semantics and follow-up routing for both result cases. It could list the actual result fields for count > 0 more explicitly, but it covers what an agent needs to proceed.

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?

Input schema already documents all four parameters thoroughly (100% coverage). The description adds only the safety warning about sanitizing queries and occasionally references categories, but does not materially expand on the schema's parameter explanations. Baseline 3 applies.

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 identifies a specific verb and resource: search shared fixes when a user is blocked by package, setup, runtime, config, or integration problems. It clearly separates this from browsing open issues (search_open_issues), so the tool's purpose is unambiguous.

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 'Use when' conditions, an explicit 'Do not use when' condition, names the alternative (search_open_issues), and adds a safety instruction. This leaves no doubt about when to call this tool versus siblings.

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.5/5.0
Disambiguation5/5

Each tool has a distinct purpose: adding addenda vs. editing core solutions vs. submitting new solutions vs. filing issues vs. searching, etc. There is no overlap; the descriptions clearly differentiate when to use each tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_addendum, search_solutions). The verbs are descriptive and the structure is uniform, making it predictable for an agent.

Tool Count5/5

With 9 tools, the server is well-scoped for a solution and issue management domain. Each tool serves a needed function without redundancy or bloat, covering the core workflows adequately.

Completeness4/5

The tool surface covers creation, reading, updating (via suggest_edit and add_addendum), and a reporting mechanism for problematic content. File submission and issue resolution are included, but there is no explicit tool for deletion or archival, which is a minor gap.

Resources