openrouter-admin-mcp

Server Quality Checklist

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

Latest release: v0.7.3
Disambiguation4/5
Each tool targets a specific resource or view (models, keys, guardrails, usage), and the overview tool is purposefully distinct as a dashboard. The only potential confusion is between or_models_user and or_models, but descriptions clarify account-specific vs public catalog.
Naming Consistency2/5
All tools use the or_ prefix, but beyond that the naming is inconsistent: list/get suffixes appear on some resources but not others, and or_models_user reverses the expected resource-modifier order. This mixing of conventions requires careful reading to infer the pattern.
Tool Count4/5
16 tools is at the upper edge of the ideal range. Each tool covers a distinct read operation, so none feels redundant, but the count is slightly heavy for a server that only provides administrative reads.
Completeness2/5
The set is heavily skewed toward read-only operations: models, keys, guardrails, and usage can be queried, but there are no create, update, or delete operations for any resource. Given the 'admin' label, the lack of key/guardrail management actions is a significant gap.
Average 4/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims 'grouped by endpoint' but the input schema's aggregate enum does not include any endpoint grouping, with 'none' as the default representing raw rows. This contradiction makes the description misleading. It also fails to clarify how the 'date' filter interacts with the fixed 30-day window and does not disclose default limits or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but its brevity comes at the cost of omitting essential information and introduces an inaccuracy. The sentence about filters partially earns its place but is incomplete.
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?
With five optional parameters and no output schema, the description should explain defaults, aggregation behavior, and result format. It only covers a subset of filters and does not mention the 'limit' or 'aggregate' parameters, making it incomplete for a tool this complex.
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?
Although schema description coverage is 100%, the description only lists three of the five parameters and omits 'limit' and 'aggregate'—the latter being critical to the stated grouping behavior. It adds no new meaning beyond the schema and partially contradicts the schema's aggregation options.
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 shows OpenRouter usage grouped by endpoint for the last 30 UTC days, using the verb 'Show' and specifying the resource and scope. This distinguishes it from sibling tools like or_overview and or_generation, which likely cover different aspects.
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 viewing recent activity but provides no explicit guidance on when to use this tool instead of siblings or any exclusions. It mentions optional filters but does not explain their mutually exclusive or complementary nature.
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 operation as listing (a read operation) and specifies that usage and limits are included, but it does not mention pagination behavior, default inclusion of disabled keys, or whether any side effects are possible. The verb 'List' suggests safety, but explicit declaration is absent.
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, concise sentence with no redundant phrases. It is front-loaded and every word contributes to the meaning.
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 with optional parameters and no output schema. The description covers the core purpose but lacks details on response structure and pagination behavior, which are important for a listing operation. Since no output schema exists, the description could have provided more context about return formats.
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 both parameters (offset, include_disabled) already described in the input schema. The description adds no extra 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 uses the specific verb 'List' with the resource 'OpenRouter inference API keys', adding scope 'all' and content 'usage and limits'. This clearly differentiates it from sibling tools like or_key_get (single key retrieval) and or_current_key (current key).
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 such as or_key_get or or_current_key. The description only states what the tool does, leaving the agent to infer appropriate usage without explicit context 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 burden for behavioral transparency. It does describe the return content (description, context, modalities, etc.), which gives the agent a sense of what to expect. However, it does not mention that the operation is read-only, whether any authentication is needed, or any rate limit/error behaviors. It adds some value but lacks richer disclosure expected for an unannotated 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 leads with the verb ('Get') and resource ('full details of a single model by id'), followed by a concise enumeration of returned fields. Every word adds value, and there is no redundancy or filler.
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 simplicity (1 parameter, no output schema) and the absence of annotations, the description adequately conveys the tool's purpose and return content. It is missing some contextual guidance, such as when to use this versus sibling list tools, but it provides sufficient information for the agent to select and invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'id' parameter with the same example ('anthropic/claude-opus-4.7') and states it is the model id. The tool description repeats this information but does not add new meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate; the description offers no extra parameter semantics.
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 fetches full details for a single model by id, listing exact returned fields (description, context, modalities, pricing, supported parameters). This distinguishes it from sibling tools like or_models (likely a list) and or_model_endpoints (likely endpoints), so the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Get full details of a single model by id' implies the use case of retrieving detailed information when a specific model id is known. However, it does not explicitly mention when to prefer this tool over siblings (e.g., or_models for listing) or provide any exclusion criteria. Usage is implied rather than explicitly stated, so a score of 3 is appropriate.
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 burden. It indicates a read-only operation ('Show') and specifies the metadata contents, but it does not disclose any permissions, side effects, or error conditions. For a simple read 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?
The description is a single, front-loaded sentence that states the action and key details without any filler. Every word contributes value.
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 has no parameters and no output schema, the description sufficiently explains its purpose and the metadata it returns. However, it could further clarify that it requires no arguments or that it reflects the currently active key, though the tool name and context cover this. Overall, it is nearly complete for its simplicity.
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, and the schema is an empty object, so the description need not elaborate on parameter semantics. The baseline for 0 params is 4, and the description adds no unnecessary parameter information.
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 shows metadata for the current Provisioning key and lists the specific metadata fields. The verb 'Show' and resource 'Provisioning key' are specific, and the phrase 'the server is using' distinguishes it from sibling tools like or_key_get that target specific keys.
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 by the description: the tool is for retrieving the server's current provisioning key metadata. However, there is no explicit comparison to alternatives or guidance on when not to use this tool versus or_key_get or or_keys_list.
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. 'Get details' implies a read-only operation, which is supported by the context. It discloses the fields returned, but does not mention potential error cases (e.g., invalid id) or authentication requirements. For a simple get, this is adequate but lacks depth.
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 action and resource, then lists the return fields. Every word earns its place, with no filler 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?
For a simple get tool with one parameter and no output schema, the description is fairly complete. It explains what it does, what parameter to use, and what fields are returned. It does not explain error behavior, but that is less critical given the simplicity. Siblings provide context for differentiation.
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%, and the schema parameter description ('Guardrail id from or_guardrails_list') already defines the parameter well. The tool description adds only 'by id' which is redundant. Thus the description adds minimal value beyond the schema, so 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 starts with a specific verb 'Get' and resource 'details of one guardrail by id', clearly distinguishing from siblings like or_guardrails_list (list all) and or_guardrails_assignments. It also lists the specific fields returned, making the purpose unmistakable.
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 clearly indicates this tool is for fetching details of a single guardrail, with the id from the list. It implicitly differentiates from or_guardrails_list (for listing all) and assignments. However, it does not explicitly mention when not to use it, but the context is fairly clear without 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 of disclosure. It states the operation is a list and defines guardrails, but does not mention output format, pagination, errors, or authentication requirements. For a simple list tool, this is adequate but has clear 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 sentence, front-loaded with the action 'List', and includes a helpful parenthetical clarification. Every word earns its place with no 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 simplicity (0 params, no output schema, no annotations), the description adequately conveys the purpose and scope. It could benefit from explicitly stating the return format or noting edge cases, but is otherwise complete for typical use.
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 baseline is 4. The description does not need to add parameter information, and the schema already reflects no inputs.
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 'List' and the resource 'OpenRouter guardrails', with a parenthetical defining the scope (account-wide spending limits and allowlists). This distinguishes it from sibling tools like or_guardrail_get (specific guardrail) and or_guardrails_assignments (assignments).
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 word 'all' implies this tool is for retrieving the complete set of guardrails, and the parenthetical clarifies what guardrails are, giving some context. However, it does not explicitly mention alternatives or when not to use this tool, so guidance is only implied.
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 burden. The verb 'Get' implies a read-only operation, which is minimally transparent, but it does not disclose potential error behaviors (e.g., missing hash, not found) or prerequisites. For a simple get, this is adequate but sparse.
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, focused sentence with no redundancy. It is front-loaded and contains exactly the needed information without waste.
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 (one parameter, no nested objects, no output schema), the description and schema together provide enough context. The term 'details' is vague but acceptable for a straightforward get operation. Sibling names help clarify scope.
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 covers 100% of parameters, including a clear description for 'hash' ('Key hash from or_keys_list'). The tool description simply echoes 'by hash' without adding meaningful new information, 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 uses a specific verb ('Get') and resource ('details of one OpenRouter inference key'), and specifies the method ('by hash'). This clearly distinguishes it from sibling tools like or_keys_list (which lists keys) and or_current_key (which gets the current key).
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 when you have a specific key hash, and the parameter schema notes the hash comes from or_keys_list. However, it does not explicitly mention alternative tools or exclusions, though the context is clear for a single-key lookup.
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. 'List' implies a read-only operation, and the description adds valuable context about the fields returned (pricing, context length, uptime). However, it does not explicitly state side-effect-freedom, authentication needs, pagination, or rate limits, leaving some ambiguity.
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 exceptionally concise: a single top-level sentence with a clarifying parenthetical and a separate usage sentence. Every word earns its place, and the most important information (what it lists) is front-loaded.
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 2-parameter list tool with no output schema, the description adequately covers the tool's scope and return fields. It lacks explicit notes on read-only behavior or pagination, but the provided use case and data field enumeration make the tool's operation clear enough for most scenarios.
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 already provides full descriptions for both parameters (slug and author) with examples, resulting in 100% schema coverage. The tool description adds no additional parameter-level detail, 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 uses a specific verb ('List') and clearly identifies the resource ('provider endpoints for a specific model'), enumerating the key returned fields (pricing, context length, uptime). This distinguishes it from sibling tools like or_model_get (which likely returns model metadata) and or_zdr_endpoints (which targets a different endpoint type).
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 includes a clear use case: 'Use this when picking the cheapest or most-stable provider for a model.' It does not explicitly mention when not to use the tool or name alternative tools, so it falls short of a 5, but the guidance is concrete and actionable.
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 itself must convey behavior. It states 'List' (implying read-only) and identifies the filtered fields, but it does not disclose potential pagination, response structure, authentication requirements, or whether the listing is complete or capped. Adds some value beyond schema, but leaves 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?
Two tight sentences: first announces the listing and its content, second gives usage and filter mechanism. No filler or repetition of schema elements. Every word serves a purpose.
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 covers the essential aspects: what the tool lists, the key fields (pricing, context length, modalities), when to use it, and how to filter. Lacks only minor operational details like default sorting or pagination, but is complete enough for a catalog listing 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?
Input schema descriptions cover 100% of the parameters, so baseline is 3. The description only mentions the parameter names ('search/supported_parameters/output_modalities') without adding operational details like OR-side semantics, but the schema already communicates this. No extra semantic value added.
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 a specific verb+resource: 'List OpenRouter model catalog' and gives concrete included fields ('pricing per 1M tokens, context length, and modalities'). This clearly distinguishes it from siblings like or_model_get (single model) and or_models_user (user-specific view).
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?
Provides clear usage context: 'Use this to compare models or look up current prices.' It does not explicitly mention alternatives or when not to use this tool, but the stated purpose is enough to guide selection among nearby siblings.
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 burden of behavioral disclosure. It discloses the key prerequisite (Management key for org account) and implies a read-only operation via 'List.' However, it does not describe error behavior for non-management keys, rate limits, or pagination details beyond the schema, leaving some behavioral aspects unaddressed.
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 every clause adds value. It states what the tool does, the operational condition, and a practical use case without redundant information.
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 tool with two optional pagination parameters and no output schema, the description covers the essential context: purpose, prerequisite, and use case. It does not detail the return format, but the operation itself implies a list of members, and the schema handles pagination. The description is nearly complete for its 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?
Schema coverage is 100%, with both 'limit' and 'offset' having clear descriptions. The tool description adds no parameter-specific meaning, but the schema already documents the parameters well. Thus, the baseline score 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's purpose: 'List members of the OpenRouter organization' with a specific verb and resource. It also distinguishes this tool from siblings by adding the contextual condition 'when running under a Management key for an org account' and notes its relevance to guardrail member-assignments, which aligns with sibling tools like or_guardrails_assignments.
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 usage context: it only applies when running under a Management key for an org account, and it is 'useful as input for guardrail member-assignments.' This implies when to use it, though it does not explicitly name alternative tools or state exclusions. The sibling list shows related guardrail tools, and the mention of guardrail member-assignments helps differentiate and guide selection.
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 key behavioral traits: it combines multiple data sources, is a 'one-shot' call (no pagination implied), and uses 'today's UTC burn' (timezone-specific). However, it does not explicitly state that the operation is read-only, potential volume implications of 'all active keys', or any authentication requirements, leaving some ambiguity.
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 concept ('One-shot dashboard'), and every clause adds value: the content list, the timezone, and the usage recommendation. 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?
Despite having no output schema or annotations, the description provides a solid overview of what to expect: credits, keys with reset info, and burn by model. It specifies the exact components returned and the intended use case. It does not detail formatting or nesting, but for a combined dashboard, this is adequate.
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 takes zero parameters, and the schema covers this completely (100% coverage). With no parameters to describe, the description adds no parameter-specific semantics, but the baseline for 0-parameter tools is 4, which 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 tool's purpose as a 'One-shot dashboard' that combines account credits, active keys with reset info, and today's UTC burn by model. This specific verb+resource structure distinguishes it from sibling tools like or_credits, or_keys_list, and or_activity, which each focus on a single resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this first when investigating cost or checking key health,' providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools for narrower queries, so it stops short of full when/when-not 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?
With no annotations, the description carries the burden. 'List' implies a read-only operation, and the explanation of ZDR adds context. However, it does not disclose any potential caveats such as authentication requirements, pagination, or whether the list is comprehensive or filtered, which would be useful for the agent.
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 states the purpose and expands the acronym without any filler. It is front-loaded with the action and resource, making it immediately scannable and efficient.
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 zero-parameter tool with no output schema, the description covers purpose and usage context sufficiently. It could mention the return format (e.g., list of endpoints) or any access prerequisites, but given the simplicity, the description is mostly complete. The use case guidance adds important context beyond the bare action.
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?
There are zero parameters and the schema coverage is vacuously 100%. The description does not need to explain parameter meanings, and the baseline for zero-parameter tools is 4. No additional information is required.
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 verb 'List' with the resource 'ZDR-compliant model endpoints', clearly stating the action and scope. The parenthetical expansion of the acronym adds precision, and the ZDR-compliance qualifier distinguishes this tool from siblings like or_model_endpoints.
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 phrase 'Useful for agents under privacy/compliance constraints' provides explicit context for when to use the tool. It does not mention alternatives or exclusions, but the sibling list implies a contrast with general model endpoint listings, so the guidance is clear enough.
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 discloses the return fields and the source of the generation_id, which conveys that this is a read-only lookup. It does not mention error cases or auth requirements, but for a simple retrieval tool this is sufficient.
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 sentences, front-loaded with the action and resource. Every sentence adds value: the first defines the operation and the identifier, the second lists the returned data and a concrete use case. No wasted words.
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 single-parameter lookup tool with no output schema, the description is complete: it names the input, explains where the input comes from, and lists the return fields. Sibling tools are not confused with this tool. No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the single parameter, including the example 'gen-abc123'. The description reinforces that the ID is returned by OpenRouter but adds little beyond the schema. 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 opens with a specific verb and resource: 'Get details of a single inference call by its generation_id.' It clearly distinguishes itself from sibling tools by targeting a single call identifier and listing the exact details returned (cost, tokens, latency, finish reason, provider).
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 use case: 'useful when an agent needs to explain why a specific call cost what it did.' It does not explicitly name alternative tools for other scenarios, but the context is unambiguous for a single-generation lookup.
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 that this is a one-shot view (read operation) and what data it combines, but doesn't describe return format, pagination, or any edge cases. For a simple read tool, 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?
The description is a single, well-structured sentence that front-loads the key concept 'One-shot view' and immediately explains what it covers. Every word earns its place, with no unnecessary 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 zero-parameter read tool with no output schema, the description fully explains what the tool does: it shows all guardrail assignments, covering keys and members, and mentions it combines two endpoints. This is complete for the tool's simplicity.
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, and the schema confirms this with 100% coverage. Per the rules, a baseline of 4 applies for tools with no params. The description adds no parameter information because none exists, but it doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: "One-shot view of all guardrail assignments: which keys and which org members are bound to which guardrail." It differentiates from sibling tools like or_guardrails_list (which lists guardrails themselves) and or_guardrail_get (which fetches a single guardrail) by focusing on assignments.
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 noting it combines two endpoints, suggesting it is the comprehensive view for assignments. It doesn't explicitly mention when not to use it, but the purpose is specific enough to distinguish it from alternatives. Clear context, though no explicit exclusions.
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. The verb 'Show' clearly indicates a read-only operation, and listing the returned fields (purchased, used, remaining) discloses the expected output. It does not mention authentication or errors, but for a simple zero-parameter read tool, this is adequate.
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, compact sentence that leads with the action verb and resource, followed by a colon and a list of returned fields. Every word adds value, with no redundancy or extraneous detail.
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?
Given the tool's low complexity (no parameters, simple read operation) and lack of an output schema, the description is sufficiently complete: it plainly states what the tool does and what it returns. No additional context is needed for an agent to use it correctly.
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 zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Show') and resource ('OpenRouter balance'), and enumerates the three components returned (purchased, used, remaining). This distinguishes it from sibling tools such as or_overview or or_activity, which relate to other OpenRouter 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 when to use the tool: to view the OpenRouter balance. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident and no competing tool appears to serve the same specific function.
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?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait that the list respects privacy/guardrail settings, meaning results are filtered by account permissions and guardrails. This is valuable context beyond a simple 'list' operation, though it omits details like pagination or response format, which are less critical for a read-only listing 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, front-loaded sentence that immediately states the action and resource, then adds the differentiating caveat. Every word earns its place, and the structure is highly efficient.
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, param-less list tool, the description provides sufficient context: it explains the scope (account-specific), the behavioral filtering (privacy/guardrails), and how it relates to the sibling or_models. Without an output schema, it does not explicitly describe the return format, but that is a minor gap for a list operation, and the overall guidance is complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero input parameters, so the baseline is 4 per the rubric. The schema is empty, and the description correctly does not attempt to describe nonexistent parameters. No additional parameter semantics are needed.
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' and clearly identifies the resource as 'models available to this account', with the parenthetical explicitly differentiating it from the sibling 'or_models' which returns the full public catalog. This makes the purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context by stating that this tool differs from or_models: it respects privacy/guardrail settings and returns only account-available models, while or_models returns the full public catalog. This directly tells an agent when to choose this tool over the named alternative.
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:

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

Score Badge

Copy to your README.md:

[![openrouter-admin-mcp MCP server](https://glama.ai/mcp/servers/oviron/openrouter-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/oviron/openrouter-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/oviron/openrouter-admin-mcp'

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