Newcomer guides for Georgian speakers in the US: short summaries and links to kartvelians.com.
Scored across 3 tools
The three tools map cleanly onto distinct retrieval operations: list (enumerate all guides), search (query by topic), and get (fetch one guide by slug). The descriptions explicitly cross-reference each other, making the intended workflow (search/list then get) unambiguous.
All three names follow a strict verb_noun pattern (get_/list_/search_ + guides) in consistent snake_case. The repeated '_for_georgians_in_us' suffix is verbose and adds noise, but it is applied uniformly, so there is no confusion about which tool does what.
Three tools is minimal but genuinely sufficient for a read-only content/guide server; nothing feels redundant or padded. It sits at the lower edge of the comfortable range, with no extra tool earning its place beyond the core retrieve operations.
List, search, and get-by-slug cover the full read lifecycle for a guide corpus, and search even surfaces planned 'coming soon' topics so users are not left at a dead end. There is no browse-by-category or related-guides operation, and no write surface, but for a static guide site that is a minor gap.
Get the summary, key facts, risk level and link for one kartvelians.com guide by slug (from search_guides_for_georgians_in_us or list_guides_for_georgians_in_us).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: "en" or "ka" (Georgian). Defaults to the query language. | |
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the shape of the response (summary, key facts, risk level, link), which matters because no output schema exists.
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 front-loads the action and resource, then packs the return contents and the slug's provenance without a wasted word. Nothing is padded or restated from the title.
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 two-parameter read tool with no output schema, the description covers the action, the identifier source, and the return fields, which is nearly everything an agent needs. It stops short of mentioning behavior on an unknown slug, but no critical information is missing.
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 only 50%: 'lang' is documented in the schema, but 'slug' carries no schema description. The description compensates by stating that the slug is a guide identifier obtained from the two sibling tools, giving the agent a concrete source and format expectation for the required parameter.
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?
Specific verb ('Get'), specific resource ('one kartvelians.com guide'), specific lookup key ('by slug'), and it enumerates the returned fields (summary, key facts, risk level, link). This distinguishes it cleanly from the two sibling tools, which are list/search rather than single-item retrieval.
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 parenthetical '(from search_guides_for_georgians_in_us or list_guides_for_georgians_in_us)' tells the agent exactly which upstream tools produce a valid slug, establishing the intended call order. There is no explicit when-not-to-use clause, but the sequencing guidance is concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the kartvelians.com guides for Georgian speakers in the US, and planned topics marked "coming soon".
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: "en" or "ka" (Georgian). Defaults to the query language. | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds the useful behavioral note that planned-but-unpublished topics are returned and flagged 'coming soon', but says nothing about return format or pagination. With annotations carrying the safety burden, a 3 is appropriate.
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 front-loaded sentence with no filler; the scope and the 'coming soon' inclusion are stated immediately.
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, optional-parameter, read-only list tool with full annotation coverage, the description covers what it returns conceptually (published plus planned topics). Only marginal gaps remain, such as return shape or ordering, which no output schema exists to explain.
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 50%: lang is documented in the schema while status is not. The description partially compensates by explaining that planned items are shown as 'coming soon', which hints at the planned/all status values, but it does not clarify the status enum's options or the default behavior.
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 states a specific verb (List) and resource (kartvelians.com guides for Georgian speakers in the US), plus notes it includes planned 'coming soon' topics. It is clear on its own, but it does not distinguish itself from the sibling tools search_guides_for_georgians_in_us and get_guide_for_georgians_in_us, which also deal with the same guides.
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?
There is no statement of when to use this tool versus the two sibling tools that operate on the same guide corpus. Usage is only implied by the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for any everyday-life question from a Georgian speaker in the US, especially New York (ქართველები ამერიკაში, ნიუ-იორკი): where to buy E-ZPass and paying tolls, renting an apartment, cosigners, subway and bus fares and OMNY, scams aimed at Uber and Lyft drivers, salvage-title cars, Zelle pay and taxes, driving on a Georgian license, loan-offer scams, sending or exchanging money with Georgia, remote jobs, and English words. Accepts English or Georgian. Returns up to 5 kartvelians.com guides with summary and link.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Answer language: "en" or "ka" (Georgian). Defaults to the query language. | |
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuine behavior beyond that: it accepts English or Georgian and returns up to 5 results with summary and link, which tells the agent what to expect from the call.
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?
Front-loads the core use case ('Use for any everyday-life question...'), then the topic list, then the return format. The long topic enumeration is verbose but serves retrieval/relevance matching, so it largely earns its place.
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?
With no output schema, the description responsibly explains the return (up to 5 guides with summary and link) and the accepted languages. Coverage of the query parameter's format is thin, but the essentials for calling the tool correctly are present.
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 50%: the lang enum is documented in the schema, but query is not. The description compensates by stating 'Accepts English or Georgian,' clarifying the lang dimension beyond the enum, and its topic list implies the query is natural-language text. Slightly above the baseline 3.
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 clear verb+resource ('search ... guides') and specifies the domain (everyday-life questions from Georgian speakers in the US) and result shape ('up to 5 kartvelians.com guides with summary and link'). An agent can distinguish it from the get/list siblings without opening the schema.
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?
Explicitly says 'Use for any everyday-life question from a Georgian speaker in the US' and enumerates concrete topics, giving strong positive-use guidance. It does not name the get_guide or list_guides siblings or state when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_guide_for_georgians_in_uslist_guides_for_georgians_in_ussearch_guides_for_georgians_in_usGeorgia education, Census, and immigration data: query, filter, aggregate, and link datasets.
Verified ITIN lender directory + 290 bilingual guides on US loans, cards & credit without an SSN.
Georgia's published auto insurance averages. Not a quote; we are not licensed here yet.
Georgia's Code, bills, and Supreme Court opinions as source text. Independent, not the State.
Add one secure layer between your agents and this server.