Peptide research for your AI: PepBank study findings plus the curo.you peptide catalog and lot COAs.
Scored across 7 tools
Each tool targets a distinct resource (products, COAs, cart, store info, PepBank research), but get_product's mention of lot reports overlaps with get_coa, and peptide_research vs search_research could be confused at a glance. Descriptions largely resolve these boundaries.
Most tools follow a clear snake_case verb_noun pattern (build_cart, get_coa, get_product, get_store_info, search_products, search_research). peptide_research deviates by omitting a verb prefix, and its name resembles search_research, a minor inconsistency.
Seven tools is well-scoped for a peptide research/storefront server, covering catalog search, product detail, COAs, cart building, policies, and research lookup without redundancy.
The surface covers the core lifecycle: discover products, inspect details/prices/stock, read COAs, build a cart, and consult policies and research. Minor gaps exist around order status/checkout follow-up and cart inspection, but agents can work around these via the external curo.you checkout.
Build a cart link from product IDs and quantities. The customer checks out and pays on curo.you.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely useful context that checkout and payment happen externally on curo.you, but it says nothing about link lifetime, whether carts persist server-side, or any rate limits. With annotations covering the basics, this is an adequate but not rich disclosure.
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 with zero waste, and the core operation is stated first. The commercial context follows and 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?
There is no output schema, so the description is the only hint that the return value is a cart link, which it conveys only implicitly. For a one-parameter, read-only tool this is mostly sufficient, but the missing return-value and link-lifetime detail leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter burden. It names both concepts ('product IDs and quantities') and maps them to the nested productId/qty fields, which is helpful. However, it gives no detail on the ID format, whether qty must be a positive integer, or how duplicate product IDs are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: build a cart link from product IDs and quantities. That is clearly distinct from sibling tools like get_product, search_products, and get_coa, though the description never explicitly contrasts itself with them. An agent can identify the operation without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence implies the usage context: this tool is for assembling a purchase that the customer completes on curo.you. It does not state when to prefer this over alternatives, any prerequisites (e.g., valid product IDs), or any cases where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read lab reports for a lot number or product.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description only needed to add context. It does not disclose that openWorldHint implies an external/third-party lookup, whether multiple reports can be returned for one product, or whether results can be empty or restricted — all behaviorally relevant for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single twelve-word sentence, front-loaded with the verb and resource. Nothing is wasted, but there is very little content to structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter descriptions, and an open-world data source, the description should say what a lab report record looks like and whether multiple reports are returned. Instead it stops at restating the title, leaving the agent under-informed about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single bare "query" string param would be opaque on its own. The description compensates by telling the agent the query should be a lot number or product identifier, but provides no format, casing, or ID conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ("Read") with a specific resource ("lab reports") and states the lookup key (lot number or product). This is clearly distinguishable from the e-commerce siblings like build_cart or search_products, though it does not explicitly name an alternative.
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?
It hints at the acceptable input (lot number or product) but never says when to prefer this tool over get_product or search_research, or what happens if no report exists. Usage is only inferable from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read product variants, prices, stock, and lot reports.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description contributes by listing the payload categories returned, but says nothing about error behavior for missing slugs, pricing visibility/authorization, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the verb front-loaded and no filler. It is appropriately compact for a simple one-parameter read tool, though it could have spent a few extra words on the slug parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup with full annotation coverage and no output schema, the description adequately conveys what comes back. The notable gap is the undocumented 'slug' parameter and the absence of any usage boundary against search_products.
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 single parameter 'slug' has zero description coverage in the schema, and the description never explains that it is the product identifier/handle. With 0% coverage the description is expected to compensate, and it does not.
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 ('Read') and resource ('product') and enumerates the data returned: variants, prices, stock, and lot reports. This clearly distinguishes a single-product lookup from the sibling search_products, though it does not name that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this versus search_products or get_store_info, nor any prerequisite or failure condition (e.g., what happens with an unknown slug). The agent must infer usage entirely from the name and the returned-field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read shipping, returns, contact, and research-use policies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the content scope (which policies are returned); it doesn't mention freshness, caching, or format of the policy text. Given rich annotations, this is an adequate but modest addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence that front-loads the verb and enumerates contents with zero filler. Nothing wasted, nothing buried.
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 zero-param, read-only lookup with no output schema, the description adequately conveys what the agent will get back (policy text categories). It could add a note on structure or breadth of the returned policies, but it's essentially complete for this complexity level.
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 to document; baseline 4 applies. The description correctly implies no inputs are needed to fetch store-level policy data.
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 (read) and enumerates the exact resource contents: shipping, returns, contact, and research-use policies. This is clearly distinct from siblings like get_product or build_cart, though it doesn't explicitly name an alternative. Purpose is unambiguous without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The enumerated policy categories imply when to reach for it (policy questions about shipping/returns/contact), but there is no explicit when-to-use or when-not statement, and no sibling is named as an alternative. Usage is inferred rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a PepBank peptide summary, main findings, sources, and credit.
| Name | Required | Description | Default |
|---|---|---|---|
| peptide | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds genuine value by enumerating the response contents (summary, main findings, sources, credit), but says nothing about what happens with an unknown peptide name or how errors surface.
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?
One front-loaded sentence with no filler, and the returned content is listed immediately. The only weakness is the unexplained term 'credit', which is jargon an agent cannot interpret without the schema.
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 annotations and no output schema, the description covers purpose and roughly what is returned. It falls short on the parameter's accepted format and on how this tool relates to search_research, both of which an agent needs to call it correctly the first time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter, so the description carries the full burden and largely fails: it never says whether 'peptide' is a name, a PepBank ID, or a sequence, nor whether matching is exact or case-sensitive. Only the implicit association with 'PepBank peptide' gives any hint about the accepted value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Read') and a specific resource ('a PepBank peptide summary, main findings, sources, and credit'), so an agent knows exactly what it gets back. It does not, however, distinguish itself from the sibling search_research, which an agent could easily confuse with this lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus search_research or get_product, and no prerequisites or exclusions. Usage is only implied by the phrase 'PepBank peptide summary', leaving the agent to infer the call context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Curo products by name, or list all products.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the useful behavioral note that omitting the query returns the full list, but says nothing about match semantics (substring/prefix), result limits, or pagination.
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?
One short sentence with both the search mode and the fallback mode front-loaded — no filler. Slightly terse given the missing detail elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description could usefully say what is returned (product summaries? IDs? full records?) and roughly how many. For a simple one-param read tool it is minimally adequate but leaves return shape and result-bound behavior undocumented.
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 single `query` parameter has 0% schema description coverage, so the description must compensate. It does partially, indicating the parameter is a product name search and that it is optional (omitting it lists all), but it leaves matching behavior and format unspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (find/list Curo products) and covers both modes of the call. It doesn't explicitly differentiate from sibling get_product for single-item lookup, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by name, or list all products' phrasing implies the two usage modes (pass a query vs. omit it), but no alternative tool is named and no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search stored PepBank findings. Read sources and credit with each result.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that each result carries sources and credit, which is useful context beyond annotations, but it says nothing about ranking, result limits, or how the cursor behaves despite the pagination parameter.
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 with no padding, and the core purpose is front-loaded. The second sentence is terse to the point of ambiguity ('credit' is undefined), so brevity costs a little clarity rather than adding it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% parameter coverage, the description carries the full burden and falls short: search scope, pagination behavior, and result shape are all unaddressed. For a search tool with a cursor parameter, this leaves real gaps an agent needs filled before calling it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both parameters: 'query' and 'cursor' are bare strings with no documentation. The description does not compensate — it never says what 'query' matches (titles, abstracts, full text) or that 'cursor' is for pagination, so an agent must guess at both semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search') and resource ('stored PepBank findings'), so the agent knows this is a retrieval tool over a findings corpus. However, it never distinguishes itself from the sibling 'peptide_research' or 'search_products', leaving overlap for an agent to guess at.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus 'peptide_research', 'search_products', or 'get_product', and no prerequisites or exclusions. The second sentence describes output content, not usage context, so the agent gets no routing guidance.
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.
build_cartget_coaget_productget_store_infopeptide_researchsearch_productssearch_researchPeptide research profiles, evidence by tier, comparisons and educational content. No dosing.
Evidence-first peptide research: summaries and comparisons from cited dossiers, linked to courses.
Cited peptide monographs, trials, safety and FDA status as JSON. Pay per call in USDC via x402.
Agent research API for 15 disease areas, plus a T1D cure lab, sourced evidence ledger and models.
Add one secure layer between your agents and this server.
