get_docs_searchEmbeds the query with Ollama (nomic-embed-text) and returns the closest public doc chunks
from the environment's search index (pgvector).
Source: GET /api/v1/docs/search No Authorization header is required. Prefer connection.workspaceName and connection.appId as stable config instead of generating identity fields dynamically.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | ||
| body | No | ||
| query | Yes | ||
| params | No | ||
| connection | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does well by explaining the embedding mechanism, the vector index, the public nature of the docs, and that no auth header is needed. The GET source also implies read-only behavior, though output format and failure cases are not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the essential search behavior, and every sentence contributes useful information. It includes endpoint, auth, and configuration guidance without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and important auth/configuration context, but with no output schema it does not describe the result shape or fields. It also does not mention default limit behavior beyond the schema's max cap, so an agent may still be uncertain about the exact response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful semantics for connection.workspaceName and connection.appId by recommending them as stable configuration. The q and limit parameters are primarily covered by the input schema, and the description does not add much about how limit or q should be formed beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool embeds a query with Ollama and returns the closest public doc chunks from a pgvector-backed search index. The resource and behavior are specific, and it is readily distinguishable from the unrelated auth/session sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it is for semantic documentation search, works over a documented GET endpoint, and requires no Authorization header. It does not explicitly name alternatives or exclusions, but no sibling tool provides comparable doc-search functionality, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools cover nearly identical actions with subtle differences: post_sessions, post_sessions_get_or_create, and post_sessions_renew_session_token all create/reuse sessions; get_auth_logout and post_auth_logout both log out; and the two revoke endpoints overlap heavily. An agent would struggle to pick the correct variant without reading detailed descriptions.
Naming mixes HTTP-verb prefixes (get_, post_, delete_) with domain-specific verbs (auth_session_callback, secureflows_build_login_url), and get_sessions_get_key is redundant and awkward. The pattern is inconsistent across the set even though individual chunks are readable.
18 tools is on the heavy side for what is essentially session lifecycle management plus a few helper utilities. Many tools could be consolidated (e.g., one logout tool, one revoke tool, one key-access pattern), making the surface feel fragmented.
The session lifecycle is well covered: create, renew, revoke, logout, get payload, set/delete keys, identity, and self-service listing are all present. Minor gaps include no direct TTL adjustment after creation and no admin-level session management, but the core workflows are complete.