Skip to main content
Glama

search_openapi

Search across all 5G service-based interface API definitions to find data types or endpoints by name, even without knowing the source document.

Instructions

Full-text search across the OpenAPI definitions of the 5G service-based interface APIs (TS 29.xxx series), using SQLite FTS5 syntax.

Use this when you need an API detail but do not know which API document holds it — searching for a data type (NFProfile, SmContextCreateData) or an endpoint (/nf-instances, subscriptions) finds it without guessing an api_name first. When you already know the document, get_openapi reads it directly.

This is a separate index from the search tool: search covers specification clause text and never returns OpenAPI content, and this tool covers OpenAPI content only.

Results:

  • One hit is one definition, not one document: either a schema (a data type from components.schemas) or an operation (one HTTP method of one path, named like "PUT /nf-instances/{nfInstanceID}").

  • A query that is a single bare term ranks a definition of exactly that name first, so searching NFProfile returns the NFProfile schema itself ahead of the schemas that merely reference it.

  • Each hit reports spec_id, api_name, kind, name and a snippet. Pass those to get_openapi (with its schema or path parameter) to read the full definition.

  • A schema's text carries one level of $ref expansion, so referenced field names are searchable, but a type two hops away is not. Follow it up with get_openapi.

  • Set include_body to get the matched definition's full text inline. It is much larger than a snippet.

Query syntax:

  • AND/OR/NOT: NFProfile AND heartbeat

  • Phrase: "nf instances"

  • Prefix: subscri*

  • Column filter: name:NFProfile or body:nfInstanceId or api_name:Nnrf_NFManagement

  • Hyphenated, dotted or underscored terms (e.g. nf-instances, 29.510, Nnrf_NFManagement) are auto-quoted to avoid FTS5 syntax errors.

Tokenization:

  • Unlike search, this index applies no stemming: identifiers are matched as written, and inflected English forms do not fold together.

  • '-', '.' and '_' split tokens, so Nnrf_NFManagement is indexed as "nnrf" and "nfmanagement" and /nf-instances as "nf" and "instances" — a partial name matches, but camelCase is not split (supportedFeatures is one token).

Pagination:

  • Results come as {results, total_count, limit, offset}; total_count is the full match count.

  • Use limit (default 10, max 200) and offset to page through matches beyond the first page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoLimit the search to one kind of definition: "schema" for data types or "operation" for endpoints. Both are searched when omitted.
limitNoMaximum number of results per page (default: 10, max: 200)
queryYesrequired,FTS5 query string. Hyphenated or dotted terms like nf-instances and 29.510 are auto-quoted. Use AND/OR/NOT operators and double-quoted phrases for exact matches.
offsetNoNumber of results to skip for pagination (default: 0). Combine with total_count in the response to page through all matches.
api_nameNoLimit the search to a single API document (e.g. Nnrf_NFManagement). Use list_openapi to see the available names.
spec_idsNoLimit the search to one or more specifications (e.g. ["TS 29.510", "TS 29.518"]).
include_bodyNoReturn the full text of each matching definition instead of a snippet (default: false). Costs many more tokens; prefer the default and follow up with get_openapi.
Behavior5/5

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

With no annotations provided, the description carries full burden. It comprehensively discloses behavior: result granularity (one definition per hit), ranking (exact name matches first), $ref expansion depth, include_body effect, query syntax (including auto-quoting for special characters), tokenization rules (no stemming, split on hyphens/dots/underscores, no camelCase split), and pagination details. No contradictory or missing behavioral traits.

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 well-structured with sections (Results, Query syntax, Tokenization, Pagination) and front-loaded with the main purpose. While it is long, every sentence provides necessary information given the tool's complexity. It could be slightly more concise, but it earns its length.

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?

Given the complexity (7 parameters, no output schema, multiple sibling tools), the description is complete. It explains the result structure, how to follow up with get_openapi, the difference from search, tokenization idiosyncrasies, and pagination. It addresses all likely agent questions.

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 description coverage is 100%, but the description adds substantial value beyond the schema. It explains the query syntax in detail (operators, phrases, column filters, auto-quoting), the purpose and cost of include_body, how pagination uses limit/offset with total_count, and the meaning of kind (schema vs operation). The description makes the parameters much more usable.

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?

Clearly states the tool performs full-text search on OpenAPI definitions of 5G APIs, using SQLite FTS5 syntax. It distinguishes from sibling tools by explicitly contrasting with 'search' (covers clause text, not OpenAPI) and 'get_openapi' (for when the document is already known).

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?

Provides explicit guidance: 'Use this when you need an API detail but do not know which API document holds it.' It also gives a clear alternative: 'When you already know the document, get_openapi reads it directly.' Additionally, it contrasts with the sibling 'search' tool, specifying that search covers different content.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/higebu/3gpp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server