aip-identity

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: message checking, identity registration, message sending, content signing, trust score retrieval, identity verification, signature verification, and identity display. The descriptions reinforce these distinct functions, making misselection unlikely.
Naming Consistency5/5
All tools follow a perfect 'aip_' prefix + verb pattern (e.g., aip_check_messages, aip_register, aip_send_message). The naming is completely consistent with snake_case throughout, making the tool set predictable and easy to understand.
Tool Count5/5
With 8 tools, this is well-scoped for an identity management server. Each tool serves a specific function in the AIP identity lifecycle (registration, verification, messaging, signing), and none appear redundant or unnecessary for the domain.
Completeness4/5
The tool set covers core identity operations well: registration, verification, signing, and trust management. A minor gap exists in message management—there's no tool to delete or manage sent messages—but agents can still perform essential workflows without significant hindrance.
Average 3.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Register') but doesn't explain what registration entails—whether it's a one-time setup, if it requires authentication, what happens on success/failure, or if it has side effects like storing credentials. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. The 'Args' section is structured but could be more integrated; overall, it's efficient with minimal waste, though it could be slightly more polished for a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't cover what the tool returns (e.g., success status, identity token), error conditions, or how it fits into the broader AIP system with siblings. For a registration tool, this leaves critical gaps in understanding its role and outcomes.
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 description includes an 'Args' section that lists and briefly describes both parameters ('platform' and 'username'), adding meaning beyond the schema which has 0% description coverage. However, it doesn't provide examples beyond 'github', 'moltbook', 'discord' for platform, or explain constraints (e.g., platform must be supported, username format). This partial compensation justifies a baseline score.
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?
The description clearly states the action ('Register') and resource ('a new AIP identity for your agent'), making the purpose immediately understandable. However, it doesn't differentiate this registration tool from sibling tools like aip_whoami or aip_verify, which might also relate to identity management, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether an agent must be initialized first), when registration is needed (e.g., for first-time setup), or how it relates to siblings like aip_whoami (which might check identity status). This lack of context leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions encryption, which is a useful trait beyond basic sending, but doesn't cover other critical aspects like authentication requirements, rate limits, error handling, or what happens after sending (e.g., confirmation, delivery status). For a communication tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 front-loaded with the core purpose in the first sentence, followed by a clear 'Args:' section listing parameters. It's efficient with no wasted words, though the parameter explanations are brief. The structure aids readability, but could be slightly more detailed without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sending encrypted messages, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks information on authentication, encryption specifics, response format, error cases, and how it integrates with siblings like 'aip_check_messages'. For a tool with 2 parameters and no structured support, it should provide more context to be fully usable.
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 description coverage is 0%, so the schema provides no parameter details. The description adds basic semantics by explaining 'recipient_did' as 'The DID of the recipient agent' and 'message' as 'The message text to send', which clarifies what each parameter represents. However, it doesn't provide format details (e.g., DID structure, message length limits) or examples, offering only minimal compensation for the low coverage.
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?
The description clearly states the action ('Send an encrypted message') and the target ('to another agent'), which is specific and actionable. It distinguishes this from siblings like 'aip_check_messages' (which retrieves messages) and 'aip_verify' (which likely verifies something else), but doesn't explicitly differentiate beyond the basic function. It's not a tautology and provides a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing to register or authenticate first), exclusions, or compare it to siblings like 'aip_check_messages' for receiving messages. Usage is implied by the purpose but lacks explicit context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, or what the output format looks like (e.g., numeric score, chain details). This leaves significant gaps in understanding how the tool behaves.
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 concise and well-structured, with a clear purpose statement followed by parameter explanations in a bullet-like format. Every sentence adds value, and there's no unnecessary information, making it efficient to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of trust scoring and vouch chains, the description is incomplete. With no annotations, no output schema, and low parameter coverage, it fails to explain key aspects like return values, error conditions, or how the trust score is calculated. This makes it inadequate for an agent to use the tool effectively without additional context.
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 description adds minimal semantics beyond the input schema. It explains that 'did' is 'The DID of the agent to check' and 'scope' is an 'Optional trust scope filter (e.g. GENERAL, CODE_SIGNING)', which provides basic context. However, with 0% schema description coverage and two parameters, this is insufficient to fully compensate, as it doesn't detail format constraints or usage examples.
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?
The description clearly states the tool's purpose: 'Get the trust score and vouch chain for an agent.' It specifies the verb ('Get'), resource ('trust score and vouch chain'), and target ('an agent'), making the function understandable. However, it doesn't explicitly differentiate from sibling tools like 'aip_verify' or 'aip_verify_signature', which might also involve trust-related checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions an optional 'scope' parameter but doesn't explain its purpose or when to apply it. There's no mention of prerequisites, context, or comparisons to sibling tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool checks for messages but doesn't disclose behavioral traits such as permission requirements, rate limits, response format, or whether it's read-only or has side effects. This is inadequate for a tool with potential behavioral implications.
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 appropriately sized and front-loaded, with the purpose stated first and parameter details following. It avoids unnecessary words, though the structure could be slightly improved by integrating the parameter explanation more seamlessly. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It covers the basic purpose and parameter but misses critical context like what the tool returns, error conditions, or how it interacts with the system. For a messaging tool, this leaves significant gaps for an AI agent.
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?
The description adds meaningful semantics for the single parameter 'unread_only', explaining its purpose and default value. Since schema description coverage is 0%, this compensates well, providing clarity beyond the basic schema. With only one parameter, the baseline is high, and the description effectively covers it.
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?
The description clearly states the tool's purpose: 'Check for messages sent to your agent.' This specifies the verb ('Check') and resource ('messages sent to your agent'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'aip_send_message' or 'aip_verify', which handle different operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions a parameter default but doesn't explain contexts like checking for new messages versus all messages, or how it relates to other messaging tools. This lack of usage context leaves gaps for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool signs content to prove authorship, which implies a write operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, side effects, or what the signature output looks like. The description is minimal and lacks necessary context for safe use.
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?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief parameter explanation. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cryptographic signing, lack of annotations, no output schema, and minimal parameter coverage, the description is incomplete. It doesn't explain the signature format, return values, error conditions, or dependencies on other tools like aip_register. For a security-sensitive tool, this leaves significant gaps in understanding.
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?
With 0% schema description coverage and only 1 parameter, the description compensates by explaining the parameter: 'content: The text content to sign.' This adds clear meaning beyond the schema, which only provides a title and type. The description effectively clarifies the parameter's purpose and format.
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?
The description clearly states the tool's purpose: 'Cryptographically sign content with your AIP identity to prove authorship.' It specifies the verb ('sign'), resource ('content'), and goal ('prove authorship'), though it doesn't explicitly differentiate from siblings like aip_verify_signature. The purpose is specific but lacks sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions proving authorship, but it doesn't specify prerequisites, when not to use it, or compare it to siblings like aip_verify_signature. Usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions 'cryptographic challenge-response' which hints at the verification mechanism, but doesn't disclose what happens during verification (e.g., network calls, timeouts, authentication requirements), what constitutes success/failure, or side effects. For a security-critical tool with zero annotation coverage, this is inadequate.
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 efficiently structured with a clear purpose statement followed by parameter documentation. Every sentence adds value, though the parameter documentation could be integrated more seamlessly rather than as a separate 'Args:' section. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cryptographic verification tool with no annotations and no output schema, the description is insufficient. It doesn't explain what verification returns (success/failure indicators, trust levels, timestamps), error conditions, performance characteristics, or security implications. The context demands more completeness for safe agent operation.
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 description coverage is 0%, so the description must compensate. It provides the single parameter 'did' with a clear example format ('did:aip:abc123...'), adding essential semantic meaning beyond the bare schema. However, it doesn't explain where to obtain DIDs, validation rules, or what happens with invalid DIDs.
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 clearly states the specific action ('verify another agent's identity') and method ('via cryptographic challenge-response'), distinguishing it from siblings like aip_verify_signature (which likely verifies signatures rather than identities) and aip_whoami (which likely identifies self rather than others). The verb+resource+method combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to verify another agent's identity cryptographically, but provides no explicit guidance on when to use this versus alternatives like aip_trust_score (which might provide reputation data) or aip_verify_signature. There's no mention of prerequisites, error conditions, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool verifies signatures but doesn't describe what happens on success/failure (e.g., returns boolean, throws error), performance characteristics, rate limits, or authentication needs. For a cryptographic tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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?
The description is front-loaded with the core purpose in the first sentence, followed by a structured Args section that efficiently explains each parameter. Every sentence earns its place with no redundant or verbose language, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (cryptographic verification), no annotations, no output schema, and 3 parameters, the description is minimally adequate. It covers the purpose and parameters well but lacks behavioral details (e.g., return values, error conditions) and usage context. It meets basic needs but leaves gaps that could hinder effective tool selection and invocation.
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 description coverage is 0%, so the description must compensate. It adds clear meaning for all three parameters: 'content' is 'the original content that was signed', 'signature' is 'the base64-encoded signature to verify', and 'did' is 'the DID of the agent who allegedly signed it'. This effectively documents parameter purposes beyond the bare schema, though it doesn't specify format constraints (e.g., DID syntax).
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 clearly states the tool's purpose with a specific verb ('verify') and resource ('cryptographic signature against a DID's public key'), distinguishing it from siblings like aip_sign (which creates signatures) and aip_verify (which may have different verification scope). It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like aip_verify or aip_check_messages. It lacks context about prerequisites, scenarios where verification is needed, or any explicit exclusions. Usage is implied only by the purpose statement, with no comparative information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's read-only behavior by using 'Show' and specifies the returned data, but lacks details on error conditions, authentication requirements, or rate limits. It adds basic context without rich behavioral traits.
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?
The description is a single, efficient sentence that front-loads the purpose and lists the returned data. Every word earns its place with no redundancy or waste, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what data is returned but not the format or structure, and lacks error handling or authentication context. It meets minimum viability for a simple identity tool.
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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but this is appropriate given the lack of inputs. Baseline is 4 for zero parameters, as the description focuses on output.
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 clearly states the tool's purpose with a specific verb ('Show') and resource ('current AIP identity'), listing the exact data returned (DID, platform, public key). It distinguishes itself from siblings like aip_register (registration) or aip_send_message (messaging) by focusing on identity retrieval.
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 implies usage context ('your current AIP identity') for checking authentication status, but does not explicitly state when to use this tool versus alternatives like aip_verify (verification) or aip_trust_score (trust assessment). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![aip-mcp-server MCP server](https://glama.ai/mcp/servers/The-Nexus-Guard/aip-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/The-Nexus-Guard/aip-mcp-server)

Score Badge

Copy to your README.md:

[![aip-mcp-server MCP server](https://glama.ai/mcp/servers/The-Nexus-Guard/aip-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/The-Nexus-Guard/aip-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/The-Nexus-Guard/aip-mcp-server'

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