Skip to main content
Glama
Sign In
Publish Control

Publish Control

by EthYusuf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

publish_control_fix

Generate detailed fix suggestions and code examples for a specific security finding using its ID and project path.

Instructions

Belirli bir güvenlik bulgusu için detaylı düzeltme önerileri ve kod örnekleri üretir. Önce publish_control ile tarama yapın, ardından bulgu ID'si ile düzeltme önerisi alın.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "findingId": "<findingId>",
      "projectPath": "<projectPath>"
    },
    "name": "publish_control_fix"
  }
}

Input Schema

NameRequiredDescriptionDefault
findingIdYesDüzeltilecek bulgunun ID'si (ör: SEC-001)
projectPathYesProje kök dizini

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral load. It usefully discloses the prerequisite relationship and that the response contains remediation advice plus code snippets, but says nothing about whether anything is written to disk, what permissions are needed, or how large/costly the generation is.

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?

Two tight sentences: the capability first, the workflow second. Nothing is redundant or padded.

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 two-parameter, non-mutating generator with no output schema, the description covers purpose, prerequisite and return content. The only real gap is the absence of any safety or side-effect statement, which would matter more if this tool touched files.

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 coverage is 100% and both parameters carry their own descriptions (including an example ID like SEC-001). The description only restates that a finding ID is supplied, adding no semantics beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource: generating detailed fix suggestions and code samples for a given security finding. The prerequisite scan tool is named, which separates it from the detection siblings, though it never explicitly contrasts itself with publish_control_quick.

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?

Gives an explicit ordered workflow: run publish_control first, then call this with the finding ID. That is clear when-to-use guidance, but there are no exclusions and the second sibling (publish_control_quick) is never addressed.

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