security_txt_analysisDiscover and validate RFC 9116 security.txt metadata on an authorized origin to find security contacts, policies, and disclosure details during bug bounty reconnaissance.
Discover and validate RFC 9116 security.txt metadata on an authorized origin.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | ||
| present | Yes | ||
| findings | Yes |
Changes observed during successful MCP inspections.
v2.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint and destructiveHint=false, so safety and idempotency are covered. The description adds one piece of non-annotation context, the 'authorized origin' scope constraint, which is useful. It does not explain behavior when the file is absent or malformed, so it only modestly exceeds the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb, resource and standard up front and no wasted clauses. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values can be omitted, and the annotations cover the safety profile. However, the definition leaves the caller without usage context and without url formatting guidance, which is the remaining gap for a one-parameter discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single url parameter, so the description must compensate. It does add one meaningful hint, that the target is an origin rather than a path to security.txt, but provides no format, scheme, or normalization details. Partial compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verbs (discover, validate) plus a precise resource (RFC 9116 security.txt metadata), so the agent knows exactly what is produced. It does not distinguish itself from adjacent sibling tools like robots_txt_analysis or sitemap_analysis, which follow the same discovery pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance and no named alternative. The phrase 'authorized origin' implicitly signals the scope prerequisite, but the agent gets no signal about when this audit is worth running versus a broader web_metadata_discovery or sensitive_file_exposure_scan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.