FastBound MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools target a distinct entity and verb (e.g., get_item vs. get_acquisition_item), and descriptions clarify overlap such as acquire vs. create_pending_acquisition. However, the high number and granular variants (dispose_theft_loss, dispose_destroyed, dispose_nfa) could cause misselection if descriptions are skimmed.
Naming Consistency4/5
Uses a consistent verb_noun pattern with standard prefixes (get/list/search/create/update/delete/set/attach/commit/add/remove). Minor deviations like bare verbs 'acquire' and 'dispose', plus 'list_4473_dispositions', break the pattern slightly.
Tool Count2/5
51 tools is well over the 25-tool threshold for a typical server, even accounting for a broad domain. Many operations are split into hyperspecific tools (set_item_external_id, edit_disposition_item_price, attach_disposition_contact) that could be consolidated, making the surface unnecessarily heavy.
Completeness5/5
Provides full lifecycle coverage: items, acquisitions, dispositions, contacts, reports/downloads, and webhooks. Includes special disposition types (theft/loss, destroyed, NFA) and pending vs. committed workflows, leaving no obvious core functionality missing.
Average 4.1/5 across 51 of 51 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; the description redundantly says 'Read-only' but adds that it searches multiple contact types and lists filter fields. No further behavioral traits like pagination or result limits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise; one sentence plus 'Read-only' immediately conveys the operation. No wasted words, though it misses some useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description is too brief. It does not explain the response format, pagination behavior, or how filters interact, leaving significant ambiguity for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%); only skip and take have descriptions. The description mentions filtering by name, FFL number, trade name, or organization name, which maps to some properties, but does not clarify individual fields such as suffix, middleName, licenseName, or how filters combine.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Search' and the resource 'contacts' (individuals, organizations, FFLs). Distinguishes from siblings like get_contact or create_contact by focusing on search/filter behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding contacts via filters but does not explicitly state when to use it over get_contact or other tools, nor does it provide exclusions. Sibling tools suggest a direct lookup via get_contact, but that is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint: false. The description adds 'Executes directly' and 'Write', which clarify that the operation is an immediate mutation and not read-only. This adds some context beyond annotations but does not disclose error conditions, audit trail behavior, or constraints like the disposition status. Overall, moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The first sentence captures the core function, and the second provides behavioral context ('Executes directly' and 'Write'). Every sentence serves a purpose, though 'Write' is somewhat redundant with 'Add'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description covers the essential purpose and the pending-disposition condition. However, it lacks guidance on how this fits into the overall disposition lifecycle (e.g., must be before commit), or what happens if the disposition is not pending. The schema fills in parameter details, so completeness is adequate but not outstanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all three parameters. The description reiterates that items are added 'by GUID' and 'optionally with a price', which aligns with the 'id' and 'price' properties in the schema. It adds little beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Add inventory items (by GUID, optionally with a price) to a pending disposition.' It specifies the target resource (pending disposition), the input type (GUID), and optional price. This distinguishes it from sibling tools like remove_disposition_items and edit_disposition_item_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the context: 'to a pending disposition', which implies it should only be used for pending dispositions. However, it does not explicitly mention when not to use it (e.g., committed/locked dispositions) or suggest alternatives like remove_disposition_items. The guidance is clear but lacks exclusionary details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description repeats 'Read-only' which is already declared via annotations (readOnlyHint: true). It adds no additional behavioral context such as pagination, ordering, filtering, or response format. With annotations covering safety, the description contributes little beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource. No wasted words; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with one parameter and no output schema. The description, combined with the straightforward operation, is mostly adequate. However, it does not mention whether the list is paginated or what fields are returned, which would be helpful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% since the id parameter has a description ('GUID of the disposition'). The description does not add any extra meaning about the parameter, but with full schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List the items on a disposition' uses a specific verb (list) and resource (items on a disposition), clearly distinguishing it from sibling tools like get_disposition (which gets the disposition itself) and add_disposition_items (which adds items). It is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The read-only hint is covered by annotations, but the description does not mention contexts such as 'use this to preview items before modifying a disposition' or exclude any siblings. Usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the sparse annotation (only destructiveHint: false), the description adds that the action 'executes directly' and the acquisition remains uncommitted, which are important behavioral traits. The explicit 'Write' label clarifies that this is a mutating operation. However, it does not disclose validation rules, error cases, or idempotency, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that lead with the purpose and follow with execution context. The trailing 'Write' is optional but does not waste space. Every sentence carries meaning, making it well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A 21-parameter write operation with no output schema and minimal annotations requires more contextual guidance. The description covers the core intent but omits many operational details: behavior when acquisition is committed, duplicate handling, or which optional fields matter for specific firearm types. The schema partially compensates, but the overall package is under-specified for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 21 parameters and only 48% schema description coverage, the description should compensate by explaining parameter roles, but it adds nothing beyond the domain hint 'firearm'. The schema's partial descriptions are the only source of parameter guidance, and the description does not help disambiguate optional fields or their relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' and a clear resource 'a single firearm to a pending acquisition', which distinguishes it from sibling tools like add_disposition_items (disposition vs acquisition) and create_pending_acquisition (which creates the acquisition rather than adding items). The scope 'single firearm' adds useful precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pending acquisition' and 'still uncommitted' implies when to use the tool, but it does not explicitly mention alternatives or exclusions (e.g., for modifying an existing item use update_acquisition_item). Usage guidance is present but only implicitly, requiring the agent to infer from sibling names and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the tool can 'delete' a license, which is a destructive operation, but the annotations set destructiveHint=false. This is a direct contradiction. The description also lacks any explanation of side effects, permissions, or reversibility beyond 'Executes directly.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences deliver the essential information with no waste. The action list, field mapping, and execution note are all relevant and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema, the description covers core action logic but omits details about copyOnFile and expiration semantics (though schema covers expiration), potential return values, and error scenarios. The contradiction also weakens completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful action-specific parameter requirements that go beyond the schema, clarifying that type and number are for add, while licenseId is for update/delete. Schema coverage is 75%, and this guidance compensates for ambiguity in optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose with specific verbs ('Add, update, or delete') and a clear resource ('a license on a contact'). This clearly distinguishes it from sibling tools, none of which manage contact licenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditional guidance for each action ('For add provide type+number; for update/delete provide licenseId'), which is essential for correct invocation. It does not name alternatives because none exist, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds 'Executes directly' and 'Write,' which hint at immediate mutation, but it does not provide additional context about auth, side effects, or what happens to existing contacts. The added value beyond annotations is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief and front-loaded with the main purpose. However, the redundant 'Write.' at the end adds no value and slightly reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention whether the operation overwrites an existing contact, what the response looks like, or any side effects. It also lacks details about the auditUser parameter's role. Given the simple schema and no output schema, the description is too sparse to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with 100% description coverage. The tool's description does not mention parameters or add any additional meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('acquisition contact on an item'), explicitly targeting items rather than acquisitions, which distinguishes it from the sibling tool attach_acquisition_contact. The scope is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the intended use case: setting the acquisition contact on an item. It does not explicitly mention alternatives or exclusions, but the wording provides clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds the useful detail that the id can be FastBound GUID or externalId, which complements the idType parameter. However, it does not disclose not-found behavior or response format beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core action front-loaded. 'Read-only' is slightly redundant with the annotation but harmless. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with full schema and annotations, the description is mostly complete. It lacks details about not-found behavior or return structure, but these are less critical given the tool's simplicity and the presence of output schema absence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described, so the baseline is 3. The description's phrase 'FastBound GUID id or your externalId' adds no new meaning beyond the schema's idType enum and property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Retrieve a single acquisition' with a specific verb and resource, clearly distinguishing from sibling tools like search_acquisitions (search vs. single retrieval) and get_acquisition_item (item vs. acquisition itself).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (use when you have an acquisition id), but no explicit when-to-use vs alternatives or exclusions are provided. Sibling tools like search_acquisitions exist for broader queries, but no guidance is given on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description merely repeats 'Read-only' and adds no other behavioral information like response format, error handling, or rate limits. No value beyond annotations is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose and identifier options. It is front-loaded and concise, with no unnecessary words aside from the harmless read-only note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description adequately conveys the resource and identifiers. Given the absence of an output schema, it could mention response details, but 'Retrieve a single disposition' implies the return object, making it acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with descriptions for id and idType, including enum values. The description restates that the id can be a FastBound GUID or externalId but does not add meaning beyond what the schema already explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Retrieve' and resource 'single disposition', clearly identifying the scope by FastBound GUID id or externalId. This distinguishes it from sibling search/list tools like search_dispositions and list_disposition_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: use this to get a specific disposition when you know its id or externalId. However, it does not explicitly mention alternatives or exclusions, such as using search_dispositions when the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: dry-run behavior by default and the need to pass confirm:true to execute. The 'Write' tag also signals mutation. There is no contradiction with the destructiveHint:false annotation. The description could add more about side effects (e.g., whether the disposition is final or reversible), but the dry-run disclosure is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that deliver the essential purpose and the critical dry-run/execute distinction. Every sentence earns its place; 'Write' is a terse but clear mutation indicator. It is well front-loaded and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 17 parameters, nested objects, and no output schema, the description is too sparse. It omits return-value behavior, prerequisites (e.g., how items must be structured, whether a pending disposition is needed), and the significance of the many contact/external ID fields. The dry-run distinction is helpful but incomplete for such a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 41%, so the description must compensate, but it does not. It only mentions confirm implicitly and items generically ('inventory items'), without explaining the required type, date, or any of the many optional parameters. The schema provides descriptions for some parameters, but the description adds almost no additional parameter-level meaning beyond the confirm flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Record and commit an NFA disposition for inventory items.' This distinguishes it from sibling disposition tools like dispose, dispose_destroyed, and dispose_theft_loss by specifying 'NFA'. The added note about dry-run and confirm further clarifies the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use—NFA dispositions—and critical operational guidance ('Dry-run by default; pass confirm:true'). However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a full 5. It implies rather than explicitly contrasts with sibling dispose tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it states that dry-run is the default and that confirm:true is required to execute, making the mutation behavior explicit. The trailing 'Write.' reinforces that this is a write operation. While it doesn't detail consequences or reversibility, the dry-run/confirm mechanism is a strong transparency feature that goes beyond the sparse annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: four short sentences totaling under 30 words. It front-loads the main purpose, then adds essential safety and validation details. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 10 parameters and no output schema, the description provides only minimal context. It covers the core action and the critical dry-run behavior but does not explain what happens on commit (e.g., if items become unavailable), what the response contains, or how this tool relates to other disposition tools. The schema covers 60% of parameters, but the description alone leaves gaps in overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for key parameters: 'Provide discovery date and incident numbers' likely maps to theftLoss_DiscoveredDate and the incident number fields, and 'pass confirm:true' clarifies the confirm parameter. However, with 60% schema coverage and 10 parameters, the description does not fully compensate for the remaining undocumented parameters, and it slightly conflates the required 'date' with the discovery date.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb-resource pair: 'Record and commit a theft/loss disposition for inventory items.' It clearly identifies the tool's unique scope (theft/loss) and distinguishes it from sibling tools like dispose_destroyed and dispose_nfa. The additional mention of discovery date and incident numbers further refines its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for theft/loss dispositions and provides a clear usage hint about dry-run vs. confirm. However, it does not explicitly state when to use this tool versus alternatives like dispose, dispose_destroyed, or dispose_nfa. The guidance is inferred from the name/title rather than articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Read-only' adds no new safety information. It does add the scoping criterion (associated with Form 4473), but no other behavioral context like pagination behavior or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus 'Read-only.' It is front-loaded with the action and resource, contains no filler, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered-list tool with two optional pagination parameters described in the schema and read-only annotations provided, the description is sufficiently complete. It conveys the essential purpose without needing to explain return values, as no output schema exists but the expected behavior is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (skip and take) with descriptions, achieving 100% schema_description_coverage. The tool description itself provides no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing dispositions with an associated ATF Form 4473. The verb 'List' plus the specific filter distinguishes it from sibling tools like search_dispositions or list_disposition_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description and name—use when needing dispositions tied to Form 4473—but there is no explicit guidance on when not to use it or what alternatives exist (e.g., search_dispositions for broader queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond annotations: it says the tool is dry-run by default and requires confirm:true to write. It also labels the operation as 'Write.' while annotations indicate non-destructive and idempotent, which is consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, with two sentences conveying purpose and the dry-run behavior. The final 'Write.' is somewhat redundant but keeps it compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with no output schema, the description covers the core purpose and the critical dry-run confirmation behavior. It does not describe the success response or edge cases like already-locked dispositions, but is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema, and the description largely restates the confirm parameter's behavior. It does not add new semantic meaning beyond the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool locks a disposition to prevent further edits, which is a specific action on a specific resource. This distinguishes it from sibling tools, none of which lock a disposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus other disposition tools. It mentions the dry-run default, which is a parameter behavior rather than usage context. There is no mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description redundantly states 'Read-only' without adding further behavioral context such as pagination behavior, result ordering, or potential performance implications. It does add minor context by describing acquisitions as 'intake events', but this does not significantly improve transparency beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences: purpose, filters, read-only note. It is front-loaded, avoids redundancy, and every sentence earns its place. No filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters and no output schema. The description provides a basic overview of what the tool does and what filters exist, but lacks information about return format, pagination defaults, and nuanced ID semantics. For a search tool with many filters, it is minimally viable but leaves clear gaps for the agent to fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 15% schema description coverage, the description must compensate. It maps filter categories (type, PO/invoice/tracking number, supplier contact, item, manufacturing flag) to several parameters, but it does not disambiguate between ID types (e.g., externalId vs itemExternalId vs acquiredFromContactExternalId) or clarify allowed values for 'type'. It adds partial value but leaves many parameter-specific details unresolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') with a clear resource ('acquisition records (intake events)') and lists filter dimensions, distinguishing it from sibling tools like get_acquisition (single-record retrieval) and search_dispositions/search_items (other resources). It is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use the tool (searching acquisition records) and what filters are available. However, it does not explicitly mention alternatives (e.g., get_acquisition for a single record) or state when not to use it, missing the top-tier 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the 'Read-only' suffix is redundant. The description adds context about what records are included (firearms leaving inventory) and filter categories, but it does not disclose pagination behavior, result limits, or consequences of the open-world hint. This is marginal added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the primary action and scope. No word is wasted; the filter list and read-only note each add distinct value. It is appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and no output schema, the description gives a high-level overview of filter categories but leaves out details like pagination via skip/take, specific parameter semantics, and return structure. It is a sufficient summary for a search tool but not fully complete for an agent to invoke with all possible filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists filter categories (type, TTSN/OTSN, PO/invoice/tracking, recipient contact, item) that map to several parameters, but it does not explain all 16 parameters. With only 19% schema coverage, the description partially compensates by providing category-level meaning, but it omits parameters like isManufacturingDisposition and include4473.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches disposition records and specifically enumerates the types (sales, FFL transfers, theft/loss, destroyed), which distinguishes it from sibling tools like get_disposition or list_disposition_items. The verb 'search' combined with the resource and filter categories provides a clear, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for finding/filtering disposition records, and the 'Read-only' note signals it is safe to call. It does not explicitly name alternatives or exclusions, but the context of sibling tools and the focus on search/filter makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false. The description adds 'Executes directly' (synchronous execution) and 'Write' (mutation) which are behavioral details not present in the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three short statements) and front-loads the action. 'Executes directly' and 'Write' are somewhat fragmented but do not waste words, so it earns above-average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description explains the action and the required state ('pending disposition'), but it does not cover return values, error expectations, or prerequisites like the existence of the contact/disposition. Annotations provide some safety context, but the description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds no additional parameter semantics beyond what the schema already states for 'id' and 'contactId', so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Assign' and clearly identifies the resource ('existing recipient/buyer contact') and target ('pending disposition'). This distinguishes it from sibling tools like attach_acquisition_contact by explicitly naming the disposition context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pending disposition' provides clear context for when to use this tool, implying it should be used for dispositions that are not yet committed. It does not explicitly name alternatives or exclusions, but the disposition-specific wording makes the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=false in annotations, the description adds meaningful behavioral context: the draft is pending, has no ATF effect until committed, and executes directly. This goes beyond the annotation. It does not mention auth or rate limits, but the added context is valuable. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, using three sentences to convey purpose, behavior, and workflow. However, the trailing 'Write.' is extraneous and adds nothing, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 16 parameters, nested objects, no output schema, and minimal annotations, the description is incomplete. It fails to explain the many optional fields, the contact object semantics, or the relationship between inline items and add_disposition_items. The workflow guidance is useful but leaves major gaps for an AI agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description should compensate by explaining key parameters. It does not explain requestType, date, contact vs contactId, items structure, or any other parameter options. The only parameter-related hint is the workflow mention of 'add_disposition_items', which actually conflicts with the schema's inline 'items' property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a PENDING (uncommitted) disposition draft') with a specific verb and resource, and distinguishes it from siblings by highlighting its pending, uncommitted nature. It also positions it within the workflow (add items, then commit).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given on when to use this tool versus alternatives: 'Add items with add_disposition_items, then finalise with commit_disposition.' It also notes that it 'executes directly' because there is no ATF effect until committed, clarifying the intended usage sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds the key behavioral detail that the file is returned base64-encoded. This is valuable context about the return format. However, it does not mention error handling, permissions, or size limits, but the annotations already cover the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by 'Read.' Every word earns its place; it is extremely efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter, read-only tool with an output format specified, the description is nearly complete. It does not mention when to use the tool vs. alternatives, but given the straightforward nature and openWorldHint annotation, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, documenting attachmentId as a GUID. The description merely restates 'by its id' without adding additional semantics. Baseline of 3 is appropriate since the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download'), the target resource ('an attachment file'), and the required input ('by its id'). It is specific enough to distinguish from sibling download tools like download_bound_book or download_multiple_sale_report, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for downloading attachments by ID, but it does not explicitly state when to use this tool versus alternatives (e.g., other download tools) or provide any exclusions. The context is self-evident but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the 'Read' note adds little. However, the description adds a useful behavioral detail: the file is returned base64-encoded, which is not captured in annotations or schema. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action and resource, and contains no redundant or filler text. Every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple download tool with two described parameters and read-only annotations, the description covers the essential aspects: what is downloaded, how to identify it, and the output format. No output schema exists, so the base64 return note is valuable. Minor gaps like error handling or file size limits are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well-described as GUIDs for the report and attachment. The description reinforces their roles ('report id' and 'attachment id') but doesn't add new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Download') with a precise resource ('Multiple Sale report attachment') and identifies the form numbers (ATF Form 3310.4/5300.9), clearly distinguishing it from sibling download tools like download_attachment or download_4473.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for multiple-sale report attachments by naming the resource, but it does not explicitly state when to use this tool versus alternatives like download_attachment. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'Read-only,' which is redundant with the annotation. It discloses no additional behavioral traits such as error handling, authorization requirements, or side effects. Since annotations cover the safety profile, the description's contribution is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences ('Retrieve a single item within an acquisition. Read-only.') that are front-loaded with the action. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read-only fetch with no output schema, the description is adequate. It doesn't describe return values or not-found behavior, but these are arguably unnecessary for such a straightforward tool. It lacks explicit sibling differentiation, but the scope is clear. Slightly below a 5 because it misses the chance to note that acquisitionItemId is scoped by id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters (id and acquisitionItemId) are fully described as GUIDs. The description adds no additional meaning about parameter types, formats, or relationships beyond what the schema already provides. Baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a single item') and the resource ('within an acquisition'), distinguishing it from sibling tools like get_acquisition (retrieves entire acquisition) and get_item (retrieves an item outside acquisition context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you have an acquisition ID and item ID and need a specific item), but it does not explicitly mention alternatives or exclusion scenarios. For example, it doesn't say 'use get_item for items not in an acquisition,' so it lacks the 'when-not' guidance seen in higher-tier examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds 'Read-only' and the use case of discovering allowed values. However, it does not elaborate on openWorldHint (e.g., lists may be extensible) or describe return format/pagination, so it adds limited behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core verb+resource, then a concrete usage tip. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, the description covers purpose, usage, and the enumeration of allowed list types. No output schema exists, but the reference-list nature and param enum provide enough context. A deeper note on return format would push it to 5, but it is not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'list' parameter fully documented via an enum and description. The description mentions some example values (caliber, manufacturer, etc.) but does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Return one of FastBound's reference lists (allowed values)' with a specific verb and resource. It distinguishes this from sibling tools by framing it as a lookup/validation helper, not a CRUD operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this to discover valid ... values before creating or editing records.' This tells the agent when to invoke the tool. No alternatives or when-not scenarios are mentioned, but the read-only nature and use-case are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behavioral traits beyond the annotations: dry-run by default, requiring `confirm:true` to execute, and that it is a write operation. It does not disclose reversibility or audit details, but the annotations are minimal and the description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding value: core action, required inputs, and dry-run/commit behavior. It is front-loaded and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and minimal annotations, the description covers the core action and dry-run behavior but omits expected return values, side effects, and the relationship between `date` and `destroyed_Date`. It is adequate but not fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description must compensate. It mentions 'destruction date, description, and witnesses', mapping to `destroyed_Date`, `destroyed_Description`, and `destroyed_Witness1/2`. However, it does not clarify the distinction between the required `date` and optional `destroyed_Date`, nor explain `note` or `externalId`, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Record and commit a destroyed disposition for inventory items', specifying the verb, resource, and specific disposition type. It distinguishes from sibling tools like `dispose` or `create_pending_disposition` by explicitly targeting destroyed dispositions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Provide destruction date, description, and witnesses' and 'Dry-run by default; pass confirm:true'. However, it does not explicitly mention when to use this tool over alternatives or when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by specifying the return format ('base64-encoded') and the 'completed' status of the form. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the key purpose front-loaded. Every word adds value, and the trailing 'Read.' is a concise reinforcement of the read-only nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only download tool with one parameter and no output schema, the description adequately covers purpose, return format, and operational scope. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the only parameter fully described as 'GUID of the 4473.' The description adds minimal extra meaning ('by its id'), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Download' with a clear resource: 'completed ATF Form 4473 PDF' and the method 'by its id.' This distinguishes it from sibling download tools like download_attachment or download_bound_book by naming the exact form type and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the PDF of a completed 4473 but does not explicitly state when to use this tool over alternatives or provide exclusions. It lacks the explicit alternative naming seen in top-tier examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the description does not need to restate safety. It adds 'Executes directly,' which implies immediate effect without additional steps, and labels the operation as 'Write,' adding some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core purpose. The final 'Write' is somewhat redundant since 'Set' already implies mutation, so it does not earn its place fully, keeping it from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with 4 parameters (one optional) and no output schema, the description covers the essential purpose, the pending-disposition context, and immediate execution. It does not explain return values or failure behavior, but these are not critical given the tool's simplicity and schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented structurally. The tool description adds no parameter-specific meaning, which matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set the sale price of an item on a pending disposition,' which uses a specific verb, resource, and scope. This distinguishes it from sibling tools like update_disposition or add_disposition_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on a pending disposition' provides clear context for when the tool applies, but it does not explicitly state exclusions or name alternative tools. It implies not for committed dispositions but lacks a direct when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description redundantly states 'Read-only.' The description adds little beyond the annotation, though it clarifies the flexible identifier behavior (GUID vs externalId), which is a useful but minor behavioral nuance. No side effects or edge-case behaviors are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the action, resource, and identifier options, followed by a clear safety qualifier. Every word contributes meaning, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is complete. It identifies the resource, the required parameter, and the read-only nature. The return object is obvious for a 'get contact' operation, and the lack of an output schema does not create ambiguity. Sibling tools do not conflict with this focused operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with detailed descriptions for both parameters, including the idType enum. The description repeats the schema's distinction between GUID and externalId but does not add new semantic value beyond what the schema already communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and identifies the resource ('a single contact') with precise lookup keys (FastBound GUID id or externalId). This clearly distinguishes it from sibling tools like search_contacts or list_smartlists, which handle broader queries or lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: fetch one contact when you know its identifier. It does not explicitly name alternative tools or exclusions, but the singular focus and ID-based lookup make the intent obvious. Sibling context further clarifies when to use this versus bulk or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds the behavioral detail that the id parameter can be either a FastBound GUID or an externalId, which goes beyond the schema. However, it does not disclose error handling or not-found behavior, so it only partially adds context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 17 words, front-loaded with the main action and resource. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, 1 required), complete schema documentation, and readOnlyHint annotation, the description sufficiently covers the tool's purpose and usage. No output schema is needed for a simple get-by-id tool, and the description states exactly what is retrieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented. The description summarizes the purpose of the id and idType parameters ('by FastBound GUID id or by your externalId'), but adds no further semantics like value formats or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and identifies the resource as 'a single firearm record', with explicit lookup methods ('by FastBound GUID id or by your externalId'). It clearly distinguishes this from sibling search tools like search_items, which are for broader queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when a single known identifier (either FastBound GUID or externalId) needs to be fetched. It does not explicitly name alternatives, but the context of sibling tools like search_items suggests a clear usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose idempotency and non-destructive behavior. The description adds 'Executes directly' and 'Write', giving extra context about immediate side effects and mutation intent. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three short sentences, with the purpose front-loaded. Each sentence adds value: 'Executes directly' and 'Write' signal behavioral traits beyond the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema, the description covers the essential purpose, target state (pending acquisition), and immediate execution behavior. Schema covers parameter details. It lacks explicit alternative guidance but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides, but it doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Assign') with a clear resource ('existing supplier contact') and target ('pending acquisition'), distinguishing it from sibling tools like attach_disposition_contact and set_item_acquisition_contact. It states exactly 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates the tool is for pending acquisitions, providing context for when to use it. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring idempotentHint=true and destructiveHint=false, the description adds context about the state change ('mark as physically verified') and optional location update. It does not contradict the annotations. The description could mention partial-failure behavior (rollbackPartial), but that is detailed in the parameter schema, so the added value is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus the word 'Write.' It is front-loaded with the core action and contains no filler. Every word contributes to understanding the tool's purpose and mutation type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the descriptive schema (6 fully described parameters) and clear annotations (idempotent, non-destructive), the description is a sufficient entry point. It adds the 'cycle count' context and signals mutation. There is no output schema, but for a write operation like this, return values are not essential for invoking it. A 5 would require more detail about the response or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has its own description. The tool description only hints at the location parameter ('optionally updating their location') without adding new meaning beyond what the schema already provides. Therefore, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('mark'), a specific resource ('serial numbers'), and a clear context ('during a cycle count'). It also explicitly states 'Write' to signal mutation, which distinguishes it from read-only siblings like get_account and search_items. The purpose is unambiguous and distinct from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context ('during a cycle count') that indicates when this tool is appropriate. However, it does not explicitly state when not to use it or name alternative tools. There is no obvious sibling alternative, so the context is sufficient for a 4 but not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite destructiveHint=false, the description discloses meaningful behavioral traits: it is a write operation ('Write.'), irreversible ('point of no return'), and dry-run by default with a confirm flag to execute. This goes beyond the minimal annotation and tells the agent the safety model (preview first, then commit). It does not mention permissions or rate limits, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, with the core action and key caveat in the first sentence. Every clause earns its place — 'Dry-run by default' and 'pass confirm:true to commit' are critical. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no nested objects, the description covers the essential purpose, the dry-run default, the confirmation step, and the irreversible nature. The schema fills in parameter details. It does not explicitly describe return values or what happens post-commit, but given the simplicity and rich schema, the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all three parameters, including id, confirm, and auditUser. The description merely restates the confirm behavior ('pass confirm:true to commit') which is also in the schema's confirm description. No additional semantic meaning is added beyond the schema, so it receives the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Commit a pending acquisition to the A&D book' — a specific verb and resource that clearly differentiates from siblings like create_pending_acquisition or commit_disposition. The em-dash 'point of no return' reinforces the finalizing nature. No ambiguity about 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finalizing a pending acquisition: it references 'pending acquisition' and explains the dry-run default with a confirm flag to actually commit. This gives clear context for when to use it, though it does not explicitly name alternatives or state exclusions. Sibling names make the niche clear, but the description itself stops short of explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide destructiveHint:false, so the description carries the transparency burden. It discloses multiple side effects (Multiple Sale report, FFL acquisition auto-creation) and the dry-run vs. confirm execution model, which is valuable. It does not contradict the destructiveHint annotation and adds significant context beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core action in the first phrase. The sentences about side effects and dry-run behavior are important and concise. The final 'Write.' is a slight redundancy that prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and only minimal annotations, the description provides sufficient context for correct invocation: it identifies the input as a pending disposition, details the key side effects, and explains the confirmation guard. The dry-run default and regulatory reporting mentions make this reasonably complete for a non-trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have detailed schema descriptions, giving 100% coverage. The description adds little beyond the schema—it restates the confirm behavior and mentions otherTransfereeEmails for FFL transfers, but does not clarify the parameters further. Baseline 3 is appropriate because the schema already provides the necessary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Commit a pending disposition to the A&D book') and distinctively positions it as the finalizing step, clearly distinguishing it from sibling tools like create_pending_disposition, update_disposition, and delete_disposition. The 'point of no return' phrasing and side-effect mentions make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use the tool: after a pending disposition exists, to finalize it. It provides concrete operational guidance (dry-run by default, pass confirm:true) and warns of irreversible consequences. It does not explicitly name alternative tools or exclusion scenarios, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include destructiveHint=false, so the description adds value by stating 'Write', 'Executes directly', and the dedup behavior via headers. This goes beyond the minimal annotation coverage, though it omits details like authorization or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the action and resource, and every sentence conveys meaningful information. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 25-parameter write tool with no output schema, the description covers the core type selection, direct execution, and dedup behavior. It does not mention response format or error conditions, but given the tool's complexity, the provided context is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 32% schema coverage, the description compensates partially by grouping parameters by contact type (fflNumber, organizationName, firstName/lastName, premise address fields). It does not explain many other parameters like auditUser, businessType, or externalId, which remain unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create), the resource (contact), and the three supported types (FFL, organization, individual). It distinguishes this from sibling tools like update_contact and merge_contacts by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on which parameters to use for each contact type, and notes that execution is direct (not an A&D record). It lacks explicit alternatives or when-not-to-use guidance, but the type-specific field mapping is a strong usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive (destructiveHint: true), and the description reinforces this with 'Write.' It further discloses that the tool is dry-run by default and requires confirm:true to execute, which is important behavioral context beyond the annotation. This makes the destructive nature and safety mechanism clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the core purpose, then the dry-run/confirm caveat, and a terse 'Write.' marker. Every sentence adds distinct value and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no output schema, the description covers the essential behavioral contract: the action, the target scope ('pending disposition'), the dry-run default, and the confirm flag. It does not describe return values or failure modes, but the schema and annotations already carry substantial detail, making this adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description only mentions the item GUID and confirm behavior, which are already detailed in the schema properties. The description adds no meaningful parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Remove') and a specific resource ('an item from a pending disposition'), and further specifies the identifier type ('inventory item GUID'). This clearly differentiates it from sibling tools like delete_disposition (removes the whole disposition) and add_disposition_items (adds items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it removes an item from a pending disposition only, and instructs to pass confirm:true to actually execute, implying a safe dry-run default. It does not explicitly mention alternatives or when-not-to-use, but the pending-disposition scope is stated and the confirm requirement clarifies the usage workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by explicitly stating 'Read-only' and disclosing the return format: 'Returns a page of items plus the total record count.' It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by filters and return info. No wasted words, highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 28-parameter search tool with no output schema, the description gives a solid high-level overview: purpose, main filters, and response shape. It relies on the schema for parameter details, which is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), but the description lists many key filter fields: serial, manufacturer, model, type, caliber, status, date ranges, TTSN/OTSN, and 'and more.' It doesn't fully compensate for all 28 parameters, but it conveys the main searchable dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the firearm inventory (the A&D book)' with a specific verb and resource. It is distinct from sibling search tools like search_acquisitions and search_dispositions by naming the inventory context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: this searches items in the A&D book and lists filterable fields. It does not explicitly name alternatives or state when not to use it, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a write operation ('Write') and adds a behavioral guarantee ('without touching other fields'). The annotations already provide idempotentHint and destructiveHint, so the description complements rather than contradicts them, giving context beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and scope. The additional 'Write.' is concise and avoids unnecessary detail, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with only 3 parameters, no output schema, and annotations covering safety, the description is largely complete. It clearly states what is updated and the scope, but could arguably mention response format or error behavior; however, that is not essential for this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema already states, but it does confirm the purpose of 'externalId' as a link to the system's record.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set or change') and clearly identifies the resource ('the externalId of an item') and scope ('only', 'without touching other fields'). This distinguishes it from the broader update_item sibling by emphasizing the partial update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without touching other fields' provides clear context that this should be used when the external ID is the only field to update, implying that other fields should be left untouched. It does not explicitly name an alternative like update_item, but the guidance is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds valuable behavioral context: the tool is a dry-run by default and only mutates when confirm is true. The 'Write.' label reinforces that it is a mutating action. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences clearly front-load the purpose, then state the dry-run/apply mechanism and mutability. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description covers the core action, outcome, and dry-run/confirm safety behavior. It does not describe what the dry-run preview returns, but the schema's confirm description mentions a preview, so this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters. The only parameter-related behavior mentioned ('pass confirm:true to apply') restates the schema's confirm description; no additional meaning is added for id, note, or auditUser.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair ('Reverse a disposition') and states the outcome ('return a disposed firearm to available inventory'). This clearly distinguishes it from sibling tools like dispose, delete_disposition, and create_pending_disposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operational guidance: dry-run by default with confirm:true to apply, which tells the agent how to safely use the tool. However, it does not explicitly mention when to avoid this tool or name alternative tools, so it lacks the full 'when/not' structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description redundantly states 'Read-only'. It does add useful context about email validity for the header, but it doesn't disclose additional behavioral traits such as pagination, result ordering, or whether the list is exhaustive, which would be valuable given openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action, followed by a specific use case. No wasted words; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description adequately covers purpose, usage, and safety profile. The annotations supply behavioral bounds, and the description supplies the practical context needed to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers 100% of the parameter surface. The description adds meaning beyond the empty schema by clarifying that the returned data contains valid emails needed for a specific header, which is the kind of semantic value expected for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('List users') and clearly identifies the account scope. It also states a distinct downstream purpose (finding valid emails for the X-AuditUser header) that differentiates it from sibling list tools like list_smartlists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: to find valid emails for the X-AuditUser header required on write operations. There are no exclusions or named alternatives, but this is clear, contextual guidance for a simple read-only listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations declare idempotentHint=true and destructiveHint=false, the description adds critical nuance well beyond them: read-merge-write semantics, dry-run by default, confirm:true to apply, and preview of the merged body. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with verb and resource. Every sentence earns its place: purpose, merge behavior, and execution model. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 28-param update tool with no output schema, the description covers the core behavioral contract (merge, dry-run, confirm) and safety profile. It doesn't enumerate field-level details, but the merge statement covers all fields collectively. Minor gap: no mention of special parameters like auditUser.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, so the description should compensate for 28 mostly undocumented parameters. It does not add meaning to individual fields (e.g., mpn vs upc vs sku); it only says 'fields' generically. The confirm parameter is already explained in the schema, not in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Edit' and resource 'existing firearm record', clearly distinguishing this update tool from create/delete/search siblings. It also states the merge behavior, which reinforces that this is a partial-update tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context—use when editing an existing firearm record—and explains the dry-run/confirm workflow. It doesn't explicitly name alternatives (e.g., update_acquisition for acquisition records), but the scope is unambiguous enough for intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the minimal annotations: 'Has no ATF effect until committed, so it executes directly (no dry-run).' This explains the immediate execution and non-committal nature, which is valuable because destructiveHint only indicates non-destructiveness. The 'Write.' label further signals a write operation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, each earning its place: purpose, contact requirement, behavioral nuance, and workflow. No redundant or filler content. Information is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 params, nested objects, no output schema), the description covers the essential workflow and key constraints. It explains how the tool fits into the larger acquisition process. However, it doesn't mention the response type or any details about the nested items structure, leaving some gaps for a highly complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 54%, the description compensates by clarifying the crucial contact requirement: 'A supplier contact is REQUIRED (contactId, contactExternalId, or inline contact).' It also explains the role of the items parameter by deferring to add_acquisition_items. This adds meaning beyond the schema, though other parameters like date and note are not individually explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Create a PENDING (uncommitted) acquisition draft.' It distinguishes itself from sibling tools like create_pending_disposition and commit_acquisition by emphasizing the draft/uncommitted state and the subsequent workflow (add items, commit). The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it explains the prerequisite (supplier contact required), the behavior (no dry-run), and the workflow ('Add items with add_acquisition_items, then finalise with commit_acquisition'). It does not explicitly mention alternatives or when not to use it, but the workflow context is strong enough to guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already flags destructiveness, and the description adds important behavioral detail: the dry-run default and the need to pass confirm:true for actual execution. This goes beyond the annotation by explaining the safety mechanism, which is crucial for an agent to use correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences (plus a final clause) that front-load the purpose, then behavior, then destructiveness. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter delete tool with no output schema, the description covers the core purpose, the pending-only scope, and the dry-run safety behavior. It does not mention what happens to related records or the return format, but given the tool's simplicity and the schema's completeness, it is sufficiently contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes all three parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the default dry-run behavior for confirm, which is not explicitly stated in the schema's description ('Omit or false returns a DRY RUN preview'), but the description's phrasing reinforces and clarifies the default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a PENDING (uncommitted) acquisition draft' with a specific verb and resource, clearly distinguishing it from sibling tools like delete_acquisition_item and delete_disposition. It also clarifies that only pending acquisitions are affected, which differentiates it from operations on committed acquisitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for pending/uncommitted acquisitions only, providing clear context about when to use it. However, it does not explicitly name alternative tools or state 'do not use for committed acquisitions', so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses the critical dry-run default and the confirmation requirement, which significantly reduces the risk of accidental destructive actions. This is valuable behavioral context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with verb and scope, then a vital safety note. Every word earns its place—no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, scope (pending acquisition), and the dry-run/confirmation safety mechanism, which is sufficient given the simple parameters and annotations. It doesn't describe return values, but no output schema exists and the schema fills parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's mention of 'confirm:true' mirrors the schema's confirm parameter description, adding no new meaning. Other parameters are fully handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' with resource 'item from a pending acquisition', clearly distinguishing it from siblings like delete_acquisition (which deletes the whole acquisition) and update_acquisition_item. Stating 'pending acquisition' provides precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs 'Dry-run by default; pass confirm:true', giving clear usage for safe execution. However, it doesn't mention when not to use or compare with alternatives like delete_acquisition, so it's not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by disclosing the dry-run default and the need for confirm:true. This is critical safety information not present in the annotations, providing the agent with accurate execution semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and scope. Every phrase earns its place, and the destructive warning is integrated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool, the description covers the essential behavior (pending scope, dry-run, confirm). However, with no output schema, the dry-run preview's return format is undisclosed, a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description merely echoes the confirm behavior already fully described in the schema, adding no new meaning for id or auditUser.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('disposition draft'), and the scope ('PENDING (uncommitted)'), distinguishing it from committed dispositions. It also differentiates from sibling tools like remove_disposition_items by focusing on the entire draft rather than individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use for pending/uncommitted drafts, dry-run by default, and confirm to execute. It implies when not to use (committed dispositions) but does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral details beyond the annotations: it commits a regulated record, defaults to dry-run, requires confirm:true to execute, and notes that FastBound may auto-create the receiving FFL's acquisition reported via headers. It does not fully describe return structure or all side effects, but with only destructiveHint=false provided, this is strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words: purpose, FFL-specific guidance, and the critical dry-run/confirm behavior. Front-loaded with the core action, then details. The final 'Write.' is terse but acceptable as a concise safety hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 17 parameters, nested objects, and no output schema, the description covers the essential workflow: item GUID references, FFL transfer setup, and dry-run/commit semantics. It does not explain return values or all parameter interactions, but the schema covers individual fields, and the description provides enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 59%, so the description partially compensates by explaining key parameters: items reference inventory GUIDs, requestType=Regular for FFL transfers, otherTransfereeEmails for recipient FFL users, and confirm controls dry-run vs execution. These clarifications add meaning not obvious from the schema alone, though many nested contact fields remain only schema-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records and commits a disposition in one step, using 'Record a disposition and commit it in one step' with a specific verb and resource. It names examples (sale, FFL transfer) and contrasts with the two-step pattern implied by sibling tools like create_pending_disposition and commit_disposition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: FFL transfers should set requestType=Regular and otherTransfereeEmails, and the tool is dry-run by default until confirm:true is passed. It does not name a specific alternative tool for two-step disposition scenarios, but the 'one step' phrasing and sibling names make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond the annotations: output is base64-encoded, large exports are summarised, and an auditUser email is required. It also states 'Read', reinforcing the readOnlyHint. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each providing distinct information: what the tool does, the auditUser requirement, and the return behavior. No filler or redundancy; front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only download tool, the description covers the essential details: purpose, required input, and return format. The only gap is that 'summarised' is vague and the nature of the returned file (e.g., file type) is not specified, but this is minor given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes auditUser (email format, override behavior, active user requirement), and the description largely restates these facts. It adds the general requirement that an auditUser email is needed, but no significant new parameter-level context. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: generating and downloading the A&D bound book export. It uses a specific verb ('Generate and download') and resource ('A&D bound book export'), distinguishing it from sibling download tools like download_4473 or download_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first sentence establishes when to use this tool. It also mentions the need for an auditUser email, giving context on prerequisites. However, it does not explicitly name alternatives or state when not to use it, though the resource-specific wording makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description supplements the readOnlyHint annotation by specifying exactly which properties are returned (number, name, items in inventory, owner) and by framing the tool as a connectivity/credential check, which implies it performs a network call and validates auth. This goes beyond the generic read-only annotation and provides actionable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with two useful sentences and a third that restates the read-only nature. While 'Read-only' is somewhat redundant with the annotation, it doesn't significantly bloat the description. Overall, it's efficient but not perfectly zero-waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description sufficiently covers the return content and the use case. It tells the reader what to expect (account properties) and when to use it, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides no parameter information. The description adds context about what the tool returns, and since there are no parameters to document, the description appropriately stays silent. The baseline for 0 parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read FastBound account properties and settings' with a specific verb, resource, and a list of example properties. This distinguishes it from sibling tools like get_item or get_acquisition by focusing on the account-level resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage context: 'Useful as a connectivity/credential check,' which tells the agent when to invoke this tool. It doesn't explicitly mention alternatives, but for an account info read, no alternatives are needed. The 'Read-only' note further clarifies it should be used for non-mutating checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal openWorldHint annotation, the description reveals that create/update/delete are write operations requiring FASTBOUND_ALLOW_WRITES, while list_events and get are reads. This gives the agent auth expectations and operation type awareness. It does not mention permanence of deletes or error details, but the core side-effect profile is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with high information density. It front-loads the full operation list, then condenses action semantics and create requirements into one clause. No redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters and no output schema, the description covers all action enum values and the most important parameter combination for create. The schema fills in parameter details, and the description is sufficient for an agent to select and invoke the correct action. Return-value formatting is not specified, but it is not critical for this management tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes url, name, events, and auditUser, and the description adds meaning by grouping actions into read/write categories and specifying that create requires name, url, and events. This helps the agent understand the action-driven parameter requirements beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly enumerates the tool's operations: 'List available webhook event types, get a webhook, or create/update/delete a webhook subscription.' It uses specific verbs and resource, and no sibling tool covers webhook management, so it distinguishes well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly separates read actions from write actions and notes the environment requirement: 'action=list_events|get reads; create|update|delete are writes (require FASTBOUND_ALLOW_WRITES).' It also states what must be provided for create. No exclusions or alternatives are needed since this is the only webhook tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover idempotent and destructive hints. The description adds crucial behavioral details: dry-run by default, the confirm flag to actually execute, and PUT replacement semantics. It also indicates the operation is a Write, which is consistent with the absence of a readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and immediately follow with operational safeguards. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 23-parameter mutation tool, the description covers operation semantics, idempotent PUT replacement, dry-run behavior, and confirmation. It lacks return-value details or edge-case guidance (e.g., item existence validation), but the schema and description together provide enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the confirm parameter and the general 'full item' requirement, but it doesn't discuss other parameters. Schema descriptions cover 52% of properties, so the description is not the primary source for most parameter semantics. It doesn't compensate for the uncovered optional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Replace') with a clear resource ('item within a pending acquisition') and context ('corrected firearm data'), distinguishing it from sibling tools like update_acquisition or add_acquisition_items. It immediately conveys what the tool does and its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool by scoping to a pending acquisition, and explains the operational workflow: supply the full item (PUT replacement), dry-run by default, and pass confirm:true to execute. It doesn't explicitly name alternative tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal annotation (destructiveHint: false), the description discloses critical behavior: it commits a regulated record, is dry-run by default, and requires confirm:true to execute. These are essential for an agent to understand the tool's side effects without over-relying on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. The main purpose is front-loaded, followed by the most critical requirements and execution mode. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with nested objects and no output schema, the description covers the most important invocation aspects: required contact, dry-run default, and confirm flag. It doesn't explain response behavior or all params, but the schema covers many details, and the description gives enough to drive correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful parameter context by spelling out the three allowed ways to supply the required supplier contact (contactId, contactExternalId, or inline contact) and clarifying confirm's dry-run semantics. With schema coverage at 64%, this helps fill gaps and reduce misuse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Record') and resource ('Acquisition'), and clearly states it commits to the A&D book in one step. This distinguishes it from siblings like create_pending_acquisition and commit_acquisition, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes this is the 'recommended intake path' and positions itself as a one-step operation, implying when to prefer it over the create-then-commit flow. It also gives concrete requirements (supplier contact, confirm:true to execute). However, it does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description reveals crucial behavioral details: dry-run by default, the need for confirm:true to execute, and that references from the losing contact move to the winner. This adds significant transparency about the operation's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences covering purpose, key parameters, dry-run behavior, and destructive nature. Every word earns its place, and the structure front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a straightforward merge tool, given that the schema documents all parameters and the annotations cover safety. It explains the reference transfer and dry-run, though it does not describe the output format or mention auditUser, which is acceptable since the schema covers auditUser.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with clear descriptions for each parameter. The description adds extra semantic context by explicitly linking winning and losing contact IDs to the merge operation and explaining the confirm flag's purpose, going just beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: merging two duplicate contacts, with specific roles for winning and losing contact IDs. It uses specific verbs and resources, distinguishing it from sibling tools like update_contact or create_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when there are duplicate contacts) and explains the dry-run behavior. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing the read-merge-write behavior, stating that unspecified fields retain their current values (including the required status). It also reveals the dry-run default and that confirm:true is needed to execute, which is a significant behavioral trait. The final 'Write' further clarifies mutability, complementing the idempotent and non-destructive annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: three sentences that each add unique value. The first states the action, the second explains the merge behavior, and the third provides the critical dry-run/confirm workflow. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (30 parameters, 1 required), the description covers essential behavioral context: the merge pattern, dry-run default, and write confirm. It does not explain response format or edge cases like missing contacts, but those are not expected given the absence of an output schema. The description is sufficient for an agent to invoke the tool correctly in most circumstances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 37%, the description compensates by explaining the merge semantics that apply to all parameters: unspecified fields keep their current values. It specifically mentions the 'status' field behavior and confirm parameter, which are important. However, it does not describe individual fields beyond what the schema provides, and many parameters remain undocumented in either source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Edit fields on an existing contact,' clearly specifying the verb (edit) and resource (contact) and distinguishing from create operations. The read-merge-write behavior and dry-run default further differentiate it from sibling update tools by describing its specific update semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: editing an existing contact with partial field updates. It explicitly explains the dry-run default and confirm:true requirement, which is critical usage guidance. However, it does not name alternatives like merge_contacts or exclusions (e.g., when a full replacement is needed), so it stops short of fully explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses dry-run by default with confirm:true required to execute, and read-merge-write semantics so unspecified fields retain values. These are not conveyed by the annotations, adding critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding distinct value: purpose, merge behavior, and dry-run. Front-loaded with the primary action, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Captures the key behavioral nuances (pending scope, dry-run, merge semantics) and field categories. With 22 parameters, it is not exhaustive on every individual parameter but provides sufficient orientation for an agent to infer likely intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema coverage (18%), the description groups parameters into meaningful categories (type, date, note, TTSN/OTSN, PO/invoice/tracking, theft-loss/destroyed) and explains the confirm semantics. This compensates reasonably for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Edit header fields on a PENDING disposition' and lists specific fields, clearly distinguishing this from sibling tools like commit_disposition or dispose. The verb 'edit' plus 'PENDING disposition' precisely defines scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly scopes usage to 'PENDING' dispositions, implying it is not for committed or locked ones. Does not explicitly name alternatives, but the pending restriction provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint:true and destructiveHint:false, and the description adds valuable context: read-merge-write semantics ('unspecified fields keep their current values') and the dry-run default ('Dry-run by default; pass confirm:true'). This goes beyond the structured data and describes precisely how the operation behaves, including the non-destructive but mutating nature. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, followed by behavioral details. Every sentence contributes meaningful information. The final 'Write.' is slightly redundant but harmless. Overall, it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema) and minimal annotations, the description covers the essential behavior: target state (pending), merge semantics, dry-run default, and confirmation flag. It sufficiently prepares an agent to invoke the tool correctly without needing to infer hidden behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, with descriptions for id, type, confirm, and auditUser. The description compensates by listing the editable field groups ('type, date, note, PO/invoice/tracking, externalId') and explaining the merge behavior, which clarifies that unspecified parameters retain their current values. This adds semantic meaning to the parameter list even if it doesn't detail each field individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Edit header fields (type, date, note, PO/invoice/tracking, externalId) on a PENDING acquisition.' This uses a specific verb (edit) and resource (pending acquisition), and lists the exact fields affected. It also distinguishes from sibling tools like update_acquisition_item and commit_acquisition by focusing on header fields of pending acquisitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly limits usage to pending acquisitions ('on a PENDING acquisition'), giving context about when to use this tool. It does not explicitly name alternatives or exclusions, but the scope is clear enough to differentiate from related operations. The dry-run default also provides a safety guideline for testing before execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructiveHint:true, but description adds critical behavior: dry-run default, immutable audit entry, and ATF regulatory constraint. It also explicitly labels the operation as 'Destructive write,' reinforcing the annotation. This goes well beyond the annotation's minimal signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero filler: front-loaded purpose, then constraints, then execution requirement. Each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, regulatory constraints, required parameters, and the critical dry-run/confirm execution flow. Given the tool's destructive nature and 5-parameter schema, it is contextually complete; absence of output schema is not a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear descriptions, so baseline is 3. The description adds meaningful semantics by tying deleteType and deleteNote to the ATF rule and audit immutability, and by explaining confirm's dry-run behavior—value beyond the schema's property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with 'Delete a firearm record'—a specific verb and resource that distinguishes this from sibling delete tools (e.g., delete_acquisition_item). It further narrows scope by noting ATF permits deletion only for Duplicate or Error.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states dry-run is default and confirm:true is required to execute, giving clear when-to-use guidance. The ATF restriction (only Duplicate or Error) functions as a when-not-to-use condition, and the required deleteType/deleteNote parameters are highlighted, though no alternative sibling tool is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fastbound-mcp MCP server](https://glama.ai/mcp/servers/xuanji86/fastbound-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xuanji86/fastbound-mcp)

Score Badge

Copy to your README.md:

[![fastbound-mcp MCP server](https://glama.ai/mcp/servers/xuanji86/fastbound-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xuanji86/fastbound-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xuanji86/fastbound-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server