Search verified Amazon FBA prep centers in the US, UK, Germany and Canada. Read-only, no auth.
Scored across 3 tools
Each tool has a clearly distinct role: summary statistics, slug-based detail lookup, and filtered search. The descriptions explicitly state when to use each and warn against misuse, leaving little room for misselection.
All tool names use consistent snake_case with predictable verb_noun structure (get_directory_summary, get_prep_center, search_prep_centers). The verbs accurately reflect the operations.
Three tools are well-scoped for a focused read-only directory: aggregate summary, search/filter, and record retrieval. No tool feels redundant or missing for the stated purpose.
The surface covers the full lifecycle for a verified directory: discovery via search, detail retrieval by slug, and aggregate coverage/verification summaries. Write operations are not applicable to this domain.
Use this when the user asks how many Amazon FBA prep centers exist in this directory, what countries or operator types are covered, or how current the verification is. Returns published counts by country and operator type.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, closed-world read, so the bar is lower. The description adds a genuinely useful caveat by specifying 'published counts', signalling that non-published entries are excluded from the totals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the usage condition is front-loaded and the return content follows immediately. Nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey the return shape, and it does: published counts by country and operator type. It does not explicitly say the verification-recency figure is returned, leaving a small gap against the stated triggers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies since no parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (returns counts) and resource (directory coverage: counts by country and operator type), plus the freshness angle. The aggregate-summary nature distinguishes it implicitly from the per-record siblings get_prep_center and search_prep_centers, though neither sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit triggering conditions: the user asking how many FBA prep centers exist, what countries/operator types are covered, or how current verification is. This maps cleanly to the aggregate intent that differentiates it from the record-level siblings, though it states no when-not-to-use or direct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to look up the full verified record for a single Amazon FBA prep center by its slug, after search_prep_centers has returned that slug. Do not guess slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The center slug exactly as returned by search_prep_centers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds that the record is "verified" and that slugs must not be guessed, but it does not describe error behavior or return contents. Against annotation-covered behavior, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with purpose and followed by the slug-source constraint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with full schema coverage and safety annotations, the description is nearly complete. It could say more about what the "full verified record" contains, but no output schema exists and the core invocation guidance is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage and already defines slug as the exact value from search_prep_centers. The description reinforces the parameter's origin and adds the constraint not to guess it, which adds practical meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: look up the full verified record for a single Amazon FBA prep center by slug. It clearly distinguishes this single-record lookup from the search_prep_centers sibling that produces the slug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it after search_prep_centers has returned a slug and warns "Do not guess slugs." That gives both the triggering condition and a clear prohibition, leaving little to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants to find, compare, or filter Amazon FBA prep centers by name, US state, country, operator type, hazmat capability, or sales-tax-free location. Returns editorially verified centers with the date each was last verified and a link to its full profile. Do not use this for general Amazon FBA policy questions, FBA fee calculations, or for finding Amazon fulfillment centers.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Case-insensitive name search. Use this when the user names a specific prep center, for example 'Urva'. Matches anywhere in the center name. | |
| limit | No | ||
| state | No | Two-letter US state or Canadian province code the user explicitly named, for example 'TX'. Do not infer this from the user's location. | |
| country | No | Country code. Defaults to all countries. | |
| operator_type | No | prep_specialist is prep only, multi_service adds adjacent services, full_3pl is a full fulfillment provider. Small Amazon-only sellers usually want prep_specialist. | |
| tax_free_state_only | No | Only centers in US sales-tax-free states (NH, OR, DE, MT, AK). | |
| hazmat_confirmed_only | No | Only centers we have positively confirmed accept hazmat. Most records are unconfirmed rather than negative, so this narrows results sharply. | |
| accepting_new_clients_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds the substantive behavior an agent couldn't infer — that results are "editorially verified," carry a last-verified date, and link to a full profile. The last-verified date is a meaningful freshness caveat that no annotation conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences: trigger, return description, then exclusions. Zero filler and the highest-value information (what it does and when it applies) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, all-optional search tool with no output schema, the description covers the return shape and the freshness signal that matter most. Remaining gaps (result ordering, whether offset pagination exists beyond limit) are minor and partly offset by the 75% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and the schema itself carries rich per-parameter guidance (e.g. the prep_specialist vs full_3pl explanation, the 'do not infer state from user location' warning). The description's filter list largely restates what the schema already documents, and it says nothing about limit or accepting_new_clients_only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb set and resource ("find, compare, or filter Amazon FBA prep centers") and enumerates the filterable dimensions, so the agent knows exactly what the tool returns. It does not name the sibling tools get_prep_center or get_directory_summary, so the boundary with those is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit triggering condition ("when the user wants to find, compare, or filter...") and three concrete exclusions: FBA policy questions, fee calculations, and Amazon fulfillment centers. It stops short of naming the alternative tool to use for a single center's details, which would have made routing unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_directory_summaryget_prep_centersearch_prep_centersVerified U.S. logistics provider search with canonical profiles, freshness, and read-only tools.
Ecommerce sourcing, inspection and fulfillment planning. Base-cost estimates; no private data.
Read-only search of a curated directory of ISO 27001, SOC 2 and compliance services.
Search B2B business lead lists by industry and location: counts, prices, masked samples. Read-only.
Add one secure layer between your agents and this server.
