searchBoxTier에서 현재 공개 모집 중인 실제 농구 매칭방을 검색한다. 사용자가 농구할 방·픽업 경기·팀 대 팀 상대·참가할 경기를 찾거나 지역, 날짜, 시간, 3대3·5대5 같은 조건으로 매칭방 추천을 요청할 때 사용한다. 반환된 실제 방 중 조건에 맞는 방만 추천한다. NBA 정보, 농구 규칙·훈련법 같은 일반 지식 질문이나 농구와 무관한 질문에는 사용하지 않는다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 사용자의 농구 매칭방 검색어와 지역·날짜·방식 조건. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive, so the description adds value by clarifying that only 'actual' currently recruiting rooms are returned and that filtering to matching conditions is applied. This goes beyond annotation basics and sets expectations about result relevance, though it stops short of describing pagination or return envelope.
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 and front-loaded: the first sentence states the core action, the second lists use cases, the third lists exclusions. Every sentence earns its place, with no redundancy or filler.
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 one-parameter search tool with no output schema, the description is nearly complete. It clarifies the domain (BoxTier, current open rooms), the filtering behavior, and the exclusions. The only minor gap is the absence of any indication of return format or empty-result behavior, but given the lack of an output schema and the simplicity of the tool, this is acceptable.
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%, with the 'query' parameter already described as a search term with region/date/format conditions. The description reinforces this by adding concrete examples like 3x3/5x5, but does not provide any new structural guidance (e.g., syntax, language, or how to combine conditions) beyond what the schema already conveys.
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 searches for actual basketball matching rooms currently open in BoxTier, using the specific verb '검색한다'. It distinguishes itself from siblings by explicitly listing what it is not for (NBA info, general rules/training, non-basketball queries), making the scope unmistakable.
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?
It provides explicit when-to-use scenarios: looking for rooms, pickup games, team opponents, or matches to join, plus recommendation by region/date/time/format. It also states when not to use it, covering NBA trivia, rule/training tips, and unrelated questions, which effectively routes the agent away from inappropriate invocations.
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 has a clearly distinct job: searching, fetching one match detail, checking account state, listing personal match records, and generating the receipt. Even though search and fetch are related, their boundary—list vs. detail-by-id—is explicit and unlikely to cause selection errors.
Three tools follow the verb_noun pattern (create_basketball_receipt, get_my_boxtier_account, list_my_match_records), but 'search' and especially the generic 'fetch' deviate by having no object or domain qualifier. The set is still readable, but it is not a consistent naming convention.
Five tools form a well-rim scope for the server's dual purpose of discovering/matching rooms and generating receipts from user or match data. There are no redundant or decorative tools, and each tool occupies a necessary step in the intended workflows.
The main flows are covered: login/limit check → list personal matches or search rooms → receipt creation. The only notable gap is the lack of a way to retrieve or manage previously generated receipts, but users can still be re-run receipt generation from existing match records, so workaround exists.