Drillable
Server Details
A multi-domain reference corpus where every answer drills down to its cited, verified source.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 1.5/5 across 53 of 53 tools scored.
Tools are clearly separated by domain prefix, making each tool's purpose distinct within its domain. However, the generic 'lookup', 'search', and 'verify' tools could cause ambiguity as they overlap with domain-specific lookup_concept and search tools when a domain is not specified.
Naming follows a consistent domain__verb_noun pattern across all domain-specific tools. The generic tools 'lookup', 'search', and 'verify' break this pattern by not including a domain prefix, introducing a minor inconsistency.
With 53 tools across 8 domains, the count is high but justified by the breadth of domains. Each domain has a reasonable set of tools, though some (like eurorack with 14 tools) may be heavy. Overall, the count is borderline excessive but still manageable.
Each domain covers core query operations (search, get, lookup concept), and the generic tools fill cross-domain needs like concept lookup and verification. Minor gaps exist (e.g., no update/delete for most domains), but for a knowledge-focused server, the surface is mostly complete.
Available Tools
57 toolsacupuncture__find_point_realizationsDInspect
[acupuncture] find_point_realizations
| Name | Required | Description | Default |
|---|---|---|---|
| lineage | No | ||
| functions | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read/write nature, side effects, or access requirements. The description adds no value beyond the tool name.
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 extremely brief, but it fails to provide essential information. While brief, it is not appropriately sized for the tool's complexity; a single tautological sentence is insufficient.
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, no annotations, and two parameters (one required), the description is completely inadequate. It does not convey the tool's functionality or context, making it unusable for an AI agent.
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 input schema has two parameters (lineage and functions) with 0% schema description coverage. The description does not explain their purpose or expected values, leaving the agent without guidance.
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 is merely the tool name with a prefix '[acupuncture]', providing no indication of what the tool does. It does not differentiate from sibling tools like acupuncture__get_point or acupuncture__search_points.
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?
No guidance on when to use this tool versus alternatives. Sibling tools have diverse purposes, but the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acupuncture__get_combinationDInspect
[acupuncture] get_combination
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Combination code, e.g. 'four-gates'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it says nothing about side effects, authorization, or output behavior. The tool could be read-only or have hidden effects—no information is given.
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 extremely short but fails to earn its place—it is under-specified rather than concise. It provides zero useful content beyond what the name and schema already imply.
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 the tool's simplicity (one parameter, no output schema), the description should clarify what a 'combination' is, what the output looks like, and how it fits with sibling tools. None of this is provided, leaving the agent guessing.
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 input schema covers 100% of parameters and already describes 'code' with an example ('four-gates'), so the baseline is 3. The description adds no additional meaning beyond that 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 is a tautology—'[acupuncture] get_combination'—merely restating the tool name without specifying what a 'combination' is or how it differs from sibling tools like get_point or search_points. It provides no unique action or resource detail.
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?
No guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when not to use it. The description is entirely absent of usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acupuncture__get_evidenceDInspect
[acupuncture] get_evidence
| Name | Required | Description | Default |
|---|---|---|---|
| point | No | ||
| topic | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details. It does not disclose any side effects, required permissions, data scope, or output format. The description fails to add any value beyond the tool name.
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 extremely short, but conciseness should not sacrifice informativeness. Here, it is under-specified and provides no useful content, failing to earn 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?
Given the complexity (two parameters, no output schema, no annotations, 0% schema coverage), the description is completely inadequate. It does not help the agent understand inputs, outputs, or behavior.
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%, and the description does not explain the meaning of the two parameters (point, topic). The agent has no semantic information to correctly populate these fields.
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?
Description is a tautology: '[acupuncture] get_evidence' merely restates the name. It does not specify the verb or the resource, failing to clarify what evidence is retrieved or how it differs from sibling tools like acupuncture__get_point or acupuncture__search_points.
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?
No context is provided about when to use this tool versus alternatives. Sibling tools include many evidence-related functions (e.g., get_point, search_points), but the description offers no guidance on when get_evidence is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acupuncture__get_pointDInspect
[acupuncture] get_point
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Standard point code, e.g. 'LI4', 'ST36', 'GV20'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It gives no information about side effects, idempotency, required permissions, or return value behavior.
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 extremely short but at the cost of missing essential information. Conciseness without substance is not effective.
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 a simple parameter, the description should at least hint at what is returned (e.g., point data). It does not, making the tool incomplete for reliable invocation.
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% (the 'code' parameter is documented with examples). The description adds no extra meaning beyond the schema, so baseline of 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?
The description is a tautology: '[acupuncture] get_point' merely restates the tool name with a domain prefix. It does not specify what the tool does (e.g., retrieve details for a specific acupuncture point).
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?
No guidance is provided on when to use this tool versus siblings like acupuncture__search_points or acupuncture__find_point_realizations. Missing context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acupuncture__lookup_conceptDInspect
[acupuncture] lookup_concept
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A TCM term, e.g. 'qi', 'shen', 'jing', 'tonify'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral information beyond the name. The agent learns nothing about side effects, required permissions, or return behavior.
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 extremely concise but at the cost of being under-specified. It does not earn its place because it provides no useful information beyond the tool name.
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 the tool has one parameter and no output schema, the description should explain the purpose and behavior. It fails completely; the agent cannot determine what the tool does or returns.
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 parameter 'term' is well-described in the input schema with an example. Since schema coverage is 100%, the baseline is 3. However, the description adds no extra meaning 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 '[acupuncture] lookup_concept' is a tautology that merely restates the tool's name without providing a specific verb or resource. It fails to distinguish this tool from sibling tools like camera__lookup_concept or other acupuncture tools.
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?
No guidance is given on when to use this tool versus alternatives. There are multiple lookup_concept tools in other domains and many acupuncture-specific siblings, but the description offers no context or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
acupuncture__search_pointsDInspect
[acupuncture] search_points
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| region | No | ||
| channel | No | ||
| function | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description offers no behavioral information such as whether the tool is read-only, destructive, or has any side effects. It discloses nothing beyond the name.
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 extremely short but not effectively concise; it lacks substantive content. While it avoids verbosity, it fails to convey necessary information, making it under-specified rather than concise.
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 the tool has 4 parameters, no output schema, and no annotations, the description is critically incomplete. It does not explain what the tool returns, how to use parameters, or how to interpret results.
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?
With 4 parameters and 0% schema description coverage, the description adds no meaning to the parameters. It does not explain what 'text', 'region', 'channel', or 'function' represent or how they filter results.
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 is a tautology: '[acupuncture] search_points' merely repeats the tool name without any verb or resource specification. It fails to indicate that the tool searches for acupuncture points based on parameters.
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?
No guidance is provided on when to use this tool versus siblings like 'acupuncture__find_point_realizations' or 'acupuncture__get_point'. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
camera__check_compatibilityDInspect
[camera] check_compatibility
| Name | Required | Description | Default |
|---|---|---|---|
| lens | Yes | Lens id, e.g. 'sony-fe-85-14-gm', 'fuji-xf-56-12'. | |
| mount | Yes | Target mount/body: 'sony-e' (FF) | 'fuji-x' (APS-C). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral information such as read-only or destructive nature, side effects, or required permissions.
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 extremely short but lacks necessary information; it is under-specified rather than concise. Every sentence should earn its place, but here there is only one non-informative sentence.
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 the tool has no output schema and no annotations, the description is severely incomplete. It fails to explain the purpose, return value, or any other context needed for appropriate use.
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% with parameter descriptions for 'lens' and 'mount'. The description adds no extra meaning but also does not contradict the schema, so baseline of 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?
The description is a tautology, merely repeating the tool name with a domain prefix. It does not state what the tool does or what 'check_compatibility' means.
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?
No guidance on when to use this tool versus alternatives like 'camera__find_kit_realizations' or 'camera__kit_redundancy'. No usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
camera__find_kit_realizationsDInspect
[camera] find_kit_realizations
| Name | Required | Description | Default |
|---|---|---|---|
| mount | No | Optional mount-lock: 'sony-e' | 'fuji-x'. | |
| school | No | Optional school scope: 'fast-ff' | 'light-apsc' (the preference axis). | |
| use_cases | Yes | The SET of use-case roles to cover, e.g. ['portrait','wide-landscape','low-light']. Roles: portrait, wide-landscape, walkaround, low-light, tele-reach, macro. | |
| weight_cap_g | No | Optional total-weight budget in grams (objective, B3-holds). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it says nothing about side effects, read-only nature, or permissions. The tool could be performing complex lookups or modifications; the agent is left blind.
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?
While short, the description is under-specified rather than concise. It fails to front-load any useful information, essentially being a placeholder.
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 the tool has 4 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain return values, parameter constraints, or how results are presented.
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 the input schema already documents all parameters. The description adds no extra meaning, but the baseline of 3 applies as the schema handles parameter semantics adequately.
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 is a tautology: '[camera] find_kit_realizations' merely restates the tool name without any verb or resource clarification. It does not specify what finding kit realizations entails.
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?
No guidance is provided on when to use this tool versus sibling tools like camera__check_compatibility or camera__get_lens. The description offers no context about use cases or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
camera__get_lensDInspect
[camera] get_lens
| Name | Required | Description | Default |
|---|---|---|---|
| lens_id | Yes | Lens id, e.g. 'sony-fe-85-14-gm', 'fuji-xf-56-12'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as whether the tool is read-only, returns specific data, or has side effects. The agent has no information beyond the name.
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 extremely concise (two words) but at the severe cost of informativeness. It is under-specified, not efficiently compressed.
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 one parameter, no output schema, and no annotations, the description is completely inadequate. It does not explain what the tool returns, what the lens_id represents, or any prerequisites.
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% with a clear description for 'lens_id'. However, the tool description does not add any meaning beyond what the schema provides, so a baseline of 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?
The description 'get_lens' is vague, barely more than the tool name. It does not specify that it retrieves details for a specific lens, and with sibling 'camera__search_lenses' present, the distinction is unclear.
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?
No guidance on when to use this tool versus alternatives like 'camera__search_lenses' or 'camera__check_compatibility'. The description provides no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
camera__kit_redundancyDInspect
[camera] kit_redundancy
| Name | Required | Description | Default |
|---|---|---|---|
| kit | Yes | A seeded kit id ('holy-trinity-sony','sony-portrait-gas','travel-apsc-light','fuji-gas') OR an array of lens ids (e.g. ['sony-fe-24-70-28-gm','sigma-50-14-art-e']). | |
| school | No | Optional school scope: 'fast-ff' | 'light-apsc'. | |
| use_cases | No | Optional: the use-cases the kit is meant to serve. Omit to default to the kit's own derived-union coverage. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a minimal description, no behavioral traits are disclosed. The agent gains no insight into side effects, required permissions, or expected behavior.
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 extremely short but fails to be informative. It is under-specified rather than concise, wasting the opportunity to provide clarity.
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 no output schema, no annotations, and a trivial description, the agent has insufficient information to understand what the tool returns or when it is appropriate to use.
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 baseline is 3. The description adds no additional meaning beyond the detailed parameter descriptions already in 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 '[camera] kit_redundancy' merely repeats the tool name and does not state what the tool does. It lacks a verb and resource, providing no actionable information for an AI agent.
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?
No guidance is given on when to use this tool versus alternatives such as 'camera__check_compatibility' or 'camera__find_kit_realizations'. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
camera__lookup_conceptDInspect
[camera] lookup_concept
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A term, e.g. 'crop-factor', 'aperture', 'bokeh', 'gas'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Description says nothing about behavioral traits such as read-only status, required permissions, or return behavior.
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?
Extremely concise, but at the expense of meaningful content. This is under-specification, not genuine conciseness.
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?
Despite low complexity, the description provides no context about return values, scope, or behavior. It is completely insufficient for an AI agent to understand the tool's role.
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%, but the description adds no additional meaning beyond the schema's parameter description. The description is a mere label.
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 is a tautology, simply repeating the tool name. It does not state what the tool does beyond the implied 'lookup concept', and fails to differentiate from sibling lookup_concept tools for other domains.
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?
No guidance on when to use this tool versus alternatives. The description provides no context about the domain or circumstances for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
camera__search_lensesDInspect
[camera] search_lenses
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Use-case: 'portrait','wide-landscape','walkaround','low-light','tele-reach','macro'. | |
| text | No | Free text over id, name, brand. | |
| brand | No | Brand, e.g. 'Sony', 'Fujifilm', 'Sigma', 'Viltrox'. | |
| mount | No | Mount/system, e.g. 'sony-e', 'fuji-x'. | |
| coverage | No | Sensor coverage: 'FF' or 'APS-C'. | |
| lens_type | No | 'prime' or 'zoom'. | |
| price_tier | No | 'budget' | 'mid' | 'premium'. | |
| max_aperture | No | Fastest f-number to accept, e.g. 1.8 means f/1.8 or faster (smaller number). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it says nothing about how the search works (e.g., returns multiple lenses, supports partial matches, pagination). The agent has no insight into the tool's operation.
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 extremely short but at the expense of usefulness. It is merely a repetition of the name, missing essential information. True conciseness would convey key information efficiently, which it does not.
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 the tool's complexity (8 parameters, no output schema, no annotations), the description is severely lacking. It does not mention what the output looks like, how results are sorted, or any constraints, making it incomplete for an agent to use effectively.
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 input schema provides detailed descriptions for all 8 parameters (100% coverage), so the agent can understand each parameter's meaning. However, the tool's description adds no additional context beyond the schema, failing to compensate for any gaps.
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 is simply '[camera] search_lenses', which merely repeats the tool's name without any additional clarification of its purpose. It fails to specify that this tool searches for camera lenses based on various criteria.
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?
No guidance is provided on when to use this tool versus alternatives like camera__get_lens or camera__check_compatibility. The description gives no context for its appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktail__check_buildDInspect
[cocktail] check_build
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | List of {ingredient, amount_oz}. | |
| method | No | 'stir' | 'shake' | 'build' (sets default dilution). | |
| dilution | No | Optional explicit dilution fraction (overrides method). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It gives no information about what 'check' entails (e.g., validation, safety, balance), side effects, permissions, or return values. The tool's behavior is entirely opaque.
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 extremely short but not efficiently informative. It under-specifies the tool, making it a label rather than a useful explanation. Effective conciseness requires clarity, which is absent here.
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 three parameters including a nested array and no output schema, the description fails to explain the tool's purpose, return values, or usage scenarios. It is completely inadequate for an agent to understand when or how to invoke it.
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%, with each parameter documented adequately in the schema (e.g., spec as list of ingredient/amount, method with enum hint, dilution as optional). The tool description adds no additional value, but per guidelines, baseline is 3 when coverage is high.
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 is essentially a tautology, restating the tool name 'check_build' with a prefix '[cocktail]'. It does not specify what action is performed or what resource is acted upon, failing to distinguish from sibling tools like cocktail__compose_build.
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?
No guidance is provided on when to use this tool versus alternatives such as cocktail__compose_build or cocktail__get_cocktail. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktail__compare_cocktailsDInspect
[cocktail] compare_cocktails
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Drink ids to compare, e.g. ['negroni','boulevardier','americano']. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Description is minimal and does not indicate if the operation is read-only, what it returns, or any side effects. No behavioral traits are communicated.
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 extremely short (one phrase) but it is under-specification, not conciseness. It fails to provide useful information.
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 a comparison with no output schema and a vague description. The agent cannot determine what the tool returns (e.g., similarities, differences) or how to interpret results.
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% for the 'ids' parameter, so the baseline is 3. However, the description adds no value beyond the schema—it does not explain how the comparison uses the ids or what the output represents.
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?
Description is a tautology: '[cocktail] compare_cocktails' restates the tool name. It does not specify any verb or resource, and fails to differentiate from sibling tools like get_cocktail or reachable_cocktails.
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?
No guidance on when to use this tool vs. alternatives. Does not mention prerequisites, limitations, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktail__compose_buildDInspect
[cocktail] compose_build
| Name | Required | Description | Default |
|---|---|---|---|
| roles | Yes | Desired role slugs, e.g. ['base-spirit','souring-agent','sweetener']. | |
| school | No | Optional school to scope to: 'classic' or 'tiki'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a description that provides no behavioral context, the agent has no insight into side effects, safety, or operation behavior.
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?
Extremely concise but under-specified; the description lacks structure and fails to provide useful information beyond the name.
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?
Without an output schema, the description should explain return behavior, but it does not, leaving the tool's purpose and effects entirely unspecified.
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 adequate parameter descriptions, so baseline is 3, but the tool description adds no value beyond the schema, warranting a slight deduction.
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?
Description is merely '[cocktail] compose_build', a tautology that restates the name without indicating the tool's function or distinguishing it from siblings.
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?
No guidance on when to use this tool versus alternatives like cocktail__check_build or any other sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktail__get_cocktailDInspect
[cocktail] get_cocktail
| Name | Required | Description | Default |
|---|---|---|---|
| cocktail_id | Yes | Cocktail id, e.g. 'negroni', 'mai-tai'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It says nothing about whether the tool is read-only, what it returns, or any side effects. It fails to convey any behavioral traits.
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 extremely short but under-specified. It does not earn its place as it provides no useful information beyond the tool name. Conciseness is outweighed by lack of content.
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 the tool's simplicity and lack of annotations, the description should at least clarify what is returned and that it fetches by ID. It fails to do so, leaving the tool incomplete in context.
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 schema description coverage is 100% for the single parameter, which includes examples. Per rubric, baseline is 3. The tool description adds no extra meaning beyond the schema, so score stays at 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?
The description '[cocktail] get_cocktail' is essentially a tautology, restating the name. It does not specify what the tool does, such as retrieving a cocktail by ID, nor does it distinguish from sibling tools like cocktail__search_cocktails.
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?
No guidance is provided on when to use this tool versus alternatives. The description gives no context about scenarios, prerequisites, or exclusions relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktail__lookup_conceptDInspect
[cocktail] lookup_concept
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A term, e.g. 'abv', 'dilution', 'stir', 'sour'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It fails to mention whether this is a read-only operation, what the output format is, or any other behavioral traits. The description is essentially empty.
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?
Extremely concise but under-specified. A single sentence that is just the tool name does not provide enough information; it sacrifices clarity for brevity.
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 the low complexity (1 required parameter, no output schema), the description is still incomplete. It does not explain what the tool returns or how the concept lookup works, relying solely on the parameter description.
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% with the parameter 'term' clearly described. The tool description adds no additional meaning beyond the schema, so baseline score of 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?
The description '[cocktail] lookup_concept' is a tautology, restating the tool name without specifying what the tool does. The parameter description hints at looking up cocktail terms, but the description itself provides no verb or outcome.
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?
No guidance on when to use this tool vs. other cocktail tools (e.g., search_cocktails, get_cocktail) or similar lookup_concept tools in other domains. The description offers no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktail__reachable_cocktailsDInspect
[cocktail] reachable_cocktails
| Name | Required | Description | Default |
|---|---|---|---|
| school | No | Optional school to scope to: 'classic' or 'tiki'. | |
| inventory | Yes | Ingredient ids you have, e.g. ['gin','campari','sweet-vermouth','lime-juice']. | |
| substitute | No | Also return role-substitution variations (default true). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist and the description offers no behavioral traits like side effects, permissions, or safety.
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?
Extremely brief but not informative; underspecified and fails to earn 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?
Given 3 parameters and no output schema, the description is totally inadequate for agent understanding.
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 baseline is 3; description adds no extra meaning beyond schema fields.
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 is a tautology repeating the tool name; it fails to specify the verb or resource purpose.
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?
No guidance on when to use this tool versus siblings; no context or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cocktail__search_cocktailsDInspect
[cocktail] search_cocktails
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Free-text over id, name, rationale. | |
| family | No | Family: 'spirit-forward', 'sour', 'highball', 'template'. | |
| school | No | School: 'classic' or 'tiki'. | |
| spirit | No | Base ingredient id, e.g. 'gin', 'tequila', 'rye'. | |
| profile | No | Emergent profile: 'spirit-forward','sour','bittersweet','refreshing','bracing','rich'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits (e.g., read-only, destructive, side effects). It adds no transparency beyond the tool name.
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 extremely short but lacks content; it is under-specified rather than concise. It provides no useful information and wastes the slot.
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 5 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to explain the purpose, return value, or any behavioral details necessary for correct use.
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 detailed parameter descriptions, so the schema already explains each parameter. The tool description adds no additional meaning, but baseline is 3 due to high coverage.
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 is only the tool name repeated, providing no information about what the tool does. It fails to distinguish from sibling tools like cocktail__lookup_concept or cocktail__check_build.
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?
No guidance on when to use this tool versus alternatives such as cocktail__get_cocktail or cocktail__lookup_concept. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__draw_patch_diagramDInspect
[eurorack] draw_patch_diagram
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional patch-level prose hints displayed below the graph. | |
| wires | Yes | ||
| modules | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It offers none—no mention of side effects, permissions, rate limits, or data mutability. The agent cannot infer safety or cost of invocation.
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 extremely short but at the expense of utility. It is not concise in a helpful way; it is under-specified. Every sentence should earn its place, but this single sentence is tautological.
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 tool with 3 parameters (nested objects, no output schema, no annotations), the description is completely inadequate. It fails to explain the purpose of the diagram, the meaning of modules/wires/notes, or any constraints. The tool cannot be used correctly based on the description alone.
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?
Though the input schema includes descriptions for parameters, the tool description itself adds no meaning beyond the schema. Given schema description coverage is low (33%), the description should compensate but fails to mention any parameter semantics.
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 '[eurorack] draw_patch_diagram' is a tautology that merely repeats the tool name without specifying the verb or resource. It fails to convey what the tool does beyond its name, leaving the agent without clear purpose.
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?
No guidance is provided on when to use this tool versus its siblings (e.g., eurorack__resolve_modules, eurorack__visualize_module). The description offers no context for decision-making or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__find_compatible_withDInspect
[eurorack] find_compatible_with
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| module_id | Yes | ||
| relationship | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, data mutation, or access requirements. The agent gets no insight into tool behavior.
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 extremely short, but this is under-specification, not conciseness. It fails to convey any useful information, so it does not earn 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?
Given the tool has 3 parameters, no output schema, and no annotations, the description is completely inadequate. The agent cannot correctly invoke or interpret the tool without external knowledge.
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?
With 0% schema description coverage, the description should explain the parameters. It does not. The names 'module_id', 'limit', 'relationship' are self-explanatory to some extent, but the description adds no additional meaning or constraints 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 is a tautology, repeating the tool name with a prefix. It does not state what the tool does; no verb or resource is explained. The agent cannot determine the purpose.
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?
No guidance is provided on when to use this tool versus its many siblings (e.g., eurorack__find_role_realizations, eurorack__reachable_pairings). The description fails to differentiate any context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__find_role_realizationsDInspect
[eurorack] find_role_realizations
| Name | Required | Description | Default |
|---|---|---|---|
| role_id | Yes | ||
| technique_id | Yes | ||
| available_modules | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral information. It doesn't disclose read-only vs destructive nature, return format, or any side effects, leaving the agent completely uninformed.
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 extremely short, but it fails to provide any useful information. Conciseness should come with clarity; here it's under-specification.
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 3 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain the tool's purpose, behavior, or how to use it effectively.
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 schema has 0% description coverage for parameters, and the description adds no meaning to 'role_id', 'technique_id', or 'available_modules'. The agent cannot infer what values are expected or how they relate to each other.
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 is a tautology, restating the tool name without explaining what 'find_role_realizations' does. It lacks a verb and specific resource, and fails to distinguish from sibling tools like eurorack__find_compatible_with or eurorack__reachable_pairings.
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?
No guidance on when to use this tool versus alternatives. The description provides no context about the use case, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__get_manual_chunkDInspect
[eurorack] get_manual_chunk
| Name | Required | Description | Default |
|---|---|---|---|
| chunk_id | Yes | Chunk id from manual_outline[].chunk_id or a search_manual result. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention whether the tool is read-only, requires authentication, or any side effects. The name suggests a read operation but is not explicit.
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 overly concise to the point of being uninformative. It does not earn its place as it provides no useful content beyond the tool name.
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 the tool has one parameter, no output schema, and many sibling tools, the description is completely inadequate. It fails to provide essential context for correct invocation.
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% for the single parameter 'chunk_id', which is well described. The description adds no additional meaning beyond the schema, so baseline of 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 is a tautology, merely repeating the tool name with a prefix '[eurorack] get_manual_chunk'. It does not state what the tool does, such as retrieving a chunk of a manual.
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?
No guidance is provided on when to use this tool versus siblings like eurorack__search_manual or other get tools. There is no context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__get_moduleDInspect
[eurorack] get_module
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Optional: "concise" returns the id-card subset (name, manufacturer, hp, description, capabilities, production_status, replaced_by) and drops the heavy arrays — good for triage or multi-module sweeps. "full" (default) returns the complete spec. Ignored when `fields` is set. | |
| fields | No | Optional: top-level keys to include (e.g. ["jacks","parameters"]) when you only need a slice and want to skip the full payload. Omit for everything. id and _meta are always returned. Takes precedence over `view`. Selectable: manufacturer, name, hp, depth_mm, power, description, capabilities, jacks, parameters, modes, hidden_functions, _field_absent, panel_sections, character, common_problems, role_fitness, firmware_versions, reference_url, audit_url, production_status, replaced_by, manual_outline, manual_outline_total. | |
| module_id | Yes | Stable module id, "<manufacturer-id>/<module-slug>" (e.g. "alm-busy-circuits/pamelas-new-workout"). | |
| outline_limit | No | Optional: max manual_outline entries to return this call (default 100, hard max 250). | |
| heading_filter | No | Optional: case-insensitive substring matched against manual_outline heading_path. Narrows the outline to chunks under a heading (e.g. "calibration") so you skip scanning a long outline. | |
| outline_offset | No | Optional: zero-based offset into the (optionally heading-filtered) manual_outline. Page past the default cap instead of falling back to search_manual. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details. There is no indication of whether the tool is read-only, destructive, requires authentication, or has rate limits.
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 extremely underspecified—a single phrase that is not even a complete sentence. It fails to convey any useful information, which is not conciseness but deficiency.
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 the complexity (6 parameters, no output schema, many sibling tools), the description is completely inadequate. It omits return values, pagination behavior, and any context for using the parameters together.
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 the input schema already documents all parameters. The description adds no meaning beyond the schema, but the schema itself is thorough, resulting in a baseline score of 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?
The description is a tautology: '[eurorack] get_module' merely repeats the tool name without stating what the tool does. No verb, resource, or scope is provided.
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?
No guidance on when to use this tool vs siblings like get_modules (list), search_modules (search), or get_manual_chunk. Use cases, prerequisites, and exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__get_modulesDInspect
[eurorack] get_modules
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Optional: "concise" returns the id-card subset for every module in the batch and drops the heavy arrays — cheapest way to triage a list. "full" (default) returns complete specs. Ignored when `fields` is set. | |
| fields | No | Optional: top-level keys to include on every module in the batch (e.g. ["jacks","parameters"]) when you only need a slice — keeps a multi-module fetch from returning full specs. Omit for everything. id and _meta are always returned. Takes precedence over `view`. Same selectable keys as get_module. | |
| module_ids | Yes | ||
| outline_limit | No | Optional: max manual_outline entries per module (default 100, hard max 250). | |
| heading_filter | No | Optional: case-insensitive substring matched against manual_outline heading_path, applied to every module in the batch. | |
| outline_offset | No | Optional: zero-based manual_outline offset, applied to every module in the batch. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention that the tool is read-only, the maximum batch size of 25, or behavior on invalid module IDs. The schema provides some clues but the description adds nothing.
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 extremely short but at the expense of informativeness. It is under-specified for a tool with 6 parameters and batch functionality, lacking essential usage details.
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 the tool's complexity (batch retrieval, multiple optional parameters) and the absence of an output schema, the description is severely incomplete. It does not cover return values, pagination, or differentiation from single-module fetch.
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 83%, so most parameters are already described in the input schema. The description adds no additional meaning, but the schema itself is adequate. Baseline score of 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?
The description '[eurorack] get_modules' is a tautology that simply restates the tool name. It fails to specify the verb or resource, and does not distinguish from sibling tools like 'eurorack__get_module' which likely retrieves a single module.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention batch retrieval of multiple modules or contrast with 'eurorack__get_module' for single module access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__get_sourceDInspect
[eurorack] get_source
| Name | Required | Description | Default |
|---|---|---|---|
| source_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden for behavioral disclosure. It says nothing about side effects, permissions, or return behavior. The agent is left with no insight into what invoking this tool entails.
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 only a few words, but this is under-specification rather than conciseness. It lacks essential information, making the tool hard to use correctly.
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 a single required parameter and no output schema, the description should at least clarify the return format or the nature of the 'source'. It fails to provide a minimally complete picture, making the tool unreliable for an AI agent.
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%. The description adds no meaning to the 'source_id' parameter beyond the schema's integer and minimum constraints. The parameter's role or expected value range remains unclear.
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 '[eurorack] get_source' is a tautology that merely restates the tool name. It does not specify what a 'source' is or what the tool retrieves, providing no actionable purpose.
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?
No usage guidance is provided. There is no indication of when to use this tool versus sibling tools like 'eurorack__get_module' or 'eurorack__search_modules'. The description offers no context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__lookup_conceptDInspect
[eurorack] lookup_concept
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a tautological description, there is no disclosure of behavioral traits. It is unclear whether the tool is read-only, mutates state, or requires authentication.
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?
While extremely brief, the description is not concise—it is under-specified. It does not contain any useful information that its title already conveys, making it wasteful and unhelpful.
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 the tool has no output schema and no parameter descriptions, the description must compensate. It fails to provide any contextual completeness, leaving the agent without the information needed to use the tool effectively.
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% and the description adds no parameter information. The single 'name' parameter lacks any explanation of its format, source, or role, leaving the agent to infer its use.
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 '[eurorack] lookup_concept' merely repeats the tool title without providing any verb or resource context. It does not specify what the tool does, leaving the agent to guess its purpose.
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?
No usage guidance is provided. The description does not indicate when to use this tool over its many sibling lookup_concept tools or other eurorack tools, nor does it mention any preconditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__rack_redundancyDInspect
[eurorack] rack_redundancy
| Name | Required | Description | Default |
|---|---|---|---|
| rack | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it is empty beyond the name. It does not state whether the tool is read-only, destructive, requires authentication, or any side effects. The agent gains no insight into behavior.
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?
While the description is short, it is under-specified rather than concise. It provides zero information, meaning each word (actually just the name) fails to earn its place. A proper concise description would be a useful sentence.
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 the complexity of the domain (eurorack modular synthesizers), the lack of output schema, and the presence of many sibling tools, the description is completely inadequate. It does not help the agent understand what 'redundancy' means in this context.
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%. The description adds no meaning beyond the schema. The 'rack' parameter is an array of strings, but the description does not explain what values are expected or what constitutes a valid rack identifier.
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 is simply '[eurorack] rack_redundancy', which repeats the tool name without providing any verb or resource indicating what the tool does. It is a tautology and fails to clarify the tool's purpose.
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?
No usage guidelines are provided. The description does not indicate when to use this tool versus the many sibling tools such as eurorack__find_compatible_with or eurorack__draw_patch_diagram. There is no context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__reachable_pairingsDInspect
[eurorack] reachable_pairings
| Name | Required | Description | Default |
|---|---|---|---|
| rack | Yes | ||
| limit | No | ||
| relationship | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as computational cost, side effects, or prerequisites. The agent gains no insight into the tool's behavior beyond the name.
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?
While the description is short, it is not concise in a helpful way—it omits essential information. A single sentence with no structure would be more acceptable if it conveyed purpose, but here it is merely a placeholder.
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 the tool's complexity (3 parameters, no annotations, no output schema), the description provides no contextual completeness. It fails to help the agent understand the tool's role or output, making it nearly useless for selection and invocation.
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%, and the description adds no explanation of the three parameters (rack, limit, relationship). The agent cannot infer valid values or constraints from the description alone.
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 is a verbatim repetition of the tool name "reachable_pairings" with a prefix, providing no verb or resource to indicate its function. It does not state what the tool does, making it a tautology.
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?
No guidance is given on when to use this tool versus alternatives like eurorack__find_compatible_with or eurorack__reachable_techniques. The description lacks any context for selective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__reachable_techniquesDInspect
[eurorack] reachable_techniques
| Name | Required | Description | Default |
|---|---|---|---|
| rack | Yes | ||
| limit | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist and the description provides no behavioral traits. The agent cannot infer whether the tool is read-only, destructive, or requires authentication.
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 short but at the cost of being useless. It lacks structure and does not earn its place as meaningful text.
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 the lack of output schema, annotations, and parameter descriptions, the description is completely insufficient. The tool's input and output remain mysterious.
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 0% and description adds no meaning. The 'rack' and 'limit' parameters have no context; their purpose and format are entirely unclear.
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?
Description is a tautology: '[eurorack] reachable_techniques' restates the name without specifying any verb or resource. It does not indicate what the tool does.
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?
No guidance on when to use this tool versus sibling tools. Siblings like 'reachable_pairings' or 'get_module' likely have distinct purposes but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__resolve_modulesDInspect
[eurorack] resolve_modules
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Module names (or ids) to resolve, up to 100. Order and duplicates preserved. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details provided; description is just the name. Without annotations, the agent has no information about side effects, permissions, or output nature.
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?
Extremely short but under-specified; does not earn its place with useful content. True conciseness would convey purpose in few 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?
Given siblings and lack of output schema, the description should differentiate this tool (e.g., resolving aliases) but fails entirely. Incomplete for agent use.
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 param descriptions are adequate ('Module names (or ids) to resolve...'). Tool description adds no extra meaning, so 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?
Description is a tautology ('[eurorack] resolve_modules') that restates the name without indicating a specific verb or resource. It fails to clarify what 'resolve' means—e.g., validating, normalizing, or fetching details.
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?
No guidance on when to use this tool versus siblings like 'get_module' or 'search_modules'. Description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__search_manualDInspect
[eurorack] search_manual
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Search terms. | |
| module_id | No | ||
| source_id | No | ||
| source_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and description does not disclose any behavioral traits such as whether the tool is read-only, what side effects occur, or any required permissions. The agent has no information about the tool's behavior.
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 extremely short but at the cost of being completely uninformative. It does not earn its place; it provides no value to the agent.
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 the tool has 5 parameters and no output schema or annotations, the description is severely lacking. It fails to provide necessary context for an agent to use the tool effectively.
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 only 20% (only query has a description). The description adds no parameter meaning beyond the schema; it does not explain module_id, source_id, or source_type. The agent cannot understand how to use these parameters correctly.
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?
Description is only '[eurorack] search_manual', which is a tautology of the name. It does not state what the tool does or how it differs from siblings like search_modules or get_manual_chunk.
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?
No guidance provided on when to use this tool vs alternatives. Missing context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__search_modulesDInspect
[eurorack] search_modules
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| limit | No | ||
| hp_max | No | ||
| hp_min | No | ||
| offset | No | ||
| capability | No | Capability id (kebab-case). | |
| manufacturer | No | Manufacturer id. | |
| signal_type_in | No | ||
| signal_type_out | No | ||
| audio_outputs_min | No | ||
| voct_tracking_quality | No | ||
| voct_tracking_range_min | No | ||
| voct_temperature_compensated | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides zero behavioral disclosure. It does not mention that the tool performs a search, supports pagination, or has filtering capabilities. The agent gets no insight into side effects or required permissions.
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 extremely short (one line) but it is under-specification, not conciseness. It offers no useful information, making it ineffective despite its brevity.
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 the tool's complexity (13 parameters, no output schema), the description is completely inadequate. It does not explain the search behavior, default parameters, or return structure.
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 input schema has 13 parameters but only 2 have descriptions (capability, manufacturer). The description adds no meaning beyond the schema, which is sparse. With 15% schema coverage, the description does not compensate.
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 is a tautology: '[eurorack] search_modules' restates the name and title without providing any verb or resource specificity. It fails to indicate that this tool searches for modules by various criteria.
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?
No guidance is given on when to use this tool versus alternatives like eurorack__find_compatible_with, eurorack__get_module, or eurorack__get_modules. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__search_techniquesDInspect
[eurorack] search_techniques
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It says nothing about side effects, permissions, scope, or any behavioral traits, making it impossible for the agent to anticipate the tool's actions.
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 extremely short but this is under-specification, not conciseness. The single phrase does not earn its place; it is a redundant repetition of the name, providing no useful information.
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 the complexity of a nested parameter and the absence of an output schema or annotations, the description is completely inadequate. It fails to provide any context about input semantics, return values, or usage scenarios.
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 input schema has 0% description coverage for its parameters. The description does not explain the purpose or usage of the 'filter' object or its sub-fields ('text', 'module_id', 'capability'), leaving them entirely undocumented.
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 is a tautology: it merely repeats the tool name '[eurorack] search_techniques'. It provides no information about what a 'technique' is or what the tool actually does, failing to distinguish it from sibling tools like 'eurorack__search_modules' or 'eurorack__reachable_techniques'.
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 offers no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurorack__visualize_moduleDInspect
[eurorack] visualize_module
| Name | Required | Description | Default |
|---|---|---|---|
| module_id | Yes | Stable module id, "<manufacturer-id>/<module-slug>" (e.g. "whimsical-raps/three-sisters"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to state whether the tool performs a read, write, or visualization operation, nor does it mention side effects, authentication needs, or output format.
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 extremely short but sacrifices substance for brevity. It is not concise in a helpful sense; it omits essential information about the tool's purpose and behavior.
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 the tool has one parameter, no output schema, and no annotations, the description is entirely inadequate. An agent cannot determine what the tool returns, how to interpret the output, or how it differs from other eurorack tools.
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%, meaning the schema already documents the single parameter 'module_id' with a clear format. The description adds no additional semantic information beyond what the schema provides, so baseline score of 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?
The description is essentially a tautology: '[eurorack] visualize_module' restates the tool name without providing any verb or resource. It does not specify what 'visualize' means (e.g., generate an image, display connections) and fails to distinguish from sibling tools like 'draw_patch_diagram' or 'get_module'.
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?
No guidance is given on when to use this tool versus alternatives such as 'eurorack__draw_patch_diagram' or 'eurorack__get_module'. There is no indication of prerequisites, context, or common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookupAInspect
Define a concept/term from a domain's glossary (e.g. 'stir', 'crop-factor', 'roughness'). Routes to each domain's lookup_concept; pass domain to target one, omit to fan out. For entities/records use search. Abstains on a miss, which is logged as a gap (the demand signal) — there is no report_gap verb.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The concept/entity to resolve. | |
| domain | No | Optional: restrict to one domain (e.g. 'acupuncture'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses routing to per-domain lookup_concept, fan-out when domain omitted, silent abstention on miss with gap logging, and no report_gap verb. This provides comprehensive behavioral context.
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-loaded with purpose, well-structured with routing, usage guidance, and miss behavior. Slightly dense but every sentence earns its place; could be slightly trimmed but overall efficient.
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?
Very complete for a 2-param tool with no output schema: covers purpose, routing, domain usage, alternative tool, miss behavior. Lacks description of successful return format, but given no output schema, it's 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 descriptions, baseline 3. Description adds semantics: explains domain parameter effect (target vs. fan-out) and provides example terms, adding value beyond 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?
Clearly states it defines glossary terms with examples, distinguishes from 'search' for entities/records, and explains routing to domain-specific lookup_concept. The verb 'define' and resource 'glossary concept' are specific.
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 when to use this tool (for concept definitions) and when not to (use 'search' for entities/records). Describes behavior with and without domain parameter, and explains miss behavior and lack of report_gap verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
music-theory__audit_oracleDInspect
[music-theory] audit_oracle
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | No | Optional dataset id, e.g. 'schwartz2003', 'mcdermott2016-Tsimane'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no information about behavioral traits such as read-only or destructive nature. The agent is left uninformed about side effects or permissions.
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?
Extremely concise but at the cost of meaning. The single phrase does not earn its place as it provides no useful information. Structure is poor due to lack of content.
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 the low complexity (1 optional param, no output schema), the description is completely inadequate. It fails to explain the tool's purpose or return format, making it nearly unusable for an AI agent.
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% for the single optional parameter 'dataset_id', which is well-documented with examples. The description adds nothing beyond the schema, so baseline score of 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?
Description is essentially the tool's name with a prefix ('[music-theory] audit_oracle'), which is a tautology. It does not state what the tool does, leaving the purpose vague.
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?
No usage guidance provided. There is no indication of when to use this tool versus sibling tools like music-theory__by_population or music-theory__compute_roughness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
music-theory__by_populationDInspect
[music-theory] by_population
| Name | Required | Description | Default |
|---|---|---|---|
| interval | No | Interval key whose verdict to test across populations, e.g. 'tritone'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It fails to state any effects, permissions, or side effects. The description is too minimal to convey behavioral traits.
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 extremely short but at the expense of clarity. It is under-specified rather than concise, lacking essential information for an AI agent to use the tool correctly.
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 annotations, the description is completely inadequate. It fails to explain the tool's purpose, return values, or behavior, leaving the agent with insufficient context.
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% with a clear parameter description ('Interval key whose verdict to test across populations, e.g. 'tritone''). The tool description adds nothing beyond the schema, so baseline score of 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?
The description is a tautology ('[music-theory] by_population') that merely repeats the tool name without specifying what the tool does. The parameter description hints at testing verdicts across populations, but the overall purpose remains unclear.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, exclusions, or comparison to sibling tools like music-theory__audit_oracle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
music-theory__compute_roughnessDInspect
[music-theory] compute_roughness
| Name | Required | Description | Default |
|---|---|---|---|
| ratio | No | OR a raw frequency ratio, e.g. '1.5'. | |
| interval | No | Interval key, e.g. 'minor_seventh'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no description of behavior. The tool's effects, side effects, or output format are completely unspecified.
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?
Extremely concise but to the point of being uninformative. The single sentence is a repetition of the tool name.
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?
Without output schema or behavioral details, the description is wholly inadequate. A user cannot determine what the tool returns or how to use it.
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 description adds no meaning to the parameters beyond the schema. Even though schema coverage is 100%, the description is empty and does not compensate.
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 is a tautology: '[music-theory] compute_roughness'. It does not specify what the tool does or what resource it acts upon.
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?
No guidance on when to use this tool or how it differs from siblings. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
music-theory__get_consonanceDInspect
[music-theory] get_consonance
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional context: 'P4_above_bass','4-3_suspension','dominant_7th_context'. | |
| interval | Yes | Interval key, e.g. 'major_third', 'tritone'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral information. It does not mention whether the tool is read-only, any side effects, or required permissions. No annotations are present to fill the gap.
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 extremely brief but lacks crucial content. It is under-specified rather than concise. A helpful description would include purpose and usage hints.
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 no output schema and no description, the context is completely incomplete. The tool's return value and behavior are entirely unclear. Sibling tools indicate a domain of music theory, but without description, the tool cannot be used effectively.
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 input schema has 100% description coverage, providing clear meaning for both parameters. The tool description adds no extra value, but the schema coverage is high enough to maintain a baseline score of 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?
The description is a tautology: it merely repeats the tool's name with a prefix, 'get_consonance'. It does not state what the tool actually does, such as retrieving the consonance value of a musical interval.
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?
No usage guidance is provided. The description does not indicate when to use this tool over siblings like music-theory__search_consonance or music-theory__compute_roughness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
music-theory__lookup_conceptDInspect
[music-theory] lookup_concept
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A term, e.g. 'roughness', 'suspension'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully describe behavior, but it contains nothing about side effects, return format, or prerequisites. The agent has no information about what happens when the tool is invoked.
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 extremely short, but this is under-specification rather than conciseness. It is not front-loaded with useful information and lacks structured content.
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 lookup tool, the description still fails to mention what is returned (e.g., definition, examples). The parameter description offers some context, but the overall description is incomplete for effective agent use.
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% for the single parameter, and the schema already provides a meaningful description with examples. The tool description adds no additional semantic value, so 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?
The description is a tautology, simply restating the tool name '[music-theory] lookup_concept', with no indication of what the tool actually does. The parameter description provides a minimal hint, but the description itself fails to clarify the tool's purpose.
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?
No usage context or guidance is provided. The description does not indicate when to use this tool over sibling tools like 'music-theory__audit_oracle' or other 'lookup_concept' tools from different domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
music-theory__search_consonanceDInspect
[music-theory] search_consonance
| Name | Required | Description | Default |
|---|---|---|---|
| gap | No | Only claims with (true) / without (false) a gap. | |
| band | No | Human band: 'consonant', 'mid', or 'dissonant'. | |
| status | No | Referee status: 'verified','partial','corrected','context-irreducible'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits. It fails to indicate whether the tool is read-only, requires authentication, or has any side effects.
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 extremely brief but at the cost of utility. It is under-specified and does not convey any meaningful information about the tool's purpose or usage.
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 are 3 parameters and no output schema, the description is woefully incomplete. It does not explain the search behavior, filter semantics, or what results to expect.
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 each parameter having a description. The description adds no additional meaning beyond the schema, so baseline score of 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?
Description is tautological, just repeating the tool name 'search_consonance' within brackets. It does not specify what the tool searches, what it returns, or how it relates to other music theory tools.
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?
No guidance on when to use this tool versus alternatives like music-theory__get_consonance or music-theory__compute_roughness. It does not mention any selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Search the mounted corpora by query. Routes to each domain's search tool; pass domain to target one. Empty results are logged as gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for. | |
| domain | No | Optional: restrict to one domain. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses routing behavior and that empty results are logged as gaps, but with no annotations, it fails to mention other important traits like error handling or authentication requirements.
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 efficiently convey the core purpose and key behavior with 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?
Given the tool's complexity as a meta-search, the description covers the essentials but could benefit from mentioning output format or how results are aggregated.
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 descriptions cover 100% of parameters, and the description adds context that the 'domain' parameter routes to a specific domain's search tool, beyond what the schema provides.
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 it searches mounted corpora and routes to domain-specific tools, distinguishing it from sibling tools like 'search_points' or 'search_cocktails'.
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 mentions passing 'domain' to target one, but does not provide guidance on when to use this meta-tool versus the domain-specific search tools, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supplements__check_safetyDInspect
[supplements] check_safety
| Name | Required | Description | Default |
|---|---|---|---|
| supplement_ids | Yes | Product ids taken together, e.g. ['zinc-30mg','multivitamin']. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It does not state whether this is a read operation, what side effects occur, what constitutes a safety issue, or what the response looks like. The agent gains no insight into the tool's behavior.
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?
While extremely brief, the description is under-specified to the point of being useless. Conciseness should not come at the cost of essential information.
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 tool with a single parameter, no output schema, and no annotations, the description must provide complete context. It fails entirely: no indication of what the tool checks, what input format is expected beyond the schema, or what the output signifies.
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 the schema's parameter description is clear ('Product ids taken together...'), so the baseline is 3. The description adds nothing beyond the schema, but does not contradict it.
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?
Description is a tautology ('[supplements] check_safety') that merely repeats the tool name. It lacks a verb or any explanation of what the tool does, and does not distinguish it from sibling tools like supplements__stack_review.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or scenarios where check_safety is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supplements__get_supplementDInspect
[supplements] get_supplement
| Name | Required | Description | Default |
|---|---|---|---|
| supp_id | Yes | Product id, e.g. 'multivitamin', 'magnesium-glycinate', 'creatine-monohydrate'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits. The agent has no information about side effects, idempotency, or return format.
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?
Extremely concise but under-specified. The description has no front-loaded content and fails to earn its place by providing any useful information.
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 many sibling tools, the description should explain what the tool returns and how it differs from search or safety checks. It is completely inadequate.
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 a clear description for the 'supp_id' parameter, including examples. The tool description adds nothing, but the schema already provides adequate parameter semantics, so baseline of 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 is a tautology: '[supplements] get_supplement' simply restates the tool name without specifying the verb or resource. It does not explain what 'get_supplement' means or what data it retrieves.
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?
No usage guidelines are provided. The description does not indicate when to use this tool over siblings like 'supplements__search_supplements' or 'supplements__check_safety'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supplements__lookup_conceptDInspect
[supplements] lookup_concept
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A term, e.g. 'ul', 'rda', 'bioavailability', 'structure-function-claim', 'evidence-certainty'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no description of behavioral traits (e.g., read-only, data source, performance), the tool entirely lacks transparency. The description does not disclose what happens when the tool is invoked or any side effects.
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 extremely short but this is a result of under-specification rather than conciseness. It wastes the opportunity to inform the agent and provides no structured information beyond the bare name.
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 the lack of output schema and annotation context, the description leaves agents guessing about return values, data volume, and usage constraints. For a simple lookup tool, basic behavioral context 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% with a clear parameter description and examples. However, the tool description itself adds no additional meaning beyond what the schema already provides, so baseline of 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?
The description '[supplements] lookup_concept' is a tautology that merely restates the tool name without defining what 'concept' means or what the tool does. The parameter examples (e.g., 'ul', 'rda') hint at domain terms, but the description itself fails to convey purpose.
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?
No guidance is provided on when to use this tool versus sibling tools like 'supplements__get_supplement' or 'supplements__search_supplements'. The agent must infer from the name and parameter, which is insufficient for reliable selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supplements__rank_supplementsDInspect
[supplements] rank_supplements
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | The grounded axis to sort on (default 'certainty'). A value axis like 'best' abstains. | |
| goal | Yes | The goal to rank for, e.g. 'sleep' | 'immune' | 'energy' | 'joint' | 'strength'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral traits such as side effects, permissions, or constraints. The agent cannot infer any important behaviors beyond the parameter schema.
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?
While very short, the description lacks substance. Conciseness should not come at the expense of informativeness; this is under-specification rather than efficient communication.
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 the tool has no output schema and no annotations, the description should provide contextual completeness about behavior and output. It fails to do so, leaving the agent with insufficient information for proper usage.
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 input schema has 100% description coverage for both parameters ('goal' and 'by'), so the schema already explains their meaning. The description adds no additional value, placing it at 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?
The description is a tautology ('[supplements] rank_supplements'), restating the tool name without any specification of what the tool does. It provides no verb or resource context, making it impossible for an agent to understand the tool's purpose.
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 guidance on when to use this tool versus alternatives. Sibling tools include 'supplements__get_supplement', 'supplements__search_supplements', and others that could overlap, but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supplements__search_supplementsDInspect
[supplements] search_supplements
| Name | Required | Description | Default |
|---|---|---|---|
| form | No | Form/salt, e.g. 'glycinate','citrate','softgel','gummy'. | |
| goal | No | Use-role: 'sleep','immune','energy','joint','general-insurance','strength'. | |
| kind | No | 'single' (one active) or 'blend' (multivitamin/B-complex — many actives). | |
| text | No | Free text over product id, name. | |
| active | No | Active compound, e.g. 'magnesium','b12','vitamin-d','creatine','iron'. | |
| regime | No | Dosing regime: 'conservative' (RDA-floor) or 'optimization' (biohacker). | |
| certainty | No | Evidence grade: 'high','moderate','low','insufficient','none' (filters by the active's evidence). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, pagination, or result limits. The agent is left with no information about what the tool does or its side effects.
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 overly terse and under-specified. It consists of a single line that restates the tool name, which does not provide meaningful information. Conciseness is not achieved when the content is missing.
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 7 parameters, no annotations, and no output schema, the description fails to provide essential context about return values, filtering behavior, or usage constraints. The tool's purpose is completely unclear.
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 the tool description adds no parameter information, the input schema covers all 7 parameters with descriptions (100% coverage). The schema adequately documents parameter semantics, so no deduction is warranted.
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 is a tautology, simply repeating the tool name 'search_supplements' without specifying what it does. It fails to indicate that this tool searches for supplements based on various criteria.
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?
No guidance is provided on when to use this tool versus alternatives like supplements__get_supplement or supplements__lookup_concept. The description offers no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supplements__stack_reviewDInspect
[supplements] stack_review
| Name | Required | Description | Default |
|---|---|---|---|
| supplement_ids | Yes | Product ids in the stack, e.g. ['multivitamin','b12-sublingual','vitamin-d3-2000iu']. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details. The agent cannot infer side effects, permissions, or operational characteristics.
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 extremely concise but under-specified, offering no more than the tool name. It fails to provide any substantive information, which is not genuine conciseness.
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 the tool's simplicity (1 param, no output schema, no annotations), the description is still completely inadequate. It does not compensate for missing structured information.
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%, with the single parameter already described in the schema. The description adds no additional meaning, so a baseline of 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?
The description is a tautology, restating the name as '[supplements] stack_review'. It provides no verb or resource, failing to clarify what the tool does.
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?
No guidance is given on when to use this tool versus its siblings. The agent is left without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifyBInspect
Check a claim's verification status. Where the domain surfaces a core/verify TRUTH-REFEREE verdict (verified / corrected / unverified-abstained against an independent oracle), that DEEP oracle check is returned; otherwise it falls back to a corpus-grounding check (the ✓verified / ⚠seed badge). The deep check was the owed extraction — now wired per-domain via core/verify.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The claim to check. | |
| domain | No | Optional: restrict to one domain. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses two behavioral paths (deep oracle check vs corpus-grounding fallback) and mentions domain-specific wiring, but does not describe side effects, authorization needs, or error handling. The description adds some transparency but lacks completeness.
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 reasonably concise with a clear front-loaded purpose, but the latter part uses jargon ('DEEP oracle check', 'owed extraction') that may confuse an AI agent without providing proportional benefit. It could be simplified.
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 the tool's complexity (two verification methods) and no output schema, the description fails to explain return values or response format. It also omits prerequisites, error conditions, or caveats, leaving the agent without essential context for correct invocation.
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 schema already describes both parameters with 100% coverage, but the description adds valuable context about the domain parameter's role in restricting to a specific domain and explains the underlying verification logic, which enriches understanding 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 clearly states the tool checks a claim's verification status, which is a specific verb+resource. It distinguishes from domain-specific siblings by being a general verification tool, but the technical jargon about 'core/verify TRUTH-REFEREE' and 'oracle check' may not be immediately clear to an AI agent.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for checking claim status, but does not compare to sibling tools or specify contexts where other verification tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing-style__check_pasticheDInspect
[writing-style] check_pastiche
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The candidate passage to score (≥~80 words for a meaningful result). | |
| author_id | No | Author to compare against; default 'jane-austen'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must disclose behavior. It fails to mention that the tool scores a passage against an author's style, any required permissions, or side effects. The description is essentially empty.
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 extremely brief but at the cost of being uninformative. It is not structured or front-loaded with useful information, making it underspecified rather than concise.
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 the tool has two parameters, no output schema, and no annotations, the description is wholly inadequate. It fails to explain what the tool returns or any behavioral context, leaving the agent with almost no understanding.
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 description adds no meaning beyond the input schema. The parameter descriptions in the schema are informative (e.g., text length recommendation, default author), but the tool description itself contributes nothing.
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 is a tautology: '[writing-style] check_pastiche' restates the name without any explanation of what 'check_pastiche' does. It provides no verb, resource, or differentiation from sibling tools.
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?
No usage guidance is provided. The description does not indicate when to use this tool versus its siblings, such as writing-style__describe_style or writing-style__find_examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing-style__describe_styleDInspect
[writing-style] describe_style
| Name | Required | Description | Default |
|---|---|---|---|
| author_id | No | Author id, e.g. 'jane-austen' (the only one seeded so far). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and description is empty of behavioral info. Does not disclose if this is a read or mutation operation, or any side effects.
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?
Extremely short but not concise in a helpful way; it omits essential information. Under-specification.
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 no output schema and no annotations, the description fails to explain what the tool returns or any behavioral context. Incomplete.
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 a decent parameter description, but the tool description adds nothing beyond the schema. Baseline 3 but no added value, so 2.
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?
Description is merely the tool name with a prefix, a tautology. No verb or resource specified; does not indicate what the tool does.
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?
No guidance on when to use this tool versus siblings like writing-style__find_examples or writing-style__get_feature. No context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing-style__find_examplesDInspect
[writing-style] find_examples
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Max examples (default 3, max 8). | |
| query | No | Free-text string to search the corpus for (overrides feature_id). | |
| author_id | No | Author id; default 'jane-austen'. | |
| feature_id | No | Feature to exemplify, e.g. 'semicolon_rate', 'dialogue_ratio', 'fw_such'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It says nothing about whether the tool is read-only, what it returns, or any side effects.
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?
While extremely short, this is under-specification rather than effective conciseness. The description lacks essential information, making it unhelpful.
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 description is completely inadequate given the tool's four parameters, no annotations, and no output schema. It fails to provide any meaningful context for an AI agent.
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 the schema already explains all parameters. The description adds no value beyond the schema, but the baseline is 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?
The description is merely a restatement of the tool name: '[writing-style] find_examples'. It lacks a verb and resource specification, and fails to distinguish from sibling tools like search_features or get_feature.
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?
No usage guidance is provided. The description does not indicate when to use this tool versus its siblings, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing-style__get_featureDInspect
[writing-style] get_feature
| Name | Required | Description | Default |
|---|---|---|---|
| author_id | No | Author id, e.g. 'jane-austen'. | |
| feature_id | Yes | Feature id, e.g. 'mean_sentence_length', 'comma_rate', 'fw_very'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It fails to indicate that this is a read-only lookup, whether it returns raw values or descriptions, or any side effects. The description is wholly inadequate.
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 extremely short, but this is under-specification rather than conciseness. It lacks essential information and does not front-load any useful content.
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 the tool has 2 parameters, no output schema, and no annotations, the description should provide context about what the feature value represents, typical usage, or return format. The single-line description is completely insufficient.
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 clear examples for both parameters. The description adds no additional meaning, but per calibration guidelines, a baseline of 3 is appropriate when schema already documents parameters thoroughly.
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 '[writing-style] get_feature' is a tautology, simply restating the tool name without any verb or resource specification. It fails to indicate that the tool retrieves a specific writing-style feature by ID.
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?
No usage guidance is provided. The description does not explain when to use this tool over siblings like 'describe_style' or 'find_examples', nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing-style__inspect_measurementDInspect
[writing-style] inspect_measurement
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | Work id, e.g. 'pride-and-prejudice', 'emma', 'persuasion'. | |
| feature_id | No | Sentence-length feature: 'mean_sentence_length' (default), 'median_sentence_length', 'sentence_length_stdev'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It contains no information about side effects, permissions, return format, or any behavioral traits, leaving the agent completely uninformed.
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 extremely short but lacks substance. It does not earn its place as it provides no useful information beyond the tool name. It is under-specification rather than conciseness.
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 the tool has 2 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the tool's function, inputs, outputs, or any constraints, making it insufficient for correct invocation.
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 input schema has 100% description coverage, so the baseline is 3. The description does not add any meaning beyond the schema, but it also does not contradict or mislead, so a score of 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?
The description is a tautology: it only repeats the tool name 'inspect_measurement' without stating what action it performs or what resource it inspects. It fails to convey a clear purpose beyond the obvious.
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?
No usage guidance is given. The description does not indicate when to use this tool compared to siblings like get_feature or describe_style, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing-style__lookup_conceptDInspect
[writing-style] lookup_concept
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A term, e.g. 'type-token-ratio', 'hapax', 'free-indirect-discourse', 'burrows-delta'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits. The tool name implies a read-only lookup, but there is no confirmation of safety, idempotency, or side effects. An agent has no information about what happens when the tool is invoked.
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 extremely short (one line), but it fails to convey any useful information. Conciseness is not a virtue when it comes at the cost of meaning. The description reads as a placeholder and does not earn 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?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is wholly inadequate. It does not explain what a 'concept' is, the nature of the lookup (definition, cross-reference, etc.), or the format of the result. An agent cannot reliably use this tool from the description alone.
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% for the single parameter 'term', which includes a list of examples. Per the guidelines, a high-coverage schema sets a baseline of 3. The description itself adds no parameter information beyond the schema, so it neither helps nor harms.
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 is a tautology: '[writing-style] lookup_concept' simply restates the tool's name and namespace. It does not state what the tool does, what a 'concept' is in this domain, or how it differs from sibling tools like search_features or find_examples. This provides no functional understanding for an AI agent.
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?
No guidance is provided on when to use this tool versus alternatives. Many sibling tools (e.g., search_features, find_examples) also deal with writing-style concepts, but the description offers no differentiation or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
writing-style__search_featuresDInspect
[writing-style] search_features
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Free text over feature id/name/definition. | |
| category | No | Filter: 'structural'|'lexical'|'punctuation'|'readability'|'function-word'. | |
| author_id | No | Author id (for the interpretation count); default 'jane-austen'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as side effects, permissions, or rate limits. The description carries the full burden but is entirely silent.
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 extremely short but not effectively concise; it lacks essential information. It does not earn its place as there is no meaningful content.
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 the tool has three parameters and no output schema or annotations, the description is completely inadequate. It provides no contextual information about what the search returns or how to use the parameters.
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 the input schema already documents all three parameters. The description adds no additional meaning beyond the schema, which is the baseline expectation at this coverage level.
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 is a tautology: it simply repeats the tool name in brackets ('[writing-style] search_features'). It does not state what the tool does beyond what can be inferred from the name, providing no specific verb or resource.
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?
No usage guidelines are provided. The description gives no indication of when to use this tool versus alternatives, no context, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!