query_profileSearches the profile for a topic and returns the evidence behind it. The topic is a subject, a technology or a skill, for example "MCP", "C# performance", "cryptography" or "physics". The result gives the projects, skills and education that match, with the detail.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The subject, technology or skill to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns evidence and that the result includes projects, skills, and education, which is useful. However, it does not specify the structure of the result, potential pagination, error behavior (e.g., no matches), or that it is a read-only operation. This is acceptable for a simple query tool but not fully transparent.
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 concise, with the core action front-loaded in the first sentence. It avoids redundant phrasing and includes only essential clarifying details. The length is appropriate for a one-parameter search tool.
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 tool is straightforward, but there is no output schema, so the description should indicate the return format more concretely. It mentions projects, skills, and education but does not describe how they are structured (e.g., list of objects, excerpts) or whether the response is flat or nested. Given the low complexity, this is a moderate gap.
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?
Although schema coverage is 100%, the description adds meaningful examples ('MCP', 'C# performance', 'cryptography', 'physics') and clarifies that the topic should be a subject, technology, or skill. This goes beyond the schema's bare parameter description and helps the agent choose appropriate values.
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 the verb 'Searches' and the resource 'profile', and explains that it returns evidence for a given topic. It distinguishes itself from sibling tools like list_projects and list_skills by explicitly mentioning it returns matching projects, skills, and education, which sets it apart as a cross-category search rather than a simple list operation.
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?
Usage is implied by the description: if you have a specific topic to search, use this tool. However, there is no explicit mention of when not to use it or alternatives such as list_projects for a full list. The description gives examples of topics but does not state a decision rule against using sibling tools.
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.
Most tools are clearly distinct: list_projects, list_skills, and get_contact_info each target a specific resource. get_bio and get_profile_summary overlap somewhat as profile overviews, and query_profile can also surface the same projects/skills/education, but their intended purposes are described clearly enough to avoid serious misselection.
Tool names consistently use snake_case and follow a verb_noun pattern (get_*, list_*, query_*). The shift from get/list to query_profile is a minor convention deviation, but the pattern remains predictable.
Six tools is well-scoped for a personal profile server. Each tool covers a natural access point (bio, contact, summary, projects, skills, and search) without redundancy or bloat.
The profile surface covers the main expected areas: biography, contact, summary, projects, skills, and topic-based search. Education is only available through the aggregate summary rather than as a dedicated view, but this is a minor gap and query_profile can retrieve matching details.