relative-interpreter-mcp

Server Quality Checklist

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

Latest release: v0.0.0
Disambiguation5/5
Each tool targets a distinct resource and operation: scope management (get_scope, enter_submodel, exit_submodel), model inspection at different granularities (get_model, get_element, get_script_source), model lifecycle (create, select, import, delete, list), editing and execution (edit_model, run_node), validation, snapshots, and undo/redo. No overlapping purposes.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern, with plural nouns for list operations (list_models, list_snapshots) and clear imperative verbs. The only exceptions are undo and redo, which are universally accepted single verbs.
Tool Count4/5
With 20 tools, the set is on the heavier side but remains justified by the complexity of a model interpreter. Each tool has a clear role, and no redundant or trivial tools are present.
Completeness4/5
The core workflow is well-covered: model lifecycle, editing, navigation, validation, execution, and snapshots. Minor gaps exist—such as missing export_model and delete_snapshot—but agents can work around these with existing operations.
Average 3.5/5 across 20 of 20 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not describe what is returned (e.g., list of names vs. full objects), ordering, or any side effects, leaving the agent with minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It does not add meaningful information beyond the title, making its single sentence not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a clearer statement of the return value and scope would suffice. The current description omits any detail about what constitutes a 'model' in the result, making it incomplete for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already confirms this with 100% coverage. The description adds no parameter-specific meaning, but the baseline for zero-param tools is 4, so this is satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Every model the service holds' is a noun phrase rather than an explicit verb phrase, effectively restating the title. It fails to distinguish this tool from siblings like get_model or create_model, which also relate to models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_model or select_model, and does not mention any context, exclusions, or prerequisites.
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 only discloses that the operation is itself undoable, which is helpful. However, it does not describe what restoration does to the current state, whether it overwrites data, requires specific permissions, or the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences. Each sentence adds some value: the first states the action, the second notes undoability. However, the first sentence essentially restates the tool name, so it earns its place only minimally.
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 simple tool with no annotations and no output schema, the description omits critical contextual information such as the effect of restoration, expected return, and relationship to current model state. This is insufficient for an agent to confidently invoke the tool in varied contexts.
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 (snapshotId) with 0% description coverage. The description does not explain the parameter's meaning or format. Although the parameter name is self-explanatory, the description 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Restore a snapshot' with a specific verb and resource. It does not explicitly distinguish from sibling tools like save_snapshot or undo, but the meaning is apparent. The phrase is somewhat tautological with the tool name, so it is clear but not exemplary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use restore_snapshot versus alternatives like undo or redo. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that snapshots are on-disk and named, and scopes them to the selected model, but does not disclose read-only behavior, return format, or side effects. This is minimal transparency for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (fragment) with no fluff or redundancy. It is concise and front-loaded with the key noun, though it could be a more complete sentence with a verb.
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 (no parameters, no output schema), and the description gives the essential context of on-disk and selected-model scope. However, it omits the explicit action and any indication of what the returned list contains, relying on the tool name for the verb.
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 has zero parameters, so there is nothing parameter-related to explain. Baseline for zero parameters is 4; the description does not need to compensate for missing schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description defines snapshots as 'named on-disk checkpoints' for the selected model, but does not explicitly state that this tool lists them. The verb 'list' appears only in the name/title, making the purpose somewhat vague, though the scoping to a selected model adds context.
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 like save_snapshot, restore_snapshot, or list_models. The phrase 'for the selected model' hints at a prerequisite but does not explain when listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Settle the reactive cascade' hints at cascading side effects but does not explain what those effects are, whether they are reversible, or what permissions are needed. It also does not mention the return value or any potential destructive/irreversible consequences, making it insufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the primary action ('Execute a function node's pipeline'). However, the second clause 'and settle the reactive cascade' is vague and potentially confusing, lowering the efficiency of communication. It is still structurally compact and uncomplicated.
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 two parameters, one required, and no output schema, the description should clarify what the tool returns, what side effects occur, and the meaning of the 'reactive cascade'. It does none of these, leaving the agent with insufficient context to predict the tool's full impact. The presence of nested objects in inputs makes this guidance even more critical.
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%, and each parameter has a description in the schema: 'node' as a string and 'inputs' as an object for overrides. The tool description adds no extra parameter-specific detail beyond the schema. Given full schema coverage, a baseline of 3 is appropriate, but no added value earns a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a function node's pipeline, using the verb 'Execute' and specifying the resource. The phrase 'settle the reactive cascade' adds a sense of broader side effects but is somewhat jargon-heavy, slightly obscuring the primary purpose. It distinguishes from sibling model-management tools, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only describes what it does, leaving the agent to infer the appropriate context from the name and sibling list. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the output is comprehensive, but it does not explicitly state read-only behavior, error conditions (e.g., not found), or any side effects. This is a significant gap for a getter 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, efficient sentence with no wasted words. It front-loads the core meaning and is appropriately sized for a simple getter tool.
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?
The tool has no output schema, no annotations, and many siblings. The description leaves 'outline' undefined and does not clarify how this getter differs from get_scope, get_model, or get_validation. It is not fully self-contained for an agent to choose and invoke confidently.
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 coverage is only 50% (ref is described, kind is not). The description adds little beyond the schema: it repeats the kind enum values ('node, link, or view') but does not explain the 'name#uuidprefix' format for ref or how to handle ambiguity. The description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (node, link, or view) and states it returns the full element rather than an outline summary. It distinguishes from sibling getters by specifying element types, though it lacks an explicit verb phrase.
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 'including everything the outline summarises away' implies use when full detail is needed, but it does not explicitly name alternatives or state when not to use this tool. The usage context is hinted rather than clearly defined.
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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only says 'redo the last operation,' without explaining side effects, reversibility, state mutation, or error behavior when no operation is available.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loading the action. However, the brevity borders on under-specification, though not to the point of being a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description is far from complete. It doesn't clarify 'selected model' or 'last operation,' nor does it mention any success/failure conditions or relationship to sibling tools like 'undo' or snapshots.
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 already covers everything (100% coverage vacuously). The description adds no parameter details, which is acceptable per the baseline 4 for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'redo the last operation on the selected model,' which clearly identifies the action (redo) and the target (last operation on the selected model). It is distinct from sibling 'undo' by inversion, but doesn't explicitly name any sibling or alternative.
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 about when to use this tool versus alternatives like 'undo' or 'restore_snapshot.' The description lacks any mention of prerequisites, such as a prior undo, or the context of the selected model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not explicitly state that the tool is read-only or mention error conditions (e.g., behavior when no model is selected). The description only lists output attributes, leaving safety and side-effect expectations implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the three key output fields. It is concise, but written as a noun phrase rather than a complete sentence, which slightly reduces clarity.
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 getter with no output schema, the description adequately covers the main return values. However, it lacks context on how to interpret 'editable' (the model or the scope?) and does not address potential error scenarios, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter semantics, and no parameter information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the scope-related information returned (selected model, submodel depth, editability), providing a specific resource and output details. However, it lacks an explicit verb and does not distinguish itself from sibling tools like get_model or enter_submodel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It simply lists the output attributes without any context about situations where get_scope is appropriate, such as checking current state before entering or exiting a submodel.
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 bears full responsibility for disclosing behavior. It only states the core action and does not reveal side effects, limitations (e.g., undo stack depth), or behavior when no operation is available. The phrase 'last operation' implies one-step undo but is too terse 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 concise sentence with no filler. It is well-structured and easily parsed, using specific language without redundant phrasing.
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, no-output-schema tool, the description is adequate for basic understanding. It captures the essential behavior, but omits edge cases like empty undo stack or which 'selected model' scope applies. Given the simplicity, this is nearly 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 tool has zero parameters, so the schema is trivially complete. Per calibration, a baseline of 4 applies. The description does not need to add parameter details, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('undo') and the target ('the last operation on the selected model'), making the purpose unambiguous. It does not explicitly contrast with sibling tools like 'redo', but the meaning is distinct enough from the name and context.
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 given about when to use this tool versus alternatives such as 'redo' or other model operations. Prerequisites like having a selected model or an undoable operation are not mentioned, leaving the usage context unclear.
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 state 'read-only,' which is a useful trait, but it does not mention return format, error behavior, or any prerequisites. This is minimal added value beyond the obvious 'get' semantics.
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 phrase with every word earning its place. It is appropriately sized for a simple getter tool and contains 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?
For a tool with one parameter, no output schema, and no annotations, the description sufficiently conveys the core behavior: retrieving a function node's script source as a read-only operation. The return value is implied by 'script source,' and the parameter is fully covered by the schema. Minor gaps exist around domain context (what a function node is) but are not critical for a straightforward getter.
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 parameter scriptPath is already fully described in the schema with 100% coverage. The description adds no additional meaning about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning a function node's script source and explicitly marks it as read-only. While it lacks an action verb, the title 'Get script source' supplies the verb, and the description unambiguously distinguishes this from sibling tools like get_model or get_scope by focusing on script source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It neither states typical use cases nor mentions exclusions or related tools. The context signals show many sibling tools, but no differentiation is provided.
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 full responsibility for behavioral disclosure. It states the scope ('whole selected model') but does not mention whether the operation is read-only, what the findings contain, how they are formatted, or what happens if no model is selected. This is insufficient for a tool with no other safety indicators.
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 wasted words. It is front-loaded with the key concept ('Validation findings') and directly communicates the tool's purpose.
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 description is complete enough for a simple 0-parameter retrieval tool, covering the core purpose. However, without an output schema or annotations, it leaves gaps about the content and format of validation findings, and how they relate to the selected model. This is a minimum viable description but lacks context to fully guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema is empty. According to the guidelines, the baseline for 0 params is 4, and there is no parameter-level detail missing. The description adds no parameter semantics because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Validation findings for the whole selected model' clearly identifies the resource (validation findings) and scope (whole selected model), distinguishing it from sibling tools like get_model or get_element. The verb is omitted but implied by the tool name 'get_validation', so the purpose 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 usage via 'Validation findings' and 'selected model', indicating the tool is for retrieving validation results of the current model. However, it provides no explicit instructions on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only that the result is restorable, but omits behavioral details such as overwrite behavior with duplicate names, any prerequisites (e.g., a loaded model), and what the tool returns. This is insufficient for a tool with side effects.
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 is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description lacks essential context: it does not mention whether the snapshot overwrites an existing one, any required state, or what the tool returns. No output schema exists to supplement these details. As a result, an agent would have incomplete information to predict the tool's behavior.
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 no descriptions (0% coverage), so the description must compensate. The word 'named' in the description associates the 'name' parameter with naming the checkpoint, but does not elaborate on constraints or uniqueness. This provides minimal added meaning over 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 uses a specific verb ('save') and a clear resource ('named, restorable checkpoint'), making it distinct from sibling tools like restore_snapshot and list_snapshots. It clearly states the core function without ambiguity.
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 does not explicitly provide usage guidance or alternatives; it only states what the tool does. The context of when to use it (to create a checkpoint) is implied by the verb and the concept of a checkpoint, but no exclusions or comparisons to related tools are given.
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 core creation action and the fact that the new model is selected, which is a meaningful behavioral detail. However, it does not mention potential side effects like overwriting an existing model with the same name, error conditions, or what 'empty' means in terms of model contents.
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 filler or redundancy. Every word contributes meaning: 'create' indicates the action, 'empty' specifies the initial state, 'model' identifies the resource, and 'select it' conveys the post-condition. This is appropriately concise.
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?
While the tool is simple, the lack of annotations and output schema means the description alone must cover behavior, but it omits important contextual details such as return values, error handling, uniqueness requirements, and the broader workflow implications of creating and selecting a model. Given the sibling tools include get_model, delete_model, and edit_model, more context would help an agent choose and invoke this tool reliably.
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%, and the description adds no information about the 'name' and 'description' parameters beyond what the parameter names themselves imply. It does not explain uniqueness constraints, optionality of description, or any format expectations, leaving the agent to guess from bare property names.
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 'Create an empty model and select it' uses a specific verb ('create') and resource ('model') with the qualifier 'empty' that distinguishes it clearly from import_model (which creates from external data) and select_model (which selects an existing model). The action is unambiguous and immediately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a brand-new blank model and makes the side effect of selection clear, which helps distinguish it from siblings like import_model or edit_model. However, it provides no explicit 'when to use' or 'when not to use' guidance, nor does it reference alternative tools by name.
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 that the tool creates and selects a model, which implies mutation and side effects. However, it does not mention failure behavior, permissions, or whether it overwrites existing models, though the simplicity of the operation makes this less critical.
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 that directly states the purpose and expected outcome. No filler words or redundant information, making it optimally sized and 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 tool with one parameter and no output schema, the description adequately covers the main context: what the tool does (create from JSON), the input source (exported Relative JSON), and the result (selection). It could mention whether the operation is destructive, but given the simplicity, the current level is sufficient.
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 a full description for the only parameter ('A full Relative model JSON document') with 100% coverage. The description adds a minor nuance by saying 'exported', implying the JSON comes from an export function, but this is not a significant addition over 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 specifies 'Create a model from exported Relative JSON and select it', which clearly states the action (create), resource (model), and input source (exported Relative JSON). It also distinguishes from siblings like create_model (which likely creates a blank model) and select_model (which only selects) by including both creation and selection.
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 the use case (importing an exported Relative JSON document) but does not explicitly state when to use this tool instead of alternatives such as create_model or select_model. It provides context but lacks explicit exclusions or alternative 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 the burden. It discloses the session-scoped open and scope reset side effects, and that it returns an outline. However, it does not mention permissions, session lifetime, or whether opening affects unsaved changes.
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 front-loads the action and key side effect, with no unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the core action, scope reset, and return value. It could add session semantics or prerequisites, but for this complexity it is largely 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?
Schema covers 100% of the parameter descriptions, with modelId documented as 'Model id from list_models.' The description adds no additional parameter semantics, which is acceptable given complete 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 tool opens a model for the session, resets the scope to its root, and returns its outline. This distinguishes it from siblings like get_model and enter_submodel by specifying a session-level open action and a scope reset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to open a model and reset navigation scope, but it does not explicitly mention when to prefer this over alternatives or any exclusions. There is no direct guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It states the action is permanent and also deletes snapshots, which is critical safety-relevant information. However, it does not cover potential errors or permissions.
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 that front-loads the key action and scope without unnecessary detail.
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 low-complexity tool with one optional parameter and no output schema, the description provides the essential side effect (cascading deletion). It lacks details on return values or error handling, but these are not strictly necessary given the simplicity.
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 sole parameter is fully described in the schema (modelId with default behavior), so the description adds no additional parameter semantics. This meets the baseline for 100% 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 action (permanently delete) and the resource (a model and its snapshots), which is specific and distinguishes it from sibling tools like create_model, edit_model, or list_models.
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 permanent and cascading nature of the action, but no explicit when-to-use or when-not-to-use guidance is given, nor are alternatives mentioned.
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 full burden. It discloses the main behavioral trait (changing the working scope so reads/edits apply inside the submodel) but does not mention reversibility (e.g., exit_submodel) or potential nesting behavior. 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, focused sentence with no redundancy. It earns its place with the essential purpose and effect.
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 scoping tool, the description plus the schema sufficiently cover the operation's purpose and parameter. It could mention how to exit the scope, but given the sibling tool context, it remains mostly 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 schema has 100% coverage, providing the 'node' parameter description. The tool description adds no additional parameter meaning, so a 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 clearly states the action ('Scope into a submodel node') and the effect ('so reads and edits apply inside it'), distinguishing it from siblings like get_scope and exit_submodel. The verb is specific and the resource 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 clear context for when to use the tool: to operate inside a submodel node. It does not explicitly name alternatives or exclusions, but the context makes the use case evident.
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 full burden. It discloses a critical behavioral trait: the service validates paths against RELATIVE_EXTERNAL_ROOTS and refuses anything outside it. This adds meaningful context beyond the basic action, though it does not mention side effects, permissions, or return details.
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 tightly written sentences, front-loaded with the core action and followed by a key constraint. Every word earns its place, with no fluff or repetition.
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 has 4 parameters, no output schema, and no annotations, the description covers the core purpose and a critical restriction but is incomplete in some areas. It does not mention return values, failure behavior beyond path refusal, or any required permissions, leaving an agent to infer these from context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, so the description must partially compensate. The description clarifies 'ref' by explaining it points to an external model directory and is subject to an allowlist, adding meaning beyond the schema. However, 'name' and 'description' remain undocumented, and the description does not systematically address all parameters.
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 ('Add') and identifies the resource ('submodel node') with a clear qualifier ('backed by a model directory outside this one'). This distinguishes it from siblings like enter_submodel or create_model, which involve different 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?
The description provides clear context for when to use the tool (when linking an external model directory as a submodel). It does not explicitly name alternatives or provide when-not-to-use guidance, but the context is unambiguous enough for an agent to differentiate it from related tools.
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 explains the primary action and the depth parameter's meaning (0 = root), but does not disclose potential side effects, error conditions, or default behavior when depth is omitted. This is adequate for a simple navigation tool 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 two short sentences that front-load the primary action and then clarify the optional parameter. Every word earns its place; 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 (one optional integer parameter, no output schema, no annotations), the description provides adequate context: it states the action and the meaning of the parameter. It implicitly covers the default case (leaving one level) by saying 'Leave the current submodel' and treats depth as an optional jump. This is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for 'depth' by explaining that it jumps to a specific level and that 0 corresponds to root. This goes beyond the schema's bare min/max constraints, but could further clarify 'level' and default behavior without depth.
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 action: 'Leave the current submodel.' It also specifies the optional depth behavior, which distinguishes it from sibling tool 'enter_submodel'. The verb is specific and the resource is explicit.
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 the tool should be used: whenever you need to leave the current submodel. It does not explicitly name alternatives or exclusions, but the use case is self-evident and complementary to 'enter_submodel'.
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 description discloses key behavioral traits: changes are bundled as an undoable operation, steps execute sequentially, later steps can reference earlier creations, and unresolvable references cause rejection before any change is sent. This pre-validation guarantee ensures the edit never silently does nothing, which is valuable given no annotations are provided.
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?
Three sentences deliver the core purpose, batching guidance, and reference semantics without redundancy. Every sentence adds value, and the most critical information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (24 action types) and lack of an output schema, the description covers essential behavioral aspects: ordering, batching, reference resolution, and failure prevention. It leaves detailed action-specific semantics to the schema enum, which is acceptable, but could benefit from a brief example or mention of how path/modelId scoping works.
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 describes path and modelId but leaves steps undocumented. The description compensates by explaining how step references work ('Switch' or 'Switch.out') and the resolution/rejection behavior, adding crucial semantics for constructing valid steps.
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 applies one or more changes as a single undoable operation, identifying both the verb ('apply') and resource (changes to a model). This distinguishes it from sibling tools like create_model or delete_model, which handle different lifecycle 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 advises batching all known changes into one call and explains that steps apply in order, establishing clear usage context. However, it does not explicitly mention alternatives or when not to use this tool, only implicitly distinguishing it from create/delete operations.
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 that the output is a 'compact outline' and that submodels are not expanded—useful behavioral context. It does not explicitly state whether the operation is read-only, but the 'get' verb and the nature of the output strongly imply it. It adds meaningful detail beyond the title.
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 output summary and then a clear limitation and alternative. Every sentence provides needed information with no filler.
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 read tool with one optional parameter, the description fully covers the return content (nodes, links, views, validation findings) and key behavior (submodel summarization). No output schema exists, so the description adequately explains what the caller will receive. Sibling tools provide context for navigation.
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 one parameter (modelId) with 100% coverage: 'Defaults to the selected model.' The description does not add additional parameter meaning beyond what the schema provides, 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 clearly explains what the tool returns: 'The current scope as a compact outline: nodes with their kind and value, links as arrows between named ports, views, and validation findings.' It also distinguishes itself from sibling tools by noting that submodels are summarized, not expanded, and points to enter_submodel/get_element for that purpose.
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 when-not guidance: submodels are summarized, so to look inside one, use enter_submodel or get_element. It also implies this tool is for getting an overview of the current scope, which is clear from context and sibling tools.
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:

[![relative-interpreter-mcp MCP server](https://glama.ai/mcp/servers/CalWtr/relative-interpreter-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CalWtr/relative-interpreter-mcp)

Score Badge

Copy to your README.md:

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

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