dendrite-admin-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a specific administrative action: registration tokens have clear CRUD separation (list/get/create/update/delete), while room operations (evacuate, purge, download state) and user operations (register, reset password, whois) are distinct. Even similar-sounding tools like evacuate_room and evacuate_user are clearly differentiated by their target resource.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (list_registration_tokens, create_registration_token, reset_password, etc.). Minor deviations include 'whois' (a single word) and 'fulltext_reindex' (which could be interpreted as reindex_fulltext), but these are still understandable and do not create confusion.
Tool Count5/5
With 15 tools, the set is well-scoped for a Matrix homeserver admin tool. Each tool addresses a distinct administrative need (token management, user admin, room admin, server maintenance) and none feel redundant. The count is at the upper boundary but remains justified.
Completeness3/5
The tool set covers registration token CRUD, core user operations (create, reset password, whois), and room management (evacuate, purge, download state), but notable gaps exist: there is no user deletion/deactivation, no list users tool, and no general room listing/search. Agents cannot perform the full lifecycle for users or rooms.
Average 3.9/5 across 15 of 15 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden. It only says 'Modify' without disclosing whether it is a partial update, what happens to unspecified fields, authentication requirements, or how 'validity' changes. The behavior is underspecified for a mutation 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 sentence that is front-loaded with the verb and resource, with no wasted words. It is concise 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?
For a tool with 5 parameters, no annotations, and no output schema, a single sentence is insufficient. It lacks key information about parameter interactions, partial update behavior, prerequisites, and edge cases, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 mentions 'usage limit' and 'expiry time' which map to usesAllowed and expiryTime, but 'validity' is ambiguous and pending/completed are unexplained. Only a few of the 5 parameters are semantically clarified.
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 action ('Modify') and the resource ('an existing registration token'), and it lists the specific attributes to be modified ('usage limit, expiry time, or validity'). This distinguishes it from sibling tools like create/delete/list.
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 this tool is for modifying existing tokens ('existing registration token'), but it does not explicitly mention when to use it over alternatives or when not to use it. No exclusions or comparisons to sibling tools are provided, though the context is reasonably clear.
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?
The word 'permanently' discloses irreversibility, which is a key behavioral trait for a delete operation. However, it does not mention other traits like authentication requirements, idempotency, or what happens if the token does not 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 a single, well-structured sentence that immediately conveys the action. No wasted words.
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 simple delete tool with one parameter, the description covers the core action and permanence. However, it lacks parameter clarification and usage context, making it minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'token' with 0% description coverage, and the description does not explain what the parameter represents (e.g., token ID vs. token string). The description fails to compensate for the low 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 verb (delete) and resource (registration token), and is distinct from the sibling tools like create/update/list/get. The phrase 'permanently delete' adds specificity.
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?
There is no guidance on when to use this tool versus alternatives (e.g., update instead of delete). No prerequisites, consequences, or scenario context are provided.
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 indicates a read-only operation ('Fetch'), which is a useful safety signal, but it does not disclose error behavior, required permissions, or what 'details' includes. The vagueness of 'details' leaves some behavioral aspects unspecified.
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 one concise sentence that immediately conveys the action and object. Every word contributes value, with no redundancy or filler.
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?
The tool is simple (one parameter, no output schema), but the description is vague about what 'details' are returned and does not cover possible error conditions or output format. While adequate as a minimal description, it leaves significant gaps given the absence of an output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'token' with no description, and schema description coverage is 0%. The description does not explain the meaning or format of the token parameter; it merely repeats the word 'token' without clarifying whether it is an ID, the token string itself, or how it should be provided. It fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource as 'details of a single registration token', clearly distinguishing it from sibling tools like list_registration_tokens, create_registration_token, and delete_registration_token. It unambiguously states the action and scope.
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 this tool is for fetching one specific registration token, but it does not explicitly state when to use it versus list_registration_tokens or provide any exclusions or alternative recommendations. Usage context is inferred from the word 'single' 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.
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 does reveal the authentication mechanism (shared secret) and clarifies that the admin token is not used. However, it does not describe what happens after creation (e.g., whether the user is immediately active, whether errors occur if the username already exists, or what the response format is). This is a notable gap for a create operation.
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 concise sentences, with the primary action front-loaded in the first sentence. The second sentence adds necessary context about configuration and authentication. No filler words or redundancy; every word contributes.
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 that there is no output schema and no annotations, the description should explain return values and potential errors, but it doesn't. It provides essential context about the registration flow and prerequisites, which is valuable, but it omits information about what a successful or failed invocation yields. For a relatively simple create-user tool, this partial completeness is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is only 50% (username and admin have descriptions; password and displayname do not), and the description adds no parameter-specific guidance. It doesn't explain the purpose of 'admin', 'displayname', or the semantics of 'password' beyond their basic types. The description could have elaborated on these parameters but instead focuses solely on the authentication flow.
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 states a specific action: 'Create a new local account' using Dendrite's shared-secret registration flow. It clearly identifies the resource (a user account) and the method, distinguishing it from sibling tools like create_registration_token which manage tokens, not users.
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 when to use this tool: it requires the shared-secret registration flow and DENDRITE_REGISTRATION_SHARED_SECRET to be configured. It also notes that it does not use the admin bearer token, implying it should be used when shared-secret auth is appropriate. However, it doesn't explicitly enumerate exclusions or name alternative tools for user management.
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 mutation (setting a new password) and the optional side effect of invalidating tokens, but it omits required permissions, irreversibility, session impact, or response behavior. The coverage is partial but not comprehensive.
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, front-loaded sentence with no unnecessary words. It directly states the action and the optional parameter effect.
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 too sparse. It doesn't mention whether admin authorization is required, what happens to active sessions (beyond optional token invalidation), or what the API response will be. This is a significant gap for a destructive 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 100%, so baseline is 3. The description adds the 'local user' constraint, which is not explicit in the schema's userId description, clarifying that remote users are not supported. This adds meaningful value beyond the schema.
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 uses the specific verb 'Set' with the resource 'new password for a local user', and also mentions the optional side effect of invalidating access tokens. This distinguishes it from sibling tools like register_user or refresh_devices.
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 states the scope ('for a local user') but does not explicitly provide when-to-use compared to alternatives or mention prerequisites like admin permissions. While the context is clear, there is no explicit guidance or exclusions beyond the local-user constraint.
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, the description carries the full burden. It states the core action but omits side effects, permissions required, reversibility, or impact on rooms. Given this is a destructive operation (parting a user from all rooms), more transparency is needed.
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, front-loaded sentence with no unnecessary words. It efficiently conveys what the tool does.
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?
The tool has one simple parameter and no output schema, so a brief description might suffice. However, the description lacks any mention of success/failure behavior, prerequisites, or edge cases (e.g., user not in any rooms). It is minimally adequate but could be more complete.
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 schema covers 100% of the parameter ('userId' with a description of the fully-qualified ID). The tool description adds the 'local user' constraint, clarifying that the userId must correspond to a local user, which is not explicit in the schema. This adds meaningful 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 action ('Part a local user') and the scope ('from every room they are currently joined to'). It is specific and distinct from the sibling tool 'evacuate_room', which presumably operates on a room rather than a user.
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: this tool is for local users and affects all memberships. It implicitly indicates when to use it (when a user needs to be removed from all rooms), and the 'local user' qualifier implicitly excludes remote users. However, it does not mention alternative tools or explicitly state when not to use it.
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 must carry the behavioral burden. It indicates a non-destructive read operation ('Retrieve') but does not disclose error behavior, whether multiple sessions are returned, or any side effects. Since the description merely restates the title with a bit more specificity, it adds limited behavioral context.
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 sentence that is concise and front-loaded, containing no filler. It efficiently conveys the tool's purpose without unnecessary detail.
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 (one parameter, no output schema), the description gives the basic purpose but does not explain the return value format or any potential edge cases. Since there is no output schema, the description should provide more clarity on what 'connection/session information' entails, making it slightly incomplete.
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 has full coverage of the single parameter 'userId' with a clear description. The tool description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies.
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 retrieves connection/session information for a given user, using a specific verb and resource. It distinguishes itself from sibling tools, which focus on tokens, room management, and user administration, by targeting session 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 implies when to use this tool (to look up a user's sessions) but does not explicitly mention alternatives or exclusions. Given the sibling tools, the context is clear enough that this is the session lookup tool, but it lacks explicit 'use when' or 'not for' guidance.
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 full burden. The verb 'Fetch and return' implies a read-only operation, but it does not explicitly state that no changes are made, whether it requires special permissions, or any potential side effects (e.g., network calls, latency). It is adequate but not transparent about behavioral nuances beyond the obvious read.
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 main action, and includes a concise use case. Every sentence earns its place with no wasted words.
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?
The tool has only 2 parameters, no output schema, and no annotations. The description covers the purpose, the object being fetched, and the typical use case (debugging). It lacks a note on the return format, but for a tool that simply fetches state, the description is largely adequate. Slightly more could be said about response structure, but it is not critically incomplete.
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%: both parameters (roomId, serverName) are fully described with examples in the schema. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
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 'Fetch and return the room state for a given room as seen by a specific federated server.' It uses specific verb and resource ('room state'), and distinguishes itself from all sibling tools, which are about tokens, user admin, or room management actions like purge/evacuate.
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 usage context: 'Useful for debugging state resolution and federation issues.' This clearly implies when to use it, but it does not explicitly contrast with alternatives or state exclusions. Since no sibling tool serves a similar purpose, this is sufficiently clear.
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, the description carries the transparency burden. It discloses the scope of the reindex and warns that it can be expensive, which is useful. However, it does not mention potential side effects (e.g., blocking, performance impact beyond cost) or whether the operation is reversible or asynchronous, leaving 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, information-dense sentence. It front-loads the action, specifies the affected event types, and adds a relevant warning—every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter trigger with no output schema, the description provides the essential purpose and a key caveat. It could mention what the expected result or return value is, but the description is sufficiently complete for an agent to use it correctly in most cases.
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 zero parameters, so the schema coverage is trivially 100%. The description does not need to explain parameters. According to the rubric, a baseline of 4 applies for 0 params, and there is nothing to penalize.
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 action ('Trigger a reindex') and specifies the exact resources affected ('all searchable events' and the three event types). It distinctly describes a maintenance operation that has no siblings, so it is 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?
Usage is implied but not explicit. The description does not state when to use this tool versus alternatives, nor does it provide when-not-to-use conditions. The warning about cost hints at caution but does not provide concrete guidance on appropriate scenarios.
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 must carry behavioral disclosure. It clarifies the read-only nature via 'List' and the filtering behavior by validity, which adds context beyond the schema's bare type. However, it does not mention pagination, return format, ordering, or access requirements.
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?
One short sentence with a clear subject and optional filter, no filler. It is front-loaded and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional boolean parameter and no output schema, the description provides sufficient scope. It could be slightly enhanced by naming alternatives or mentioning default behavior, but it is adequate for the tool's complexity.
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 single 'valid' parameter is fully described in the schema with 100% coverage. The description reinforces that 'valid' refers to token validity status, but adds no new syntax or formatting details, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'registration tokens' and qualifies with an optional validity filter. This clearly distinguishes it from sibling get/create/update/delete operations.
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?
It clearly states the tool lists registration tokens and can filter by validity, making the list context apparent. It does not explicitly contrast with get_registration_token or state when to prefer this over alternatives, but the list-vs-single distinction is implicit.
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 for behavioral disclosure. It does reveal a key behavior: omitting 'token' triggers random generation. However, it does not mention permissions, side effects, or return value, which are relevant for a create operation. This is adequate but not rich.
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 deliver the purpose and key usage guidance without waste. The most important information is front-loaded, making it easy to scan.
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 create tool with no output schema and no annotations, the description gives the core purpose and generation behavior but omits what the response looks like, whether there are permission requirements, or how this integrates with other token operations. While not incomplete enough to be unusable, it leaves some contextual gaps.
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 100%, so the baseline is 3. The description adds semantic value by explaining the relationship between omission of the 'token' parameter and random generation, which is beyond what the schema explicitly states. This elevates it to a 4.
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 starts with 'Create a new registration token', giving a specific verb and resource. It further clarifies the token's purpose ('gate new-account registration'), which distinguishes it from sibling tools like list/get/update/delete_registration_token.
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: this tool is for creating tokens to gate registration. It also gives a usage hint about omitting 'token' to generate a random one. However, it does not explicitly mention when to use this tool over alternative sibling tools or any exclusions, so it stops short of a full 5.
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. It discloses critically important behavior: irreversibility and non-deletion of associated media. This goes beyond a basic mutation description. However, it doesn't mention permission requirements or other potential side effects, so it's not exhaustive but strong.
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 primary action and then essential caveats. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers all essential aspects: what is removed, what is not removed, and the irreversible nature. This is complete enough for an agent to safely select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with roomId already described as 'Room ID, e.g. !abc123:example.com'. The description adds no new parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.
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 action: 'Remove a room and all its events from Dendrite's database.' This is specific with a verb and resource, and it distinguishes purge_room from siblings like evacuate_room, which likely only moves users, not deletes the room. The scope is 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 use for permanent room deletion but does not explicitly state when to use this versus alternatives like evacuate_room. No exclusions or alternative tool names are mentioned, leaving the agent to infer the intended use case.
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 transparency burden. It discloses the mechanism (immediate network query, cache refresh) and that it affects cached device/cross-signing keys. However, it doesn't specify whether the operation is safe/idempotent, what happens if the remote server is unreachable, or any permission requirements.
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 action and purpose. Every sentence earns its place: the first explains what the tool does, the second clarifies when to use it. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description plus schema fully cover purpose, action, parameter, and use case. The description's mention of caching and encryption issues provides enough context for an agent to select 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?
The schema provides 100% coverage for the single required userId parameter, including an example (@bob:otherserver.com). The description itself adds no additional parameter semantics, so it relies on the schema, which is complete. Baseline 3 is appropriate.
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 states a specific action ('query... and refresh...') on a clear resource ('federated user's /devices endpoint'), and the purpose is further clarified with a concrete use case ('resolving encryption issues'). This distinguishes it from all sibling admin tools, which target registration tokens, room state, or user evacuation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('Useful for resolving encryption issues with remote users'), giving a clear contextual trigger. It doesn't mention alternatives or exclusions, but no sibling tool serves the same purpose, so the guidance is adequate.
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 burden. It discloses the message format and configuration requirement but omits other behavioral traits like admin permissions, potential side effects (e.g., room creation), or error behavior. This is a moderate disclosure 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, no wasted words. The action and target are front-loaded, followed by the configuration prerequisite.
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 simple tool with two parameters and no output schema, the description gives essential context but lacks information about who can invoke it (e.g., admin only) and what happens on failure. It is minimally sufficient but not fully comprehensive.
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 schema already has 100% parameter description coverage. The description adds value by specifying that the user must be a 'local user' and clarifying the server-sourced nature of the m.text message, which goes beyond the schema's generic 'Fully-qualified user ID' phrasing.
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 action (send a server notice), the target (a specific local user), and the message type (m.text). It distinguishes from sibling tools focused on registration tokens and room operations.
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?
It provides a concrete prerequisite (server notices configured in dendrite.yaml) which helps define when the tool is usable. However, it does not explicitly discuss alternatives or when not to use the tool, but the sibling domains are distinct enough to make context clear.
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, the description carries the burden of behavioral disclosure. It explicitly states that the operation parts all local users, which is a destructive action, and clarifies that only local members are affected. It does not mention permissions or reversibility, but the core behavior is transparent enough for this simple 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 two sentences, front-loaded with the action and followed by a practical use case. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description covers the purpose, scope, and a motivating scenario. It does not explain return values or prerequisites, but these are not critical for such a straightforward operation, making it adequately complete.
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 fully covers the single parameter `roomId` with a description and format example, achieving 100% schema_description_coverage. The description adds no additional parameter-level semantics, so the baseline of 3 is appropriate.
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 action with a specific verb ('Part') and resource ('all local users from a room'), which is distinct from sibling tools like evacuate_user (likely targeting a single user) and purge_room (likely removing the room entirely). The scope is unambiguous.
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 a clear usage context ('when a room is stuck and needs every local member removed at once'), giving the agent situational guidance. However, it does not explicitly mention when not to use it or name alternative tools such as evacuate_user or purge_room, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![dendrite-admin-mcp MCP server](https://glama.ai/mcp/servers/niels-emmer/dendrite-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/niels-emmer/dendrite-admin-mcp)

Score Badge

Copy to your README.md:

[![dendrite-admin-mcp MCP server](https://glama.ai/mcp/servers/niels-emmer/dendrite-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/niels-emmer/dendrite-admin-mcp)

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/niels-emmer/dendrite-admin-mcp'

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