Skip to main content
Glama

Search the concepts

search_concepts
Read-onlyIdempotent

Searches concepts by their words and by meaning, across every tree or some. By words: every word must match a word in the concept's title, description, tags, ID, or body, or the start of one (pol finds policy; fund doesn't find refund); case doesn't matter. By meaning: concepts that mean what the query asks, in other words or in another language, so describe what you need in a phrase or a question ("how we recognize revenue") rather than a single word, which matches by meaning poorly. Filter by types, tags, statuses, or trust tiers: a concept passes a filter with any of its values, and must pass every filter given. An empty query lists every concept that passes the filters.

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": {
      "query": "<query>"
    },
    "name": "search_concepts"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagsNoOnly concepts with any of these tags (case-insensitive).
limitNoDefault 10.
queryYesWhat you're looking for, in a phrase or a question (or just words); may be empty when filtering.
treesNoThe trees' slugs, as list_trees gives them (not their names). Only these trees; omit for every tree.
typesNoOnly concepts of any of these types (case-insensitive).
statusesNoOnly concepts with any of these statuses.
trustTiersNoOnly concepts with any of these trust tiers.

Output Schema

NameRequiredDescriptionDefault
urlYesThis search in OKForest, with every match.
totalYesHow many concepts match, before `limit`.
resultsYesThe best matches, best first.
unindexedTreesYesThe slugs of trees not indexed yet, which aren't searched: try again in a moment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / results / items / properties / snippet / description
      Previous value: -"A line of its body with a word the query matches, when one has."New value: +"A line of its body with a word the query matches, when one has; for a concept found by meaning alone, its body's first line."
  2. Changed4 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Words; may be empty when filtering."New value: +"What you're looking for, in a phrase or a question (or just words); may be empty when filtering."
    • addedOutput schema / properties / results / items / properties / matchedBy
      Added value: +{
      +  "additionalProperties": {},
      +  "description": "How it matched: a concept found by meaning alone uses other words.",
      +  "properties": {
      +    "meaning": {
      +      "description": "It means what the query asks, in whatever words.",
      +      "type": "boolean"
      +    },
      +    "words": {
      +      "description": "It has the query's words.",
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "words",
      +    "meaning"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / properties / results / items / properties / score / description
      Previous value: -"How well it matches: words in the title count most, then the tags and description, the ID, and the body."New value: +"How well it matches, higher first: by its words (in the title most, then the tags and description, the ID, and the body) and by meaning, mixed."
    • changedOutput schema / properties / results / items / required
      Previous value: -[
      -  "id",
      -  "tree",
      -  "path",
      -  "url",
      -  "tags",
      -  "status",
      -  "stale",
      -  "trustTier",
      -  "score"
      -]New value: +[
      +  "id",
      +  "tree",
      +  "path",
      +  "url",
      +  "tags",
      +  "status",
      +  "stale",
      +  "trustTier",
      +  "score",
      +  "matchedBy"
      +]
  3. Changed6 schema fields changed
    • changedInput schema / properties / query / description
      Previous value: -"Keywords; may be empty when filtering."New value: +"Words; may be empty when filtering."
    • changedOutput schema / properties / results / items / properties / score / description
      Previous value: -"How well it matches: title matches count most, then tags and description."New value: +"How well it matches: words in the title count most, then the tags and description, the ID, and the body."
    • changedOutput schema / properties / results / items / properties / snippet / description
      Previous value: -"A line of its body containing a search term, when one does."New value: +"A line of its body with a word the query matches, when one has."
    • addedOutput schema / properties / unindexedTrees
      Added value: +{
      +  "description": "The slugs of trees not indexed yet, which aren't searched: try again in a moment.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • removedOutput schema / properties / unreadTrees
      Removed value: -{
      -  "description": "The slugs of trees that couldn't be read, so their concepts are missing.",
      -  "items": {
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
    • changedOutput schema / required
      Previous value: -[
      -  "total",
      -  "url",
      -  "results",
      -  "unreadTrees"
      -]New value: +[
      +  "total",
      +  "url",
      +  "results",
      +  "unindexedTrees"
      +]
  4. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral detail beyond that: prefix matching rules (`pol` finds `policy`, `fund` doesn't find `refund`), case-insensitivity, filter combination semantics (any value within a filter, every filter across), and the empty-query listing behavior.

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?

Front-loaded with verb and resource, then organized into clearly delineated clauses ("By words:", "By meaning:", "Filter by"). Dense but every sentence carries operative information; nothing is redundant filler.

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?

Output schema exists, so return values need no explanation; all seven parameters are documented in the schema at 100% coverage and annotations cover the safety profile. The description supplies the remaining behavioral nuance an agent needs to call it correctly.

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 3 is the baseline, and the description earns a bump by explaining the `query` matching rules and how filters combine in ways the schema descriptions do not. `trees` and `limit` semantics remain schema-only, keeping it from a 5.

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?

States a specific verb and resource ("Searches concepts") plus the scope ("across every tree or some") and the two retrieval modes, which clearly separates it from get_concept and list_trees. An agent can identify the tool 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 concrete guidance on how to phrase a query for each mode, including the explicit warning that a single word "matches by meaning poorly" and the note that an empty query lists everything passing the filters. It lacks explicit routing to sibling tools (e.g., get_concept for a known ID), so it stops short of full when/when-not coverage.

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.

Resources