Skip to main content
Glama

tm_create_profile

Destructive

Create a load test profile by specifying name, target URL, duration, and a RPS curve; prevents overwriting existing profiles.

Instructions

Create a new traffic profile (upsert by name — see below).

Minimum viable profile = name + target_url + duration_seconds + points. The points array is the RPS curve as a list of {"x": seconds, "y": rps} dicts — e.g. [{"x": 0, "y": 10}, {"x": 60, "y": 100}] ramps from 10 to 100 RPS over the first minute.

Optional shape knobs:

  • http_method — defaults server-side to POST if omitted.

  • request_body — string body sent on every request.

  • request_headers — JSON-encoded header list, e.g. '[{"name":"Authorization","value":"Bearer ..."}]'. Must be a string (the API accepts a string for round-tripping via the UI's form layer).

  • loop — repeat the curve indefinitely while the run is active. Defaults to False.

Not yet exposed via MCP: init / response / cleanup scripts, alert policy, callback URL, schedule. Use the web UI or the public REST API directly for those.

Name-collision behavior: the server's create endpoint is upsert-by-name, which would silently REPLACE every field of an existing profile from the request body — including advanced fields (scripts, callback, alerts) this tool doesn't expose. To prevent that data loss, this tool fails fast on collision: if a profile with this name already exists, you get a typed :class:ToolError naming the existing profile's id, and no write is attempted.

Name comparison matches the server's normalization: whitespace is trimmed and the match is per-character case-insensitive (mirrors the JDBC LOWER() lookup used by Spring Data's IgnoreCase derived query). " Existing ", "EXISTING", and "existing" all collide with an existing "Existing" profile.

ASCII names recommended. Non-ASCII names (e.g. "Straße", "İstanbul") work, but the case-fold semantics on the JVM and PostgreSQL may differ subtly from a Python-side re-implementation. The MCP guard uses str.lower() to match the server's per-character behavior (e.g. "Straße" and "STRASSE" are treated as DISTINCT names by both sides), not the more aggressive Python casefold(). For names with locale-sensitive characters, ASCII spellings give predictable cross-database behavior.

To modify an existing profile, use :func:tm_update_profile (which preserves advanced fields on partial updates). To create a fresh profile, pick a name that doesn't collide.

Concurrency caveat: the collision check is a client-side preflight against GET /profiles immediately before the POST. A concurrent POST from another session for the same user can land in the gap. For single-user MCP usage the race is sub-millisecond; for higher-concurrency scenarios the structural fix is a server-side create-if-absent contract (tracked separately).

Returns the full saved profile dict (id, name, duration, …).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
target_urlYes
duration_secondsYes
pointsYes
http_methodNo
request_bodyNo
request_headersNo
loopNo
Behavior5/5

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

Annotations already indicate destructive and non-idempotent. Description adds extensive context: fail-fast on collision to prevent data loss, server-side normalization details, concurrency race condition, return value description. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though lengthy, the description is well-structured with clear sections (minimum viable, optional knobs, name-collision, concurrency). Every sentence adds value, but could be tightened without losing clarity.

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 tool with 8 params, no output schema, and many siblings, the description covers all critical aspects: return type, upsert semantics, error handling, normalization, concurrency, and unsupported features. Provides a complete picture for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining each parameter: minimum viable set, points format with example, defaults for http_method and loop, request_headers must be string, and optional knobs. Adds meaning well 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 clearly states the tool creates a new traffic profile with upsert behavior. It explicitly distinguishes from siblings like tm_update_profile, which modifies existing profiles while preserving advanced fields, and explains the name-collision fail-fast behavior.

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?

Provides explicit guidance on when to use this tool (create fresh profile) vs tm_update_profile (modify existing). Details name-collision behavior, concurrency caveat, and recommends ASCII names. Also lists advanced features not exposed, directing to web UI/REST API.

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/trafficmorph-gif/tm-mcp'

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