nexus-mcp — jpi-guard & PII Guard

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool detects and what it returns, but does not cover important behavioral aspects like rate limits, authentication requirements beyond the api_key parameter, error handling, or performance characteristics. The disclosure is adequate but lacks depth for a security-focused tool.

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?

The description is efficiently structured in two sentences: the first states purpose and specialization, the second lists detection capabilities and return values. Every element earns its place with no wasted words, and key information is front-loaded.

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?

For a security detection tool with 3 parameters, no annotations, and no output schema, the description provides adequate purpose and detection scope but lacks important context. It doesn't explain the return structure in detail (what risk_level values mean, format of detection_reason), doesn't mention error cases or limitations, and doesn't provide integration guidance beyond the basic use case.

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 100%, so the schema already fully documents all three parameters. The description does not add any meaningful parameter semantics beyond what's in the schema - it mentions the input parameter indirectly but doesn't provide additional context about parameter usage, constraints, or interactions.

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?

The description clearly states the tool's purpose with specific verbs ('detect prompt injection attacks') and resources ('user-supplied text'), explicitly listing the types of attacks it detects. It distinguishes from siblings by specifying specialization for Japanese RAG applications, unlike generic scanning tools like pii_scan or sanitize_content.

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?

The description provides clear context for when to use this tool ('before passing to an LLM' and 'for Japanese RAG applications'), but does not explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage scenarios without detailed exclusions.

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

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

With no annotations provided, the description carries full burden and does well: it discloses key behavioral traits like the free tier quota (10,000 requests/month), permanence, no credit card requirement, immediate usability with pii_scan, and idempotent behavior (returns existing key if email already registered). It lacks details on rate limits or error handling, but covers core operational context adequately.

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?

The description is front-loaded with the core purpose, followed by key details (quota, terms, behavior). Every sentence earns its place: first states action and outcome, second specifies quota and terms, third links to usage, fourth covers idempotency. No wasted words, appropriately sized for the tool's complexity.

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?

Given no annotations and no output schema, the description does well to cover purpose, usage, behavior, and parameters. It explains the return scenario (existing key detection) but doesn't detail output format or error cases. For a single-parameter tool with straightforward operation, it's nearly complete but could mention response structure.

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?

The input schema has 100% description coverage, so baseline is 3. The description adds value by explaining the parameter's purpose beyond the schema: 'Used only for key delivery and quota management' in the schema is expanded with context about registration, existing key checks, and quota allocation, providing richer semantics.

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?

The description clearly states the specific action ('Register an email address and get a free PII Guard API key') and distinguishes it from siblings like 'get_trial_key' (free vs trial) and 'pii_scan' (key acquisition vs usage). It explicitly mentions the resource (API key) and its purpose.

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?

The description provides explicit guidance on when to use this tool: for registering an email to obtain a free API key with specific quota (10,000 requests/month). It distinguishes from 'get_trial_key' by specifying 'permanent free tier, no credit card required' and mentions the alternative 'pii_scan' for key usage. It also covers the 'when-not' scenario: if email already has a key, it returns the existing one.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool returns a key with specific limits (2,000 requests, 30-day validity), no authentication requirements ('No credit card or signup required'), and immediate usability ('The key can be used immediately with sanitize_content'). It doesn't mention rate limits or error conditions, but covers the essential operational context.

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?

The description is perfectly concise with three sentences that each add distinct value: purpose statement, key specifications, and usage context. There's zero wasted language, and information is front-loaded with the core purpose immediately clear.

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?

For a zero-parameter tool with no annotations and no output schema, the description provides strong context about what the tool does, the key's specifications, and how to use it. It could be more complete by explicitly describing the return format (though 'Returns a key' implies a string) and mentioning any limitations beyond the 2,000 requests, but it covers the essential information needed to use this trial key acquisition tool effectively.

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?

The tool has zero parameters with 100% schema coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and output characteristics.

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?

The description clearly states the specific action ('Get a free trial API key') and identifies the target resource ('for the nexus-api-lab cleanse API'). It distinguishes this tool from siblings like 'get_pii_guard_key' by specifying the particular API and trial nature.

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?

The description provides clear context about when to use this tool: when needing a trial key for the cleanse API with 2,000 requests valid for 30 days. It mentions 'No credit card or signup required' as a usage condition. However, it doesn't explicitly state when NOT to use it or name alternatives like 'get_pii_guard_key' for different API keys.

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

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

With no annotations provided, the description carries the full burden and excels by disclosing key behavioral traits: it specifies the deterministic methods used (regex + checksum + keyword scoring, no LLM), includes full-width character normalization, details the 10 PII categories with validation rules (e.g., My Number mod-11, credit card Luhn), describes the output structure (findings[], has_high_risk, masked_text), and mentions rate limits (10,000 requests/month) and cost (free). This covers safety, functionality, and operational constraints comprehensively.

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?

The description is appropriately sized and front-loaded, starting with the core purpose and key features. Every sentence adds value, such as detailing methods, categories, and output. It could be slightly more structured (e.g., bullet points for categories), but it avoids waste and remains efficient.

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?

Given the complexity (PII scanning with multiple categories and methods), no annotations, and no output schema, the description is highly complete. It explains the detection logic, categories, output format (findings[], has_high_risk, masked_text), and operational details (rate limits, cost). This compensates well for the lack of structured fields, making it sufficient for an agent to understand and use the tool effectively.

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?

The schema description coverage is 100%, so the schema already documents all parameters (text, api_key, mask) thoroughly. The description does not add meaning beyond the schema, such as explaining how 'mask' interacts with the output or providing examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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?

The description clearly states the specific action ('Scan Japanese text for personally identifiable information') and resource ('PII'), distinguishing it from siblings like 'sanitize_content' or 'validate_rag_input' by focusing on detection rather than modification or validation. It explicitly lists the 10 categories detected, making the purpose highly specific and unambiguous.

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?

The description provides clear context for when to use this tool: for scanning Japanese text for PII using deterministic methods (regex, checksum, etc.), with a free tier of 10,000 requests/month. However, it does not explicitly state when not to use it or name alternatives among siblings (e.g., 'sanitize_content' might be for cleaning after scanning), leaving some guidance implicit rather than explicit.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: what gets detected (prompt injection payloads like hidden HTML, zero-width characters), the specialized focus (Japanese-language content), and what it returns (cleaned_content safe for the model). It doesn't mention rate limits, auth details beyond the API key parameter, or error handling beyond timeout behavior.

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?

The description is efficiently structured in two sentences: the first states purpose and detection scope, the second adds specialization and return value. Every sentence adds critical information with zero waste, making it easy to parse and front-loaded with key details.

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?

For a complex security tool with 7 parameters and no annotations or output schema, the description provides good context on behavior and purpose. However, it could better address error cases beyond timeout, explain the 'cleaned_content' output format, or detail performance characteristics. It's mostly complete but has minor gaps given the tool's complexity.

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?

The schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain 'strictness' levels or 'on_timeout' choices further). Baseline 3 is appropriate when the schema does the heavy lifting.

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?

The description clearly states the specific action ('sanitize external content'), the resource ('content'), and the purpose ('before passing it to an LLM'). It distinguishes from siblings by specifying it's for prompt injection detection and specialized for Japanese-language content, unlike tools like 'pii_scan' or 'validate_rag_input'.

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?

The description provides clear context for when to use this tool ('before passing external content to an LLM', 'specialized for Japanese-language content'), but doesn't explicitly mention when not to use it or directly compare to alternatives like 'check_injection' or 'validate_rag_input'. The guidance is helpful but lacks explicit exclusions.

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

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

With no annotations provided, the description carries full burden and does well: it explains the return behavior ('Returns safe: true if input can proceed to LLM, or safe: false with block_reason'), mentions it's a validation gate, and implies it's a security tool. It doesn't mention rate limits, auth requirements beyond the api_key parameter, or error handling details, keeping it from a perfect score.

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?

Three sentences with zero waste: first states purpose, second explains return behavior, third provides usage guidance. Each sentence earns its place by adding distinct value, and the description is appropriately sized for a validation tool.

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?

For a validation tool with 3 parameters, 100% schema coverage, and no output schema, the description is quite complete: it explains purpose, behavior, and usage context. The main gap is lack of output format details (what block_reason contains, response structure), but given the schema coverage and clear behavioral description, it's mostly adequate.

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 100%, so the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., doesn't explain input format expectations or api_key usage details), but it does provide context about the overall validation purpose that helps understand parameter roles.

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?

The description clearly states the tool's purpose with specific verbs ('validate user input is safe') and resources ('RAG pipeline'), and distinguishes it from siblings by mentioning 'prompt injection detection and content safety check' - unlike check_injection (only injection) or pii_scan/sanitize_content (different safety aspects).

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?

Explicit guidance is provided: 'Use this as a gate in your RAG handler' tells when to use it, and the description distinguishes it from alternatives by mentioning it combines multiple safety checks (injection + content safety) rather than just one aspect like check_injection or pii_scan.

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