Skip to main content
Glama
seer22

io.github.seer22/shturman-direct-mcp

by seer22

Create a geo segment from circles

direct_audience_segments

Create Yandex Audience geo segments from circle points with a radius in meters. Preview confirms before creation; afterwards, find the segment under a different ID in retargeting lists.

Instructions

Create ONE geo segment in Yandex Audience from CIRCLES — the one create path measured live. Polygons are recorded as knowledge only (knowledge://audience) and deliberately not implemented: their shape was never probed against the live service.

Radius is METERS, 500..10000 — the unit is proven by a two-sided probe; kilometers here would draw 500 km circles. A segment holds up to 1000 points, a 'condition' segment up to 100 (a limit bought by a live refusal), and 'condition' requires both period_length and times_quantity. Everything checkable is checked BEFORE the network, because the service's wrapper refusal masks every other complaint.

Called without a confirmation it answers a preview. After creating, the list is read back with the status — Direct sees the segment only after processed, and under a DIFFERENT number: verify by reading retargetinglists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesthe segment's name — it appears in the confirmation phrase and on the card
pointsYescircle centers: objects with latitude, longitude and an optional description. At most 1000; for geo_segment_type='condition' at most 100
radiusYescircle radius in METERS, 500..10000 — one radius for the whole segment
confirmationNothe exact phrase the preview asks for
period_lengthNodays, 1..90. condition only, required there
times_quantityNodays the person was inside, <= period_length. condition only, required there
geo_segment_typeYesmeasured list — no page names it. regular: regularly visits, lives or works (45 days); condition: was there N days over a period; last: is there now; work and home are legacy
Install Server

TDQS

A4.4/5.0
Behavior5/5

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

The description discloses substantial behavior beyond the annotations: radius units are 'proven by a two-sided probe', limits are 'bought by a live refual', and the service's wrapper refual 'masks every other complaint'. It also explains preview behavior without confirmation and that the segment appears under a DIFFERENT number after processing.

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?

The description is front-loaded with purpose and every paragraph covers a distinct concern: scope, limits/validation, and post-create verification. It is longer than minimal but the density of operationally valuable detail justifies the length, though some provenance details like 'two-sided probe' could be trimmed.

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?

Despite no output schema, the description explains what to expect: a preview without confirmation, a confirmation phrase, and a post-create readback with status and a different number. It also covers point limits, radius bounds, and condition requirements, leaving no critical gap for invoking the tool correctly.

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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces radius units in METERS and that condition requires both period_length and times_quantity, but does not add significant meaning beyond the schema's own parameter descriptions.

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 opens with a specific verb and resource: 'Create ONE geo segment in Yandex Audience from CIRCLES'. It explicitly distnguishes the tool from polygons by stating they are 'deliberately not implemented', making the tool's scope unmistakable.

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?

It gives clear context for when to use the tool: the live measured create path from circles, not polygons, and when 'condition' segments require extra parameters. It also advises verification after creation via reading retargetinglists, but does not explicitly name sibling tools as alternatives, so it falls just short of full 1.

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

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/seer22/shturman-direct-mcp'

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