Case-insensitive FAQ search. Exact question matches rank above substring hits, so "who is mark siazon" returns identity-who rather than a longer hiring question.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses case-insensitivity, exact-match ranking, and the substring fallback behavior with a concrete example. However, it does not describe no-result behavior, pagination/limit effects, or return shape, which are meaningful gaps for a search tool.
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?
A single sentence that leads with the tool's core function and immediately follows with the most decision-relevant behavioral nuance. The example is compact and instructive. No wasted words.
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, the description covers matching semantics well enough to invoke it, but the lack of any annotation, output schema, or explanation of the limit parameter leaves the agent with notable gaps around result count and return values.
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 description coverage is 0%, so the description must compensate for the two parameters. It gives an example for 'query' that implies the query should be a natural-language question, but it never mentions 'limit', its meaning, or its bounds. Half the parameters remain undocumented in both schema and 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?
States a specific verb and resource: 'FAQ search' with the additional qualifier 'Case-insensitive.' The example also clarifies what type of query produces what result. None of the sibling tools overlap with FAQ searching, so the purpose is unambiguous.
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 makes clear this is the tool for searching FAQ content, and none of the listed siblings are search tools. It does not explicitly state when not to use it, but the resource scope is obvious enough that an agent can select it correctly.
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 resource or retrieval purpose: availability, profile summary, single project, proof, project list, and FAQ search. Although get_profile_summary includes availability, its purpose as a consolidated summary is clearly separated from get_availability's focused availability/work-scope lookup.
All tool names follow a consistent snake_case verb_noun pattern (get_*, list_*, search_*). This makes the tool set predictable and easy to navigate.
Six tools is well scoped for a portfolio/profile server. Each tool covers a distinct read-only information need without unnecessary duplication or bloat.
The set covers the apparent domain comprehensively: profile entity, availability, project listing/detail, proof retrieval, and FAQ search. No obvious dead ends or missing operations for a public read-only profile service.