Skip to main content
Glama

price_manipulation_test

Test server-side price validation by sending manipulated price values like 0, 1, and -1 to identify vulnerabilities in e-commerce systems.

Instructions

Test client-side price manipulation by sending modified price values.

Sends price=0, price=1, price=-1, and negative quantity variants to check if the server validates prices server-side.

Returns: {"results": [{"test_case": str, "payload": str, "status": int, "length": int, "accepted": bool, "snippet": str}]}.

Side effects: May add items to cart or create orders at manipulated prices.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL that processes the purchase/cart action
price_paramYesParameter name for the price, e.g. 'price', 'amount', 'total'
cart_endpointNoSeparate cart/checkout endpoint to verify final price after manipulation
extra_paramsNoAdditional form parameters, e.g. 'productId=1&quantity=1'
auth_cookieNoSession cookie for authenticated requests
content_typeNoRequest content type: 'form' or 'json'
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes what the tool does (sends specific test cases), what it returns (detailed results structure), and importantly discloses side effects ('May add items to cart or create orders at manipulated prices'). This covers the mutation risk and potential consequences 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 efficiently structured with three focused sentences: purpose statement, return value specification, and side effect disclosure. Every sentence earns its place by providing essential information without redundancy or 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 security testing tool with 6 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the tool's purpose, what it tests, the return format, and critical side effects. The main gap is that without an output schema, the description doesn't fully explain the meaning of each field in the results array (e.g., what 'accepted: bool' specifically indicates).

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 100% schema description coverage, all 6 parameters are already documented in the input schema. The description doesn't add any additional parameter semantics beyond what's in the schema descriptions. It mentions 'price=0, price=1, price=-1, and negative quantity variants' which relates to the tool's behavior but doesn't provide parameter-specific guidance.

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 specific action ('test client-side price manipulation by sending modified price values') and the resource being tested (price validation). It distinguishes itself from sibling tools by focusing specifically on price manipulation testing rather than authentication, SQL injection, XSS, or other security tests listed.

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 ('to check if the server validates prices server-side'), which implicitly suggests it's for security testing scenarios. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools for similar validation testing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/operantlabs/operant-mcp'

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