Skip to main content
Glama
TJLDC

Roomvana MCP Server

by TJLDC
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Server Quality Checklist

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

  • Latest release: v0.1.0

  • Disambiguation5/5

    Each tool targets a distinct, non-overlapping purpose: two lookup helpers for separate dimensions (styles vs. rooms) and one action tool that composes them. There is no realistic way to confuse them, and the descriptions explicitly cross-reference each other to reinforce the intended workflow.

    Naming Consistency5/5

    All three tools use a clean snake_case verb_noun pattern: list_design_styles, list_room_types, and design_a_room. The two listing tools are perfectly parallel, and the action tool follows the same verb-first convention.

    Tool Count4/5

    Three tools is reasonable for a narrowly scoped link-generation flow: two enumeration helpers plus one generator. It sits at the lean end of appropriate, but each tool clearly earns its place with no redundancy.

    Completeness4/5

    The surface covers the core flow of discovering valid styles/rooms and producing a pre-configured design link. Minor gaps exist (e.g. no way to check the status or result of a generated design, or fetch account history), but these fall outside the intended handoff where the user completes the workflow externally.

  • Average 4.2/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 1 commit in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • 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

  • 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 usefully discloses that the room and style are validated against Roomvana's live catalog (implying invalid ids fail) and that the tool only produces a link rather than performing the redesign. It does not cover permissions, error behavior, link persistence, or rate limits.

    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?

    Three tight sentences, front-loaded with the core outcome (studio link with options pre-selected) followed by what the user does with it. No filler, though the 30-second detail is marginally decorative.

    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?

    There is no output schema, and the description compensates by explaining what the caller receives (a studio link with options pre-selected). The end-to-end user flow is covered; only failure/validation-error behavior is left unspecified.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters3/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 100%, so the schema already documents room, style, and the notes field (including that notes are echoed but not encoded in the link). The description adds no parameter-level detail beyond the schema, which is the expected baseline.

    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?

    States a specific verb and artifact: it turns a room + style into a pre-configured Roomvana studio link. It also clarifies what the tool does not do (the redesign happens after the user opens the link), so an agent can tell it apart from the sibling list_room_types and list_design_styles tools.

    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 usage context by describing the downstream user flow (open link, upload photo, get redesign), but it never states when to call this vs. alternatives or any prerequisites. The only routing hint ('See list_room_types' / 'See list_design_styles') lives in the schema, not the description, so guidance is implied rather than explicit.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior4/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries the full burden. It discloses the return payload ('each with a short description') and the read-only nature implied by 'List', which matters since there is no output schema. It stops short of stating exhaustiveness, freshness, or access requirements.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    Two tightly scoped sentences with no filler. The purpose is front-loaded and the follow-on usage note is a single clause, so every sentence earns its place.

    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, no-output-schema catalog tool, the description covers both what is returned (styles with short descriptions) and the workflow reason to call it. Nothing an agent needs to invoke it correctly is missing.

    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, so there is no parameter semantics to document; baseline is 4. The description correctly implies no filtering arguments are needed to enumerate styles.

    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?

    States a specific verb and resource ('List the interior-design styles Roomvana can render') and grounds it with concrete examples (modern, japandi, industrial). An agent can distinguish this catalog-listing tool from design_a_room (which renders) and list_room_types (which enumerates a different domain) without opening any schema.

    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?

    Explicitly says when to use it: 'Use this to pick a `style` for design_a_room', linking the tool to its downstream consumer. It gives clear context but does not describe exclusions or contrast directly with the list_room_types sibling.

    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, but for a zero-parameter static enumeration the risk surface is minimal. It usefully discloses the shape of the returned content (three categories of redesignable space), which is the main behavioral fact an agent needs; pagination, auth and ordering are irrelevant here.

    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 short sentences, front-loaded with what is listed, followed by the reason to call it. Every clause earns its place and there is 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?

    With no parameters and no output schema, the description compensates by naming the returned categories and pointing to the consuming tool (design_a_room). Nothing an agent needs in order to call this correctly is missing.

    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 no parameters, so per the rubric the baseline is 4. The description correctly adds no spurious parameter talk, and the empty schema leaves nothing to clarify.

    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 gives a specific verb ('List') and resource ('room and outdoor space types'), then enumerates the categories returned (interior rooms, house exterior, garden/outdoor). This distinguishes it from the sibling list_design_styles, which enumerates a different taxonomy.

    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 explicitly states the downstream use: 'Use this to pick a `room` for design_a_room,' which tells the agent exactly when this tool is the right call. It stops short of a full when/when-not pair (e.g., no statement that it should not be used to find style ids), so it is clear context rather than complete routing guidance.

    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

Roomvana MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

Score Badge

Roomvana MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md: