Skip to main content
Glama

Security requirements checklist

security_requirements_checklist

Produce a security requirements checklist for non-functional requirements, with verification methods and scope-based priorities, adding regulated and context-specific items.

Instructions

非機能要件として ID 管理すべきセキュリティ要件のチェックリストを返す。各項目に「どう検証するか」を併記する。scope の記述から公開範囲・データの機微性・規模・運用体制を読み取り、この範囲で先に着手すべき項目を理由付きで選ぶとともに、共通の一覧には無い範囲固有の観点(物理アクセス、取引先アカウントのライフサイクル、責任分界など)を足す。regulated を true にすると規制対象の案件で追加になる項目も含める(false でも、記述に個人情報・決済が出てくれば指摘する)。 / Return the checklist of security requirements to register and track as non-functional requirements, each with its verification method. Reads exposure, data sensitivity, scale, and the operating arrangement out of scope to select, with reasons, which items to start with here, and adds scope-specific concerns the generic list omits — physical access, partner account lifecycle, the responsibility split. Set regulated to true to include what regulated engagements additionally need; with false, it still flags personal data or payments if the text mentions them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNo出力言語 / Output languageboth
scopeNo対象範囲。システム名だけでなく、公開範囲・扱うデータ・保守体制まで書くと項目に優先度が付く。省略すると書き方の案内を返す / The scope. Beyond a system name, describing exposure, the data held, and the maintenance arrangement makes the items get prioritized. Omit it for guidance on what to write — 最大 20,000 文字 at most 20,000 characters
regulatedNo規制対象の案件かどうか / Whether the engagement is subject to regulation
Install Server

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and fully discloses behavior: it reads exposure, data sensitivity, scale, and operating arrangement from `scope`, selects prioritized items with reasons, appends scope-specific concerns, handles regulated vs. non-regulated cases, and returns writing guidance when `scope` is omitted. Nothing about the tool's behavior is left to guesswork.

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 lengthy and bilingual, but every clause carries functional weight: core purpose, scope analysis, prioritization, scope-specific additions, regulation behavior, and fallback. The main purpose is front-loaded, and the duplication between languages is not filler—it ensures clarity for either language context.

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?

Even without an output schema, the description specifies the return content (checklist items with verification methods, prioritized items with reasons, scope-specific additions) and all edge cases (regulated true/false, scope omitted). It does not specify the exact data format of the response, but that is a minor gap given the detailed behavioral description.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining what `scope` should contain (public exposure, data sensitivity, scale, operating arrangement) and how `regulated=false` still triggers flags for personal data or payments. This helps the agent construct better parameter values.

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 states a specific verb (返す / returns) and a clear resource: a security-requirements checklist with verification methods. It further differentiates the tool by explaining that it prioritizes which items to start with and adds scope-specific concerns, distinguishing it from siblings like generate_review_checklist or threat_model_starter.

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 gives concrete conditions: setting `regulated` to true adds regulatory items, while false still flags personal data or payments, and omitting `scope` returns guidance on what to write. It does not name sibling alternatives explicitly, but these behavioral conditions effectively tell an agent when to use this tool.

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/Waganawa-Megumin/togaf10_EAP_MCP'

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