Skip to main content
Glama

pentest_ctf_cyclic

Generate De Bruijn cyclic patterns or find a crash value's offset to locate buffer overflow positions in CTF exploitation.

Instructions

De Bruijn cyclic pattern: generate one, or find a crash value's offset (mode='find').

Input Schema

NameRequiredDescriptionDefault
nNo
modeNogenerate
valueNo
lengthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden, and it only discloses the two modes. It never says what each mode returns (a pattern string versus a numeric offset), how the pointer-width argument affects generation, or what happened if a value is not found in the pattern.

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?

A single front-loaded sentence with a clear noun-then-verb structure; the generate/find split is stated early with no filler. It could still afford one clause explaining the defaults without becoming bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter, zero-coverage tool with no annotations and no output schema, the description is far too thin: an agent knows the concept but cannot construct the find-mode call or predict the return shape without guessing. The generation mode is especially under-specified regarding how n and length interact.

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

Parameters2/5

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

Schema description coverage is 0% across four parameters, and the prose only hints at 'mode' (via mode='find') and 'value' (via 'a crash value's offset'). The 'n' (pointer width) and 'length' arguments are completely undocumented anywhere, leaving half the surface unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource ('De Bruijn cyclic pattern') and both operations (generate; find a crash value's offset), which is enough to distinguish it from the neighboring encode/decode utilities. It stops short of naming which of the two modes is the default, but the dual capability is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implicitly signals two workflows and tags the lookup path with mode='find', which is more guidance than most siblings in this family offer. Nothing says when to pick this over pentest_ctf_encode or pentest_ctf_decode, or what preconditions ('a crash value') look like.

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

Deploy Server

Other Tools