search_questionsFind guidance on how to answer a security questionnaire question. Search by the question text, a control area, or a standard and control identifier such as CEK-03. Returns matching entries with the URL of the page each came from.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return. Defaults to 8. | |
| query | Yes | The questionnaire question, or words from it. Pasting the row from the spreadsheet works. |
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 independently discloses that the tool is a search operation and returns matching entries with the URL of each source page. It does not state matching behavior, ranking, or absence of side effects, but for a read-only search tool the core behavioral expectations are reasonably covered.
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?
Three sentences with no filler. The main purpose is front-loaded, search dimensions follow, and the return format is stated. Every sentence contributes necessary information.
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?
For a simple two-parameter search tool with no output schema and no annotations, the description covers the key invocation context: what to search by, what the results contain, and the source URL. Minor omissions like sorting or no-results behavior are not critical for selecting and invoking the tool correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that the query can be a question text, control area, or standard/control identifier, and gives a concrete CEK-03 example, which meaningfully enriches the query parameter semantics beyond the schema's description.
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 starts with a specific action ('Find guidance') tied to a well-defined resource ('security questionnaire question' / questionnaire corpus). It gives concrete search dimensions (question text, control area, standard/control identifier) and clearly differentiates from siblings like get_question by focusing on searching rather than fetching a single record.
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 clearly implies when to use this tool: when you need guidance on answering a security questionnaire question and have text, control area, or an identifier. It does not explicitly exclude alternatives or mention get_question when a specific ID is known, but the intended use context is clear enough.
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.
Each tool targets a distinct purpose: vendor posture, question detail, corpus statistics, standards list, and search. Even search_questions vs get_question are clearly separated by search vs complete lookup.
All tool names use a consistent verb_noun pattern with clear retrieval verbs: get_, list_, and search_. The names are lowercase snake_case and predictable.
Five tools is well-scoped for a focused questionnaire guidance corpus. Each tool covers a necessary access pattern without redundancy.
The tool surface covers searching, retrieving detailed guidance, listing standards, analyzing corpus statistics, and viewing the vendor's own posture. A direct browse-all-questions capability is not present but search covers discovery adequately.