Gemstone and diamond cuts: ray-traced brilliance, fire and sparkle in 7 gems, 3D and faceting files
Scored across 8 tools
Two clusters overlap heavily: best_cuts_for_gemstone vs recommend_cut both answer 'what are the best cuts in this gemstone' (one fixed combined ranking, one buyer-priority ranking with filters), and cut_in_gemstone vs get_cut both describe a single cut in a stone (get_cut is a superset covering all seven gemstones). Descriptions do articulate the differences, and compare_cuts/get_cut_scores/search_cuts are distinct, but an agent could plausibly misselect among the top-cut and single-cut tools.
Six of eight names are verb_noun (get_cut, get_cut_scores, list_gemstones, compare_cuts, search_cuts, recommend_cut) and the get_cut/get_cut_scores pair is a clean refinement pattern. The two outliers, cut_in_gemstone and best_cuts_for_gemstone, are noun phrases that break the verb-led convention but remain readable.
Eight tools is well within the ideal 3-15 range and each covers a distinct access mode: browse, search, single-item detail, raw scores, pairwise comparison, ranking, and recommendation. No tool feels like dead weight, though the ranking/recommendation pair is a candidate for consolidation.
For a read-only reference library the surface covers discovery (list_gemstones, search_cuts), detail (get_cut, cut_in_gemstone), raw metrics (get_cut_scores), comparison (compare_cuts) and recommendations (two flavors) with no obvious dead ends. Minor gaps: no tool to retrieve the Cut Performance Index methodology or glossary of score definitions, and no way to enumerate cuts by outline/family outside search and recommend_cut's filters.
The top ten brilliants and the top ten jewelry cuts in one gemstone, ranked by brilliance, fire and scintillation added together, with the stone's optical constants.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | brilliants (round cuts), jewelry (fancy and step shapes) or both. | both |
| gemstone | Yes | Gemstone, as its slug. |
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 genuinely new behavioral detail: the ranking formula (brilliance + fire + scintillation summed) and the fact that optical constants are returned alongside the lists, which tells the agent how results are ordered.
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 dense sentence with no filler, and the core output (top ten of each kind) is front-loaded ahead of the ranking criteria. Minor awkwardness in 'in one gemstone', but nothing is wasted.
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 only two fully-enumerated parameters and no output schema, the description does the right extra work: it says what comes back (two ranked top-ten lists plus optical constants) and how ranking is computed. A brief note on tie-breaking or list length variability would close the remaining 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?
Schema description coverage is 100% and both parameters carry enum value descriptions, so the schema does the heavy lifting. The description's phrase 'one gemstone' and its mention of brilliants and jewelry cuts loosely mirrors the `kind` enum but adds no format or edge-case detail beyond the schema.
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+resource: returns the top ten brilliants and top ten jewelry cuts for a gemstone, ranked by a defined composite metric. It implicitly distinguishes itself from get_cut_scores and search_cuts by being a pre-ranked 'best of' list, but it never names a sibling to make the boundary explicit.
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 — call this when you want a curated top-ten ranking rather than raw per-cut scores — but there is no explicit statement of when to prefer it over get_cut_scores or search_cuts, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two cuts side by side in one gemstone: overall, brilliance, fire, scintillation, tilt, face-up spread and leakage from the Cut Performance Index, each cut's place in that stone, facets and size, and the products with prices and checkout links. For questions like 'oval or pear for my sapphire?'.
| Name | Required | Description | Default |
|---|---|---|---|
| cut_a | Yes | The first cut's slug or name, for example 'oval'. | |
| cut_b | Yes | The second cut's slug or name, for example 'pear'. | |
| gemstone | No | The stone to compare them in; diamond if left out. |
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 contributes beyond that by disclosing what the response contains — comparative CIP metrics, facet/size data, and product prices with checkout links — which matters since there is no output schema. It omits any note on result limits or fallback behavior when a cut is unavailable in a stone.
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 core purpose is front-loaded in the first clause, and the trailing example question is high-value for routing. The middle enumeration of metrics is dense but each item informs the agent about returned content, so nothing is clearly wasted; only the list length borders on heavy.
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 three fully documented parameters, no output schema, and read-only annotations, the description covers nearly everything an agent needs: what is compared, in what context, and roughly what comes back. Only edge-case behavior (unknown cut, stone without that cut) is unaddressed.
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 100%, so both cut slugs and the gemstone enum are already documented in the schema. The description reinforces that the comparison is scoped 'in one gemstone' and that the gemstone is a single shared context rather than per-cut, but adds no syntax or format detail beyond the schema.
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 ('Two cuts side by side in one gemstone') and enumerates exactly what is compared: CIP metrics, tier placement, facets, size, and shoppable products. This clearly distinguishes it from siblings like get_cut_scores or best_cuts_for_gemstone, which surface one cut or a recommendation rather than a head-to-head comparison.
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 example question 'oval or pear for my sapphire?' gives a concrete trigger condition that maps directly to the cut_a/cut_b/gemstone parameters. However, it never names an alternative such as recommend_cut or best_cuts_for_gemstone or says when not to use this tool, so the guidance stops short of full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How one cut performs in one gemstone: its headline, eight measured scores against the T73 round brilliant in the same stone, and its pros and cons. For questions like 'is an oval a good cut for sapphire?'.
| Name | Required | Description | Default |
|---|---|---|---|
| cut | Yes | The cut's slug or name. | |
| gemstone | Yes | Gemstone, as its slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context beyond annotations by specifying the return contents: a headline, eight measured scores against the T73 round brilliant, and pros/cons. It stops short of describing output format details or error behavior, which keeps it from a 5.
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 two dense, front-loaded sentences that immediately state the resource and its returned content, followed by a clear usage example. No sentence is redundant or wasteful.
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?
Given that there is no output schema, the description does the necessary work of explaining what the tool returns: headline, eight measured scores against the T73 round brilliant, and pros/cons. Combined with fully documented parameters and annotations covering safety, an agent has enough information to invoke and interpret 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 description coverage is 100%, so both parameters are fully documented in the input schema. The description implies the mapping of cut and gemstone via the example 'oval... sapphire' but adds no syntax or constraint details beyond what the schema already provides, so the baseline 3 applies.
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 tool's scope: performance of one cut in one gemstone, including headline, eight measured scores against the T73 round brilliant, and pros/cons. This is specific enough to distinguish the resource from broad siblings like list_gemstones or search_cuts, but it never explicitly names or contrasts with get_cut or get_cut_scores, leaving some ambiguity about overlap.
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 example question 'is an oval a good cut for sapphire?' gives a concrete usage context, making it clear when this tool is appropriate. However, it does not state when not to use it or point to alternatives such as get_cut_scores or best_cuts_for_gemstone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything about one cut: what it is, measured specifications (facets, angles, depth, size, index gear), brilliance, fire and scintillation in all seven gemstones against the T73, the products with prices and checkout links, its questions and answers, and its page.
| Name | Required | Description | Default |
|---|---|---|---|
| cut | Yes | The cut's slug or name, for example 'asscher', 'T73' or 'Old European'. | |
| gemstone | No | Optional: also return the pros and cons of this cut in this stone. |
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 valuable return-content detail (prices, checkout links, Q&A, page) that annotations cannot convey, but says nothing about failure behavior for an unknown cut slug.
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 long sentence that is front-loaded with 'Everything about one cut' and then enumerates contents compactly. It is list-heavy but each clause maps to a real returned field, so there is minimal waste.
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 correctly carries the burden of describing what comes back, and it does so comprehensively. The remaining gap is the optional gemstone behavior and error/not-found handling, which are left implicit.
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 100%, so both parameters are already documented and the baseline is a 3. The description hints at 'all seven gemstones' but never explains that the optional gemstone parameter narrows the response to pros/cons for that one stone, so it adds little beyond the schema.
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-resource pair implied by 'Everything about one cut' and enumerates the resource's contents (specs, brilliance/fire/scintillation scores, products, Q&A, page). It does not, however, distinguish this from siblings like get_cut_scores or cut_in_gemstone, which overlap on the scoring content.
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 only implied: an agent can infer this is the single-cut lookup keyed by slug/name. There is no explicit statement of when to use this versus get_cut_scores or cut_in_gemstone, and no stated preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scores from the Digital Gemology Cut Performance Index for every cut we sell: overall, brilliance, fire, scintillation, tilt, symmetry, spread, shape-norm and leakage, ray traced separately in diamond, moissanite, cubic zirconia, ruby, sapphire, emerald and amethyst, with each cut's place in its material. Filter by cut, category or material; with no filter, every row. Figures are unrounded. Never compare or rank scores across materials. Ruby and sapphire share one refractive index, so the same figures. Cuts not yet scored come with the reason.
| Name | Required | Description | Default |
|---|---|---|---|
| cut | No | The cut's slug or name, for example 'oval' or 'DG-M5'. | |
| category | No | brilliants, jewelry, historic, house or platonic. | |
| material | No | One stone (diamond, moissanite, cubic-zirconia, ruby, sapphire, emerald or amethyst); leave it out for all seven. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, and the description adds substantive domain constraints beyond them: the cross-material comparison ban, the ruby/sapphire shared refractive index caveat, unrounded figures, and the fact that unscored cuts return a reason. This is exactly the extra context an agent needs to interpret results correctly.
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 metric list is front-loaded and every clause carries information, including the caveats. The second half runs long in a single breath, but no sentence is 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?
No output schema exists, so the description takes on the burden of describing the return payload, and it does so thoroughly (metric names, per-material ray tracing, ranking placement, unrounded values, missing-score reasons). Nothing essential for correct invocation or interpretation 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 100% and enums are fully documented for category and material, so the schema carries the load. The description adds only the global default ('with no filter, every row'), which the schema already states for material; baseline 3 is appropriate.
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?
Names a specific resource (Digital Gemology Cut Performance Index scores) and enumerates exactly what is returned: overall, brilliance, fire, scintillation, tilt, symmetry, spread, shape-norm, leakage, ray traced per material. An agent can distinguish this from get_cut or search_cuts without opening any 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?
States filtering behavior ('Filter by cut, category or material; with no filter, every row') and a hard usage rule ('Never compare or rank scores across materials'), but gives no guidance on when to choose this over siblings such as best_cuts_for_gemstone, cut_in_gemstone or search_cuts. Tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The seven gemstones every cut is measured in, with refractive index, critical angle, dispersion, hardness and specific gravity, and the three best cuts of each kind.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: this is a fixed, closed set of exactly seven gemstones with a defined attribute list, which tells the agent to expect a small static reference table rather than a searchable or paginated collection.
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 cardinality and subject ('the seven gemstones every cut is measured in') then lists the returned fields. No filler, no redundancy.
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 and no parameters, the description carries the burden of describing return content, and it does so by naming every field plus the nested 'three best cuts'. It could be marginally more complete by stating the container shape (a list of seven gemstone objects), but nothing an agent needs to call it correctly 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?
The tool takes zero parameters and the schema is an empty object with additionalProperties=false, so there is nothing for the description to disambiguate. Baseline 4 applies.
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 names the exact resource (the seven gemstones that cuts are measured in) and enumerates the attributes returned (refractive index, critical angle, dispersion, hardness, specific gravity, plus three best cuts per gemstone). That is far more specific than a restatement of the name. It stops short of distinguishing itself explicitly from siblings like best_cuts_for_gemstone or get_cut_scores, which it partially overlaps with on the 'three best cuts' content.
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 only implied: an agent can infer this is the reference lookup for gemstone properties, but the description never says when to call it versus best_cuts_for_gemstone (which also returns best cuts) or cut_in_gemstone. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The best cuts in one gemstone for what matters to the buyer: overall light performance, brilliance, fire, scintillation (sparkle), spread (looks bigger for its weight), tilt (stays bright when tilted) or leakage (least light lost). Filter by family or outline. Returns a ranked short list with each cut's page and checkout links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many cuts to return, 1 to 20; 5 if left out. | |
| shape | No | Only cuts with this outline. All if left out. | |
| category | No | Only this family: brilliants, jewelry, historic or house. All if left out. | |
| gemstone | Yes | Gemstone, as its slug. | |
| priority | No | What to rank by; leakage ranks the least light lost first. overall if left out. | overall |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is only responsible for add-on context. It supplies two useful traits: results are a *ranked short list* and each entry carries page and checkout links. It does not mention that ranking is a scoring model over measured cut data or any caveats about sparse data.
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?
Two sentences, purpose first, then filters and return shape. The long parenthetical glosses on each priority term are dense but each carries real disambiguating value; only 'sparkle' for scintillation is redundant 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?
With no output schema, the description correctly steps in to say the return is a ranked short list with page and checkout links, which is the key thing an agent needs for follow-up calls. The remaining gap is that it never distinguishes this tool from the near-identical 'best_cuts_for_gemstone' sibling.
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, and the description genuinely adds meaning on top: it glosses 'spread' as 'looks bigger for its weight' and clarifies that 'leakage' ranks least light lost first, which is non-obvious from the bare enum. It adds no semantics for 'limit' or 'shape' beyond the schema, keeping it out of 5 territory.
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 ('recommend' a 'cut' for one gemstone) and enumerates the ranking dimensions (brilliance, fire, spread, tilt, leakage), so the agent knows exactly what the tool computes. It does not, however, contrast itself with the very similar sibling 'best_cuts_for_gemstone', leaving the distinction implicit.
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?
'Filter by family or outline' hints at narrowing, and the ranking-priority framing implies use when the buyer has a stated preference. But there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as best_cuts_for_gemstone or search_cuts, despite seven overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Digital Gemology's gem cuts and Platonic solids by name, style, shape or use (for example 'square step cut', 'round brilliant for moissanite', 'historic cushion', 'pear'). Returns each match with its page, facets, size, price and checkout links. Give a gemstone to add the cut's brilliance, fire and scintillation in that stone and to sort by them.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance (default with a query), total (brilliance + fire + scintillation, the default with a gemstone and no query), brilliance, fire, scintillation, facets (most first) or name. | |
| limit | No | How many cuts to return, 1 to 50; 10 if left out. | |
| query | No | Free text. Leave it out to list every cut that fits the filters. | |
| shape | No | Outline of the cut. | |
| category | No | brilliants, jewelry (fancy and step cuts), historic, house (our own designs) or platonic (solids, 3D files only). | |
| gemstone | No | Gemstone, as its slug. | |
| cutting_files | No | Only cuts that are also sold as GemCad cutting files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description is not burdened with safety disclosure. It adds useful behavioral context by describing the return contents: page, facets, size, price, and checkout links. It also explains that the gemstone parameter changes scoring and sorting behavior, which is valuable beyond the annotations.
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 front-loaded with the core search action, followed by return-value context and then the gemstone-specific behavior. It is compact, uses useful examples, and has no apparent 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 seven-parameter search tool with full schema coverage and a clear read-only annotation profile, the description is largely complete. It explains what matches contain and how the gemstone parameter affects results, though it could do more to position the tool against its siblings.
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 schema already documents all seven parameters well. The description adds meaningful semantics not fully captured by the schema, especially that providing a gemstone evaluates and sorts cuts by brilliance, fire, and scintillation in that specific stone.
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 and resource: search gem cuts and Platonic solids. It adds concrete query examples such as 'square step cut' and 'historic cushion', making the scope clear. It does not explicitly differentiate itself from siblings like best_cuts_for_gemstone or get_cut.
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 implies when to use the tool through examples and through the gemstone clause, which explains that supplying a gemstone adds brilliance, fire, and scintillation scoring. However, it does not explicitly say when to prefer this tool over best_cuts_for_gemstone, list_gemstones, or get_cut.
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.
compare_cutsrecommend_cutsearch_cuts1 field changedInput schema / properties / limit / descriptionAdded value: +"How many cuts to return, 1 to 50; 10 if left out."get_cut_scores2 fields changedInput schema / properties / material / descriptionPrevious value: -"diamond or moissanite; leave it out for both."New value: +"One stone (diamond, moissanite, cubic-zirconia, ruby, sapphire, emerald or amethyst); leave it out for all seven."Input schema / properties / material / enumPrevious value: -[
- "diamond",
- "moissanite"
-]New value: +[
+ "diamond",
+ "moissanite",
+ "cubic-zirconia",
+ "ruby",
+ "sapphire",
+ "emerald",
+ "amethyst"
+]best_cuts_for_gemstonecut_in_gemstoneget_cutget_cut_scoreslist_gemstonessearch_cutsGemology lessons to search and quote: the 4 Cs, diamond anatomy, grading reports, moissanite
Identify gemstones by refractive index, birefringence, SG, pleochroism and spectrum. Compare 7 gems
FITINY jewellery tools: density-corrected carat/mm, GIA grades, ISO 8653 ring sizes
Optical design, simulation and analysis with GPU-powered ray tracing. Import from Zemax and CAD.
Add one secure layer between your agents and this server.
