mcp-india-stack

Overview Schema Source Related Servers Discussions Admin

validate_aa_consent_artifact

Read-onlyIdempotent

Validate Account Aggregator consent artifacts by checking JSON structure and flags. Ensures only valid consent data proceeds to processing, returning a validation result with consent details.

Instructions

Validate AA consent artifact structure and flags.

Use when verifying consent artifacts received from AA before processing.

Args: artifact: Consent artifact JSON from AA response

Returns: Validation result with consent details.

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": {
      "artifact": "<artifact>"
    },
    "name": "validate_aa_consent_artifact"
  }
}

Input Schema

Name	Required	Description	Default
`artifact`	Yes	AA consent artifact JSON

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.5.0Aug 25, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / artifact / title
```
Added value: +"Artifact"
```
- addedInput schema / title
```
Added value: +"validate_aa_consent_artifactArguments"
```
- addedOutput schema / title
```
Added value: +"validate_aa_consent_artifactDictOutput"
```
Addedv0.4.2Jun 8, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already establish read-only and idempotent behavior, and the description does not contradict them. The description adds only limited behavioral context: that validation concerns 'structure and flags' and returns a validation result. It does not describe edge cases, error behavior, or what 'flags' means, but the output schema helps cover return-value expectations.

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 short, front-loaded with the core purpose, and structured into purpose, usage, args, and returns. There is some redundancy between the Args section and the schema, but the overall structure remains clean and easy to parse.

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 single-parameter validation tool with an output schema and read-only/idempotent annotations, the description covers what is needed for selection and invocation. It states the input, the intended usage moment, and gives a return hint. It does not explain full validation criteria, but this is not essential for choosing the tool.

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?

The schema already provides 100% coverage of the single artifact parameter. The description repeats 'Consent artifact JSON from AA response', adding only the minor extra context that it comes from an AA response. This is baseline value rather than substantial enhancement.

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 uses a specific verb and resource combination: 'Validate AA consent artifact structure and flags.' It clearly distinguishes this from sibling tools like build_aa_consent_request and decode_aa_fi_type. The additional context about verifying artifacts received from AA reinforces what the tool is for.

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 explicitly says 'Use when verifying consent artifacts received from AA before processing', giving a clear context for when this tool is appropriate. It does not explicitly mention when not to use it or name direct alternatives, so it falls short of a 5.

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

Deploy Server