Skip to main content
Glama

Search Company Wiki

search_company_wiki
Read-onlyIdempotent

Search this company's private memory wiki by keyword. Returns matching page slugs, titles and excerpts.

Input Schema

NameRequiredDescriptionDefault
queryYesSearch keyword
companyNoWhich company to read, by name or id, when the account has more than one (see list_companies). Leave it out to use the only company, or the default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description does not need to restate safety. It adds useful behavioral context by saying the wiki is private to the company and by describing the return shape as page slugs, titles, and excerpts. It does not mention result limits or pagination, but its added value is clear.

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?

Two sentences, front-loaded with the core action. The second sentence efficiently states the return shape with no wasted wording.

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?

For a simple read-only search tool with strong annotations and full schema coverage, the description is largely complete. Because there is no output schema, it helpfully names the returned fields. It omits pagination or result-limit behavior, which is a minor gap.

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?

Schema description coverage is 100%, so both the query and company parameters are already documented. The description reinforces keyword search and company scope but adds no syntax, matching behavior, or handling details beyond the schema. A baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: searching the company's private memory wiki by keyword. It also says what the search returns: matching page slugs, titles, and excerpts. It does not explicitly distinguish this from siblings such as search_wiki, read_wiki, or read_company_wiki, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The keyword-search framing implies this is for finding wiki pages rather than reading a known page. However, it gives no explicit when-to-use guidance, no exclusions, and does not name alternatives like read_company_wiki or search_wiki. In a large sibling set, this leaves routing partly to inference.

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.