Vorim AI — Agent Identity & Trust

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific operations in the agent identity and trust domain, such as checking permissions, delegating credentials, registering agents, or revoking access. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.
Naming Consistency5/5
All tool names follow a consistent 'vorim_verb_noun' pattern with snake_case, such as vorim_check_permission, vorim_register_agent, and vorim_revoke_permission. This uniformity enhances readability and predictability across the entire toolset.
Tool Count5/5
With 17 tools, the server is well-scoped for managing agent identity and trust, covering essential operations like registration, permission management, auditing, and verification. Each tool serves a specific and necessary function, avoiding bloat or gaps.
Completeness5/5
The toolset provides complete CRUD and lifecycle coverage for the domain, including agent registration, updates, revocation, permission management, delegation, auditing, and trust verification. There are no obvious gaps, ensuring agents can handle all core workflows effectively.
Average 3.4/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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, the description carries full burden but lacks critical behavioral details. It mentions optional rate limits and expiry, but doesn't disclose permissions needed, whether delegation is reversible, effects on existing delegations, or response format. For a mutation tool, this is a significant gap.
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?
Two concise sentences with zero waste: the first states the core purpose, the second adds key optional features. It's front-loaded and 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., auth requirements, side effects), usage context, and return values, leaving significant gaps for an agent to understand and invoke it correctly.
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 100%, so the schema fully documents all 5 parameters. The description adds minimal value by hinting at scopes (e.g., 'read', 'write') and optional features, but doesn't provide additional syntax, constraints, or examples beyond what's in the schema.
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 ('Delegate a credential') and resource ('to an agent'), specifying it creates a scoped delegation. It distinguishes from siblings like 'grant_permission' or 'list_delegations' by focusing on credential delegation, but doesn't explicitly contrast with them.
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 on when to use this tool versus alternatives like 'grant_permission' or 'request_token' is provided. The description implies usage for delegation scenarios but offers no context about prerequisites, typical workflows, or exclusion criteria.
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 optional expiry and rate limits, which hints at mutation and constraints, but fails to specify critical details: whether this operation is idempotent, what permissions are required to execute it, how errors are handled (e.g., invalid agent_id), or the response format. For a permission-granting 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 a single, efficient sentence that front-loads the core action ('Grant a permission scope to an agent') and appends optional features concisely. There is no wasted language, and it's structured to immediately convey the primary function without unnecessary elaboration.
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 a permission-granting tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., idempotency, error handling), usage context compared to siblings, and what the tool returns upon success or failure. While the schema covers parameters well, the overall context for safe and effective use is insufficient.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value by implying that 'valid_until', 'rate_limit_max', and 'rate_limit_window' are optional enhancements, but doesn't explain their interactions or provide examples (e.g., format of 'scope'). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have elaborated on parameter relationships.
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 ('Grant') and resource ('permission scope to an agent'), making the purpose understandable. It distinguishes from siblings like 'vorim_check_permission' (checking) and 'vorim_revoke_permission' (revoking) by focusing on granting. However, it doesn't explicitly mention what a 'permission scope' entails or how it differs from similar tools like 'vorim_delegate_credential', leaving some ambiguity.
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., agent must exist), exclusions (e.g., cannot grant overlapping scopes), or compare to siblings like 'vorim_delegate_credential' for credential-based permissions. Without such context, an agent might misuse it in inappropriate 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 action but doesn't describe what 'active permissions' entails (e.g., format, scope, or limitations), whether it's read-only, or any rate limits. This leaves significant gaps for a tool with no annotation coverage.
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 directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise and well-structured.
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 doesn't explain what 'active permissions' means, the return format, or any behavioral traits like safety or constraints. For a tool with no structured data beyond the input schema, this leaves too many unknowns for effective use.
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 description coverage is 100%, with the single parameter 'agent_id' documented in the schema. The description doesn't add any meaning beyond this, such as clarifying what constitutes an 'agent' or how permissions are structured. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
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 verb ('List') and resource ('active permissions for an agent'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'vorim_check_permission' or 'vorim_list_agents', which reduces its differentiation value.
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 'vorim_check_permission' (for checking a specific permission) or 'vorim_list_agents' (for listing agents). There's no mention of prerequisites, context, or exclusions, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool registers agents and returns specific data (agent_id, did:key, keypair), but lacks critical details such as authentication requirements, rate limits, side effects, or what 'auto-expire' entails operationally. This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence that front-loads the purpose and key traits ('short-lived agents that auto-expire'), with no wasted words. However, it could be slightly more structured by separating the return values into a distinct clause for clarity.
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 registering agents with identity and permissions, no annotations, and no output schema, the description is incomplete. It lacks details on authentication, error conditions, the significance of returned values, and how this tool fits into the broader agent lifecycle compared to siblings like 'vorim_update_agent' or 'vorim_revoke_agent'.
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 100%, with each parameter well-documented in the schema (capabilities, scopes, ttl_seconds). The description adds no additional meaning beyond the schema, such as examples or constraints not in the schema. 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.
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 ('ephemeral agent with a did:key identity'), distinguishing it from sibling tools like 'vorim_register_agent' by specifying 'ephemeral' and 'short-lived agents that auto-expire'. However, it doesn't explicitly contrast with the non-ephemeral registration tool, missing full sibling differentiation.
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 mentions 'short-lived agents that auto-expire', which implies usage for temporary needs, but provides no explicit guidance on when to use this tool versus alternatives like 'vorim_register_agent' or other agent-related tools. There are no exclusions, prerequisites, or clear context for selection.
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 discloses that the token is 'short-lived' and 'scoped', which are useful behavioral traits. However, it lacks details on authentication requirements, rate limits, error conditions, or what 'short-lived' means (e.g., expiration time). For a tool that likely involves security-sensitive operations, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose ('Request a short-lived access token for an agent') and followed by return details. Every word earns its place with no redundancy or fluff, making it highly 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 (security-related token request), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., token structure), error handling, or dependencies (e.g., requires prior agent registration). For a tool with three parameters and potential side effects, more context is needed to ensure safe and correct usage.
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 100%, so the schema already documents all three parameters (agent_id, scope, provider_id) with descriptions. The description adds minimal value beyond the schema by implying that 'scope' defines permissions and 'provider_id' targets a specific provider, but doesn't provide additional syntax, format examples, or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Request a short-lived access token') and the resource ('for an agent'), with the return value specified. It distinguishes from siblings like 'vorim_grant_permission' or 'vorim_delegate_credential' by focusing on token acquisition rather than permission management or credential delegation. However, it doesn't explicitly differentiate from all siblings, such as 'vorim_verify_trust' which might involve token validation.
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 explicit guidance on when to use this tool versus alternatives is provided. The description mentions 'for an agent' and 'for the specified provider', but doesn't clarify prerequisites (e.g., agent registration) or contrast with siblings like 'vorim_delegate_credential' (which might handle longer-term credentials). Usage is implied through parameter context, but no explicit when/when-not statements are included.
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 for behavioral disclosure. It states the action ('revoke') which implies a destructive mutation, but doesn't clarify whether this requires specific permissions, if the change is reversible, what happens on success/failure, or any rate limits. For a security-sensitive mutation tool, this lack of behavioral context is a significant gap.
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 states the core functionality without unnecessary words. It's front-loaded with the key action and target, making it immediately scannable. Every word earns its place in conveying the essential purpose.
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 permission revocation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after revocation, whether there are side effects, what format the scope parameter expects, or security implications. Given the complexity of permission management and lack of structured behavioral hints, more context is needed for safe operation.
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 input schema has 100% description coverage, with both parameters clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema (e.g., format examples, scope enumeration, or relationships between parameters). This meets the baseline for high schema coverage but doesn't enhance understanding.
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 ('revoke') and target ('permission scope from an agent'), making the purpose immediately understandable. It distinguishes from siblings like 'vorim_grant_permission' (opposite action) and 'vorim_list_permissions' (read-only), though it doesn't explicitly mention these distinctions. The description avoids tautology by specifying what gets revoked rather than just restating the name.
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 'vorim_revoke_agent' (which revokes the entire agent) or 'vorim_grant_permission' (for granting permissions). It doesn't mention prerequisites (e.g., whether the permission must exist first) or contextual constraints, leaving the agent to infer usage from the tool name alone.
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 implies a mutation operation ('Update') but doesn't disclose critical traits like required permissions, whether updates are idempotent, error conditions, or what happens to unspecified fields. This is inadequate for a mutation tool with zero annotation coverage.
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 core action ('Update an agent's metadata') and lists the updatable fields. Every word earns its place with no redundancy or fluff.
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 mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., permissions, side effects), usage guidance, and output expectations, leaving significant gaps for an AI agent to invoke it correctly.
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 100%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain format constraints or interactions between parameters). Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('Update') and resource ('an agent's metadata'), specifying the fields that can be updated (name, description, status, capabilities). It distinguishes from sibling tools like vorim_get_agent (read) and vorim_register_agent (create), but doesn't explicitly differentiate from similar update operations if they exist.
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. It doesn't mention prerequisites (e.g., needing specific permissions), when not to use it, or how it relates to siblings like vorim_get_agent (for viewing) or vorim_revoke_agent (for deletion).
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 logs events but doesn't describe key behaviors: whether this is a write operation (implied by 'log'), if it requires specific permissions, potential rate limits, or what happens on success/failure (e.g., confirmation or error response). The description is minimal and lacks operational details needed for safe invocation.
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 two sentences, front-loaded with the core purpose and followed by a rationale. Every word earns its place without redundancy or fluff. It's appropriately sized for a logging tool, 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 complexity (8 parameters, 4 required) and lack of annotations or output schema, the description is incomplete. It covers the 'what' and 'why' but misses operational context like authentication needs, error handling, or return values. While the schema handles parameters well, the description should compensate for the absence of behavioral annotations, which it doesn't fully do.
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 input schema has 100% description coverage, with each parameter clearly documented (e.g., 'agent_id' as 'The agent that performed the action'). The description adds no additional parameter information beyond the schema. According to the rules, with high schema coverage (>80%), the baseline score is 3, as the schema already provides comprehensive semantics.
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: 'Log an audit event for an agent action.' It specifies the verb ('log') and resource ('audit event'), and the second sentence explains the rationale ('for compliance and traceability'). However, it doesn't explicitly differentiate this tool from sibling tools like 'vorim_export_audit' or 'vorim_list_agents', which might also relate to audit or agent management.
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 context with 'Every agent action should be logged,' suggesting this tool is for recording agent activities. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., 'vorim_export_audit' for retrieving logs or 'vorim_check_permission' for permission checks). No exclusions or prerequisites are mentioned, leaving usage somewhat open-ended.
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 lists delegations with optional filtering, but doesn't describe key behavioral traits such as whether it's read-only, what the output format looks like (e.g., list structure, pagination), or any rate limits or authentication requirements. This leaves significant gaps for a tool that likely involves sensitive credential data.
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 extremely concise and front-loaded, consisting of just two sentences that directly state the purpose and usage. Every word earns its place, with no redundant information, making it easy for an agent to parse quickly.
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 credential delegations and the lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'credential delegation' entails in this context, how results are returned, or any behavioral nuances. For a tool in a security-sensitive domain with no structured support, more detail is needed to ensure safe and correct usage.
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 value beyond the input schema, which has 100% coverage for the single parameter 'agent_id'. It mentions the optional filter by agent_id, but doesn't provide additional context like format examples or edge cases. With high schema coverage, the baseline is 3, as the schema already documents the parameter adequately.
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 with a specific verb ('List') and resource ('credential delegations'), making it immediately understandable. It distinguishes itself from siblings like 'vorim_list_agents' or 'vorim_list_permissions' by focusing on delegations. However, it doesn't explicitly contrast with all siblings, such as 'vorim_export_audit' which might also involve delegation data.
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 provides clear context for usage by mentioning the optional filter parameter ('Optionally filter by agent_id'), which helps the agent understand when to apply this tool. It implies usage for viewing delegations, but lacks explicit guidance on when to choose this over alternatives like 'vorim_list_agents' or 'vorim_export_audit', and doesn't specify prerequisites or exclusions.
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 key behavioral traits: it returns events with a SHA-256 manifest for tamper-proof verification, indicating a read-only export with integrity features. However, it lacks details on permissions, rate limits, or error handling, which are important for a tool handling audit data.
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 two sentences with zero waste: the first states the purpose and scope, the second explains the return value and verification feature. It is front-loaded and appropriately sized, with every sentence earning its place.
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 complexity (exporting audit bundles with verification), no annotations, and no output schema, the description is moderately complete. It covers the core functionality and output format but lacks details on authentication, data format, or error cases, which could hinder effective use.
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 100%, so the schema fully documents the two parameters (from and to as ISO 8601 dates). The description adds no additional parameter semantics beyond implying date-range filtering, meeting the baseline for high schema coverage without extra value.
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 ('Export a signed audit bundle') and resource ('for a date range'), distinguishing it from siblings like vorim_emit_event (emitting) or vorim_list_agents (listing). It precisely defines the tool's function 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 among the 15 sibling tools. It does not mention prerequisites, exclusions, or specific contexts, leaving the agent to infer usage solely from the purpose statement.
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 of behavioral disclosure. It mentions 'Supports pagination and filtering by status' which adds useful context about capabilities beyond basic listing. However, it doesn't disclose important behavioral traits like whether this requires authentication, rate limits, what happens with invalid parameters, or the format/structure of returned data. The description doesn't contradict any annotations (none exist).
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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second adds important behavioral context about pagination and filtering. No wasted words, no redundancy, and front-loaded with the main functionality.
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?
For a list tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and mentions pagination/filtering capabilities, but doesn't address authentication requirements, error conditions, response format, or how to interpret the results. Given the lack of output schema, some description of return values would be helpful but is absent.
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 100%, so the schema already fully documents all three parameters with descriptions and defaults. The description adds minimal value beyond the schema by mentioning 'filtering by status' which is already covered in the schema's status parameter description. No additional parameter semantics, constraints, or usage examples are provided beyond what's in the structured schema.
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 verb ('List') and resource ('all agents in the organisation'), making the purpose immediately understandable. It distinguishes from sibling tools like 'vorim_get_agent' (singular retrieval) and 'vorim_register_agent' (creation). However, it doesn't explicitly mention what 'agents' represent in this context, which could help differentiate from other list tools like 'vorim_list_delegations' or 'vorim_list_permissions'.
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 for retrieving multiple agents with optional filtering, but provides no explicit guidance on when to use this versus alternatives like 'vorim_get_agent' for single agents or other list tools. It mentions filtering by status but doesn't specify when filtering is appropriate versus retrieving all agents. 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.
Behavior4/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 effectively adds context: it specifies the tool is a public endpoint with no authentication required, and describes the return values (trust score, status, active scopes, key fingerprint). This covers key behavioral traits like accessibility and output format, though it could mention rate limits or error handling for a higher score.
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: it starts with the core purpose, then adds key behavioral details (public endpoint, no auth), and ends with return values. Every sentence earns its place with no wasted words, making it highly efficient and well-structured.
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?
Given the tool's complexity (simple verification with one parameter), no annotations, no output schema, and rich description coverage, the description is mostly complete. It explains the purpose, usage context, and return values. However, without an output schema, it could benefit from more detail on output structure or error cases, but it's sufficient for a tool of this nature.
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 input schema has 100% description coverage, with the parameter 'agent_id' fully documented in the schema. The description does not add any meaning beyond what the schema provides regarding parameters. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which applies here.
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: 'Verify an agent's identity and trust score.' It specifies the verb ('verify') and the resource ('agent'), but doesn't explicitly differentiate from siblings like 'vorim_get_agent' or 'vorim_list_agents' beyond the verification focus. The description is specific but lacks sibling differentiation for a full 5.
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 provides some usage context by stating 'Public endpoint — no authentication required,' which implies when to use it (for public verification) and hints at alternatives (tools requiring authentication). However, it doesn't explicitly name when-not-to-use scenarios or compare to specific siblings like 'vorim_get_agent,' leaving guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses the return values (boolean allowed, reason if denied, remaining quota) and performance characteristics ('Sub-5ms via Redis cache'). However, it does not mention error handling, authentication needs, or rate limits, leaving some gaps for a tool with no annotation coverage.
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, followed by return details and performance note in a single, efficient sentence. Every element adds value without waste, making it easy for an AI agent to parse and understand quickly.
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?
Given no annotations and no output schema, the description compensates well by explaining return values and performance. However, it lacks details on error cases or system dependencies (e.g., Redis availability), which could be important for a permission-checking tool. It is mostly complete but has minor gaps in behavioral 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?
Schema description coverage is 100%, so the schema already documents both parameters ('agent_id' and 'scope') with descriptions. The description adds minimal semantic value beyond the schema by implying the scope examples ('e.g. agent:read, agent:execute'), but this is redundant with the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Check if an agent has a specific permission scope') and the resource ('permission scope'), distinguishing it from siblings like 'vorim_grant_permission' or 'vorim_revoke_permission' which modify permissions rather than checking them. It also specifies the return format, which helps differentiate its read-only nature.
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 for permission verification but does not explicitly state when to use this tool versus alternatives like 'vorim_list_permissions' or 'vorim_verify_trust'. It provides context (e.g., 'Sub-5ms via Redis cache') that suggests use cases requiring fast checks, but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key behavioral traits: the tool returns an Ed25519 keypair, agent_id, and trust score; it warns that the private key is shown only once and must be stored securely. This covers critical security and operational aspects, though it doesn't mention potential rate limits, authentication requirements, or error conditions.
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 extremely concise and front-loaded, consisting of just two sentences that efficiently convey the tool's purpose and critical behavioral details. Every sentence earns its place: the first states the action and return values, the second provides essential security guidance with zero waste or redundancy.
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?
Given the tool's complexity (registration with security implications), no annotations, and no output schema, the description does well by explaining the return structure (keypair, agent_id, trust score) and security warning. However, it could be more complete by mentioning potential prerequisites (e.g., authentication needed) or what happens on failure, though the security guidance partially compensates for the lack of structured fields.
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 100%, so the schema already fully documents all four parameters (name, description, capabilities, scopes) with clear descriptions and requirements. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline expectation when schema coverage is high.
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 ('Register a new AI agent with Vorim') and the resource ('AI agent'), distinguishing it from sibling tools like vorim_get_agent (retrieval) or vorim_revoke_agent (deletion). It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
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 context by mentioning the return of an agent identity and private key, suggesting this is for initial setup. However, it doesn't explicitly state when to use this tool versus alternatives like vorim_register_ephemeral (for temporary agents) or vorim_update_agent (for modifications), leaving some ambiguity about sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key traits: the action is permanent and irreversible, deactivates the agent's identity, and sets its trust score to 0. This covers destructive impact and outcomes, though it lacks details on permissions or error handling.
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 action and consequences in two concise sentences. Each sentence adds critical information (irreversibility and specific effects), with no wasted words, making it highly efficient 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?
Given the tool's complexity (destructive action with permanent effects) and lack of annotations or output schema, the description does a good job covering key behavioral aspects. It explains the irreversible nature and outcomes, though it could benefit from mentioning permissions or error scenarios for full completeness.
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 100%, with the parameter 'agent_id' fully documented in the schema. The description does not add any additional meaning or context about the parameter beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.
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 ('permanently revoke') and resource ('an agent'), distinguishing it from siblings like 'vorim_update_agent' or 'vorim_get_agent'. It explicitly mentions irreversible consequences, which adds specificity beyond the basic verb.
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 context by stating the action is permanent and cannot be undone, suggesting caution. However, it does not explicitly guide when to use this tool versus alternatives like 'vorim_update_agent' or provide prerequisites, leaving some ambiguity for the agent.
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 of behavioral disclosure. It describes the return data (name, status, trust score, capabilities, permissions, metadata), which is helpful, but does not cover other behavioral aspects such as error handling, authentication requirements, rate limits, or whether the operation is read-only (implied by 'Get' but not explicitly stated). The description adds value but leaves gaps for a mutation-free tool.
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, well-structured sentence that efficiently conveys the tool's purpose, input, and output. It is front-loaded with the core action and includes no redundant information, making it highly concise and effective.
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?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and what it returns, which is sufficient for a simple retrieval operation. However, without annotations or an output schema, it could benefit from more detail on behavioral aspects like error cases or data formats, but it meets the minimum requirements for this context.
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 input schema has 100% description coverage, with the single parameter 'agent_id' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, but since there is only one parameter and the schema coverage is high, the baseline is 3. The description's mention of 'agent_id' reinforces the parameter's purpose, slightly elevating the score.
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 ('Get details') and resource ('a specific agent by agent_id'), and distinguishes it from sibling tools like 'vorim_list_agents' (which lists multiple agents) and 'vorim_update_agent' (which modifies an agent). The verb 'Get' is precise and the scope is well-defined.
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 by specifying 'a specific agent by agent_id', suggesting it should be used when you have a particular agent identifier. However, it does not explicitly state when to use alternatives like 'vorim_list_agents' for browsing agents or 'vorim_update_agent' for modifying agents, nor does it mention prerequisites or exclusions.
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?
No annotations are provided, so the description carries the full burden. It discloses the return values (status, version, service health) and implies a read-only, non-destructive operation, but lacks details on error handling, rate limits, or authentication needs. This is adequate but has gaps.
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 return values with zero waste. Every word earns its place, making it highly concise and well-structured.
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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for a health check tool. It covers purpose and return values, though it could benefit from more behavioral context like error scenarios or performance expectations.
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 parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter information, which is appropriate since there are no parameters to document, maintaining clarity without redundancy.
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 verb ('Check') and resource ('Vorim AI API health and connectivity'), distinguishing it from sibling tools that focus on permissions, agents, delegations, events, and other operations. It precisely communicates the tool's diagnostic purpose.
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 for health and connectivity checks, which provides clear context. However, it does not explicitly state when not to use it or name alternatives among the sibling tools, such as for more detailed status checks or troubleshooting.
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:

[![vorim-mcp-server MCP server](https://glama.ai/mcp/servers/Vorim-AI-Labs/vorim-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Vorim-AI-Labs/vorim-mcp-server)

Score Badge

Copy to your README.md:

[![vorim-mcp-server MCP server](https://glama.ai/mcp/servers/Vorim-AI-Labs/vorim-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Vorim-AI-Labs/vorim-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/Vorim-AI-Labs/vorim-mcp-server'

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