Remote MCP discovery and x402 Solana USDC pay-per-call public Instagram data for autonomous agents.
Scored across 6 tools
Most tools have distinct purposes: list vs get vs recommend vs discovery URLs are clearly separated. However, build_purchase_request and get_purchase_instructions both revolve around purchasing a product and could be confused by an agent deciding which to call first.
All six tools follow a consistent snake_case verb_noun pattern (build_, get_, list_, recommend_). The convention is uniform and predictable across the set.
Six tools is well-scoped for a product-discovery-and-purchase flow. Each tool earns its place: discovery, listing, retrieval, recommendation, instructions, and request building.
The read and purchase-preparation lifecycle is well covered (list, get, recommend, discovery, instructions, build request). There is no tool for submitting/settling a transaction or checking wallet balance, though agents can send the built request themselves.
Build a ready-to-send InstaVeil x402 POST request for one paid product so an autonomous agent can purchase with minimal integration work.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Requested answer language for Veil Lens | |
| question | No | Research question for Veil Lens | |
| username | No | One public Instagram username without @ | |
| usernames | No | One to three public Instagram usernames without @ | |
| product_id | Yes | InstaVeil x402 product identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds output form ('ready-to-send POST request') and scope ('one paid product'), but does not disclose auth needs, rate limits, or the request contents, so it adds moderate value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action and purpose with no wasted words. It is appropriately sized for a tool of this simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich with examples and 100% parameter descriptions, and annotations cover safety. The description supplies the output format context ('ready-to-send POST request'). Minor gap: it does not clarify which parameters are required for which product_id values, but the schema examples compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds no parameter-specific detail beyond 'one paid product' hinting at product_id, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Build' and resource 'ready-to-send InstaVeil x402 POST request for one paid product'. This distinguishes it from siblings like get_purchase_instructions (which likely provides instructions rather than constructing a request), but no sibling is explicitly named for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains why the tool exists ('so an autonomous agent can purchase') but gives no when-to-use guidance, no prerequisites, and no alternatives. It does not tell an agent when to call this instead of get_purchase_instructions or get_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return canonical machine-readable URLs for InstaVeil x402, OpenAPI, llms.txt and human fallback.
| 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 and openWorldHint=false, so the safety and determinism profile is fully covered structurally. The description adds only the notion of 'canonical' URLs and a 'human fallback', but says nothing about auth requirements, rate limits, or stable-vs-mutable URLs. With annotations carrying the burden, a 3 is appropriate.
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 front-loaded sentence with no filler; the verb and the return payload are stated immediately and every noun 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?
With no output schema and no parameters, the description sensibly enumerates the categories of URLs that come back, which is the main thing an agent needs. It could go slightly further by describing the shape/keys of the response or stability guarantees, but it is adequate for a zero-arg discovery endpoint.
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 and the baseline is 4. Schema coverage is also reported at 100%, leaving no gap for the description to fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Return') and a precisely scoped resource ('canonical machine-readable URLs'), then enumerates exactly which URL kinds are returned (InstaVeil x402, OpenAPI, llms.txt, human fallback). This is unmistakably distinct from the sibling product/purchase tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the nature of a discovery/entry-point endpoint, and an agent can infer it should be called to bootstrap knowledge of the service. However, the description never states when to call it, whether it is a prerequisite for other tools, or any alternative — no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one InstaVeil x402 product in decision-ready form before an agent spends USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | InstaVeil x402 product identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is fully structured. The description adds the value framing ('decision-ready form before spending USDC'), which situates the tool in a paid flow, but doesn't explain what makes it 'decision-ready' (returned fields, pricing data, etc.).
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 tightly-worded sentence, front-loaded with the verb and resource. No redundancy, though terseness means some routing context is compressed into a phrase that could be clearer.
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 single-parameter read tool with complete schema/annotation coverage and no output schema, the description is roughly adequate. It orients the agent within a purchase flow but omits what the returned 'decision-ready' data contains and when to choose it over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the sole product_id parameter is enumerated with five values in the schema. The description adds nothing about the parameter. Baseline 3 applies when the schema fully documents the parameter.
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 (Get) and resource (one InstaVeil x402 product) with a clear purpose ('decision-ready form before an agent spends USDC'). It doesn't explicitly distinguish itself from the siblings list_paid_products or recommend_paid_product, but the singular 'one product' scope plus the pre-purchase framing implies the distinction.
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 phrase 'before an agent spends USDC' implies the use case (pre-purchase due diligence), but the description never names alternatives like list_paid_products (to browse) or build_purchase_request (to act). Usage context is implied rather than stated, leaving the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return exact machine purchase steps for one InstaVeil product using x402 V2 and Solana USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product to purchase |
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 covered. The description adds that the output is 'exact machine steps' with specific protocol details (x402 V2, Solana USDC), which is useful context, but it doesn't disclose return format or whether steps expire. Marginal value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-formed sentence with zero filler and the core purpose front-loaded. Nothing to trim without losing meaning.
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 1-parameter read-only tool with annotations covering safety, the description is nearly complete. It could be improved by explicitly routing to/from build_purchase_request, but it adequately tells an agent what it gets back and under what protocol. No output schema exists, so explaining the 'exact steps' return is helpful and 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?
Schema coverage is 100% with a clear enum of product IDs, so the schema carries parameter semantics. The description adds only that it operates on 'one InstaVeil product', which is already implied; no new constraints or format hints are provided. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Return) and a precisely scoped resource (exact machine purchase steps for one InstaVeil product via x402 V2 and Solana USDC). It's clearly differentiated from siblings like get_product (catalog details) and build_purchase_request (constructing a request).
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?
Implied usage is that you call this after identifying a product you want to purchase, but the description never explicitly says when to use this versus build_purchase_request, which is the nearest sibling and could confuse an agent. It names no alternative and gives no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all InstaVeil x402 products with current prices, resource URLs, input schemas and examples.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive operation with no open-world access, so safety is fully covered. The description adds that the output includes current prices, resource URLs, schemas, and examples, which is useful context about content but not about behavior like pagination, caching, or rate limits. With annotations carrying the safety profile, 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?
A single, front-loaded sentence that efficiently conveys the tool's action and returned data without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only list tool with no output schema, the description covers the essential purpose and the kind of data returned. It is nearly complete, though it could mention how the listing is ordered or whether it's exhaustive to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly implies no input is needed, and 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?
The description states a specific verb (List) and resource (InstaVeil x402 products) and enumerates what the listing includes: prices, resource URLs, input schemas and examples. It is clear what the tool does, though it doesn't explicitly differentiate itself from siblings like get_product or recommend_paid_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_product (for a single product) or recommend_paid_product (for recommendations). The description implies it's for an overview, but no explicit when/when-not is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend the lowest-friction InstaVeil paid x402 product for an agent task, with exact price and resource URL.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What the agent needs to accomplish |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds that it selects the lowest-friction option and returns exact price and resource URL, which is useful beyond annotations. However, it does not mention whether recommendations are stable across calls or how 'lowest-friction' is determined.
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, front-loaded sentence that includes the verb, resource, selection criterion, and return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a read-only recommendation tool with annotations covering safety and a fully documented parameter. It lacks sibling differentiation, but the core purpose and output are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single 'task' parameter is fully documented in the schema. The description adds no additional parameter semantics, so the baseline of 3 is appropriate when the schema does the heavy lifting.
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 (recommend) and resource (InstaVeil paid x402 product) with the outcome (exact price and resource URL). It is clear what the tool produces, but it does not explicitly differentiate itself from siblings like list_paid_products or get_product, which could also surface product listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explain when to use this tool versus alternatives such as list_paid_products, get_product, or get_purchase_instructions. It only states the purpose, leaving the agent without 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_purchase_request5 fields changedInput schema / examplesAdded value: +[
+ {
+ "product_id": "profile-snapshot",
+ "username": "instagram"
+ },
+ {
+ "product_id": "creator-compare",
+ "usernames": [
+ "instagram",
+ "natgeo"
+ ]
+ }
+]Input schema / properties / language / descriptionAdded value: +"Requested answer language for Veil Lens"Input schema / properties / question / descriptionAdded value: +"Research question for Veil Lens"Input schema / properties / username / descriptionAdded value: +"One public Instagram username without @"Input schema / properties / usernames / descriptionAdded value: +"One to three public Instagram usernames without @"get_discovery_urls1 field changedInput schema / examplesAdded value: +[
+ {}
+]get_product1 field changedInput schema / examplesAdded value: +[
+ {
+ "product_id": "profile-snapshot"
+ }
+]get_purchase_instructions1 field changedInput schema / examplesAdded value: +[
+ {
+ "product_id": "story-snapshot"
+ }
+]list_paid_products1 field changedInput schema / examplesAdded value: +[
+ {}
+]recommend_paid_product1 field changedInput schema / examplesAdded value: +[
+ {
+ "task": "Compare two public Instagram creators for a campaign"
+ }
+]build_purchase_request1 field changedInput schema / properties / product_id / enumPrevious value: -[
- "profile-snapshot",
- "story-snapshot",
- "profile-intelligence",
- "veil-lens"
-]New value: +[
+ "profile-snapshot",
+ "story-snapshot",
+ "profile-intelligence",
+ "creator-compare",
+ "veil-lens"
+]get_product1 field changedInput schema / properties / product_id / enumPrevious value: -[
- "profile-snapshot",
- "story-snapshot",
- "profile-intelligence",
- "veil-lens"
-]New value: +[
+ "profile-snapshot",
+ "story-snapshot",
+ "profile-intelligence",
+ "creator-compare",
+ "veil-lens"
+]get_purchase_instructions1 field changedInput schema / properties / product_id / enumPrevious value: -[
- "profile-snapshot",
- "story-snapshot",
- "profile-intelligence",
- "veil-lens"
-]New value: +[
+ "profile-snapshot",
+ "story-snapshot",
+ "profile-intelligence",
+ "creator-compare",
+ "veil-lens"
+]build_purchase_requestget_discovery_urlsget_productget_purchase_instructionslist_paid_productsrecommend_paid_product16 Instagram endpoints. Pay per call in USDC via x402.
x402 pay-per-call APIs over MCP, settled in USDC on Base for autonomous agents and developers.
Metered MCP tools: free discovery over MCP; per-call execution settled in USDC via x402 v2.
8 pay-per-call web intel tools over MCP. Free discovery, calls settle in USDC on Base (x402).
Add one secure layer between your agents and this server.