Reel Estate MCP

Official

by TryReelEstate

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.3.4
Disambiguation4/5
Tools are mostly distinct with clear purposes. Minor overlap between timeline-related tools (add_timeline_audio, add_timeline_overlay, move_timeline_element, reorder_timeline) is mitigated by detailed descriptions. Generic api_request could overlap but is explicitly for non-standard routes.
Naming Consistency3/5
Naming conventions are mixed: most tools use verb_noun (e.g., add_image, list_projects), but some use noun-like patterns (project_stats, whoami, help). All use underscores, but the pattern is not uniform.
Tool Count4/5
23 tools is slightly on the high side but still reasonable for the comprehensive pipeline (auth, project management, image editing, timeline, rendering, billing). Each tool serves a distinct function, so the count is justified.
Completeness2/5
Several obvious gaps exist: there is no create_project, delete_project, or update_project tool. Timeline manipulation lacks a remove_timeline_element tool. The surface relies on api_request for missing operations, but that is not ideal for a coherent tool set.
Average 4/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on July 3, 2026
- 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.
Tools from this server were used 4 times in the last 30 days.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only gives the API paths. It does not disclose whether the tool is read-only, destructive, or any rate limits. 'Rendered movies' hints at read-only but is not explicit.
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 very brief with one sentence and a conditional. It is efficient but could be slightly reworded for 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?
Given the tool's simplicity (one optional param, no output schema), the description is minimally adequate. It explains the basic function and parameter effect, but lacks details on return format, pagination, or filtering 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 description adds meaning to the only parameter (projectId) by explaining its effect on the API endpoint. With 0% schema description coverage, it partially compensates but could be more detailed.
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 'Rendered movies for the user' and clarifies the API endpoints based on projectId presence, making the purpose clear. However, it doesn't explicitly distinguish from sibling tools like list_clips or list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list_clips or list_projects. No exclusions or prerequisites 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?
The description mentions paging and status filtering, and implies authentication via 'authenticated user'. With no annotations provided, the description carries the full burden, but it omits details like response format, rate limits, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys key endpoint logic. It is concise and front-loaded, though the endpoint details could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no required ones, and no output schema, the description lacks completeness. It does not explain return values, pagination boundaries, or how status filtering interacts with paging, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only briefly mentions 'paging/status' and projectId, without explaining the meaning of each parameter (e.g., page, limit, status enum values). This is insufficient for an agent to correctly use the parameters.
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 that the tool retrieves clips for the authenticated user, with different endpoints based on the presence of a projectId. It effectively communicates the core function, but does not explicitly differentiate from sibling tools like get_clip_status or list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides conditional usage guidance (with vs without projectId), implying when to use each variant. However, it does not offer explicit when-not-to-use advice or compare against alternative tools like list_movies or list_projects.
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?
Discloses async nature, returns jobId, cost, and assembled components. No annotations provided, so description bears full burden. Lacks details on error conditions, destructive potential (though likely non-destructive), or rate limits. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: purpose stated first, then async/cost details. Efficient and front-loaded. Could benefit from slightly more structure but is good for its length.
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?
No output schema; description mentions return type (jobId) and polling via list_movies. Covers async and cost. Does not explain output format or job lifecycle beyond polling. Adequate but not exhaustive.
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 low (33%); only aiGeneratedLabel has description. Description adds that settings fall back to project defaults, but does not explain meaning of nested settings properties (duration, resolution, etc.) beyond enum values. Minimal added value for 3 parameters (one nested object).
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?
Description clearly states the tool assembles timeline into final video with specific elements (clips, music, watermark, overlays). This verb+resource combination distinguishes it from sibling tools like add_timeline_audio or generate_clip, which handle individual components.
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?
Provides some context: only projectId required, settings fallback, async behavior, cost. However, no explicit guidance on when to use this vs alternatives (e.g., generating a clip vs rendering full movie). Missing exclusions or prerequisites.
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 disclosure. It states 'for the authenticated user' and implies a read-only GET operation, but does not clarify side effects, rate limits, or the exact structure of the returned metrics. The description is minimal but not misleading.
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, concise and front-loaded with the HTTP method and endpoint. It contains no unnecessary words, though it could be slightly more descriptive.
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 no output schema and zero parameters, the description provides the core purpose but lacks details about the return format or specific metrics. It is adequate but leaves ambiguity about what exactly the agent will receive.
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, and schema coverage is effectively 100%. The description does not add parameter meaning, but with no parameters this is acceptable. Baseline 4 applies per rules.
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?
Description clearly specifies the tool retrieves aggregate project counts/metrics for the authenticated user, using a GET request. The verb 'GET' and resource '/projects/stats' are precise, distinguishing it from sibling tools like list_projects (lists individual projects) or get_project (single project).
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. For example, when to prefer project_stats over list_projects or get_project is not addressed. The description lacks any contextual selection criteria.
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?
Discloses authentication, path relativity, read-only mode blocking non-GET, and return format including error envelopes. Does not discuss side effects of mutations, rate limits, or authorization scopes. Without annotations, more depth on side effects would be beneficial.
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, front-loaded with purpose, example, and key behavior. Every sentence adds value with no redundancy. Highly efficient.
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?
Covers return structure, path usage, and read-only behavior. Lacks details on error handling specifics, authentication mechanism, and potential side effects. For a generic tool, it is adequate but not thorough.
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?
Adds context for path (relative to base, examples) and method (enum already clear). For query and body, description only says 'JSON body' and 'object' but no additional constraints or format details beyond schema. Schema coverage is 50%, so description partially compensates.
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?
Description clearly states it performs generic authenticated requests to any backend route, with examples. It mentions using list_endpoints to discover paths, which implies differentiation from specific tools, but does not explicitly distinguish from siblings like get_project or list_projects.
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 guidance on when to use: for general API access, and references list_endpoints for path discovery. Mentions blocking of non-GET when MCP_READONLY is set, which is a usage constraint. No explicit when-not or alternatives, but the generic nature makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals key behaviors: async operation returning a jobId, automatic resolution of imageUrl, and credit cost. This is valuable but lacks details on error handling, idempotency, or default values for unmentioned parameters.
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 three concise sentences, front-loading the core purpose and adding essential behavioral notes without any fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description covers the main purpose and critical behaviors (async, cost, auto-resolve) but omits details on parameter defaults, motion types, and response format beyond the jobId. It is adequate but has clear gaps.
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 only 38%, and the tool description adds minimal parameter insight beyond noting that imageUrl auto-resolves. The description does not explain the meaning or impact of motion, resolution, aspectRatio, or customMotionPrompt, leaving a significant semantic gap.
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: 'Animate one still project image into a video clip (Runway Gen-4).' It identifies the verb (animate/generate), the resource (video clip), and the source (project image), successfully distinguishing this from sibling tools like edit_image or render_movie.
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 mentions the async pattern and polling requirement, but does not provide explicit guidance on when to use this tool over alternatives such as render_movie or add_timeline_overlay. Usage context is implied rather than clearly stated with when/when-not or alternatives.
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 exist, so the description must carry the burden. It mentions 'authenticated user' but fails to disclose potential side effects, permissions, or rate limits; however, as a simple GET, it 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?
A single sentence, front-loaded with key information, containing no unnecessary 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?
For a simple get-by-ID tool with one parameter and no output schema, the description is sufficient; it cleanly states the operation and 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?
Schema coverage is 100% with a description for the only parameter ('Project id.'). The description adds no extra semantic value beyond what the schema already provides.
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 (GET /projects/:id) and purpose (full project document for authenticated user), distinguishing it from sibling tools like list_projects.
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 authenticated users but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like list_projects.
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 exist, so the description must carry the burden. It mentions it's a GET endpoint (read-only), but does not disclose potential behavioral traits like rate limits, data volume, or pagination limits. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the HTTP method and core purpose. No unnecessary words, and it efficiently conveys the tool's scope.
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 8 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return structure, pagination behavior, or how to combine filters, which an agent might need to use the tool effectively.
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?
With only 13% schema description coverage, the description lists parameter categories (paging, sorting, search, status) but does not explain individual parameter meanings, formats, or constraints beyond what is in the schema. Many parameters lack descriptions in the schema, so the description should compensate more.
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 lists projects for the authenticated user with specific capabilities: paging, sorting, search, and status filter. This distinguishes it from sibling tools like get_project (single project) or list_clips (clips).
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 implicitly contrasts with get_project and other list tools by specifying features. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when needing a filtered list vs all projects).
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 explains that the tool returns ranked candidates with specified fields. It does not disclose if the tool has side effects (e.g., auto-population is a downstream consequence), nor does it mention rate limits, authentication, or data retention. The behavioral disclosure is adequate but not detailed.
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 three sentences long, front-loaded with the primary action. It is efficient and free of fluff. However, it could be slightly more compact without losing clarity.
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 (two parameters, no output schema), the description covers the purpose, usage context, and output fields. It explains how to use the result. Missing details about error handling or input validation, but overall it is sufficiently complete for a geocoding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It mentions 'free-text address' for the query parameter but does not explicitly describe the limit parameter or provide guidance on its usage. The description adds minimal parameter-specific insight beyond what the schema implies.
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 resolves a free-text address into ranked candidates with specific fields (formatted, placeId, location, components). It distinguishes its purpose from sibling tools by indicating it should be used before creating a project for a real listing.
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 when to use the tool ('before creating a project for a real listing') and how to use the output ('pass the chosen candidate as the project address'). It also advises to prefer candidates with isStreetLevel=true. However, it does not mention when not to use it or alternatives, but no alternative geocoding sibling exists.
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 discloses key behaviors: non-destructive, versioned, async (returns jobId), costs 1 credit. It misses rate limits or error handling but 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 three sentences, front-loaded with purpose, each sentence adding unique value: purpose, edit types, conditions and async behavior. 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?
No output schema exists, but description explains return value (jobId) and effect. Covers major edit type conditions and cost. Lacks error behavior or auth requirements but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%. The description adds meaning by explaining editType enum values and required combinations (e.g., advancedParams for replace/remove/add), complementing schema descriptions for style, roomType, etc.
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 it creates a non-destructive, versioned edit, listing many edit types and async behavior. However, it does not explicitly differentiate from sibling tools like add_image_from_file or get_clip_status.
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?
It implies usage by listing required conditions for edit types (e.g., staging needs roomType+style), but does not provide when-to-use vs alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it is a GET request and for the authenticated user, but does not explicitly state it is non-destructive or discuss rate limits, data freshness, or authentication details beyond implication.
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 the endpoint path. It is front-loaded and every word adds 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 no output schema and no parameters, the description provides enough context (what it does, for whom). It could hint at response format, but it is largely complete for a simple read 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?
There are no parameters, and schema coverage is trivial (100%). The description does not need to add parameter info. Baseline 4 for 0 parameters 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 verb (GET) and resource (/billing/usage) and the purpose: retrieving credit and export usage for the authenticated user. It differentiates from siblings as no other tool focuses on billing/usage.
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 when to use it (when you need credit/export usage), but does not provide explicit guidance on when not to use it or mention alternative tools. The context is clear but lacks 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 provided, so the description carries full behavioral burden. It mentions it's a GET endpoint and what it returns (stock+cloned voices), but lacks details on pagination, authentication requirements, or response format.
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?
Single sentence that is front-loaded with the HTTP method and resource, conveying the essential 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?
For a simple tool with no parameters and no output schema, the description is nearly complete. It could mention whether authentication is required, but overall it adequately describes the tool's purpose and output.
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?
No parameters exist in the input schema, and schema description coverage is 100% trivially. The description adds no parameter information, but none is needed. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists voiceover voices available to the user, specifying they include stock and cloned voices. This distinguishes it from sibling list tools like list_clips or list_movies.
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?
No explicit guidance on when to use this tool versus alternatives, but the purpose is straightforward and siblings are clearly different resources. A brief mention of when to use list_voices vs other list tools would improve clarity.
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?
Given no annotations, the description fully discloses the multi-step process (read file, mint S3 URL, PUT bytes, attach) and that no credentials are needed. Notes aspect ratio constraint. Missing potential side effects like overwriting, but overall transparent.
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?
Concise 4-sentence paragraph. Front-loads purpose, explains process, then constraints. Every sentence is informative 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?
No output schema, but parameters are well-documented in schema. Description covers workflow and constraints. Could mention error cases or size limits, but fairly 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%, so baseline is 3. The description adds context about local file path and aspect ratio, but does not elaborate on optional parameters beyond schema descriptions.
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?
Clearly states the action: 'Upload a LOCAL image file to a project.' Distinguishes from siblings by emphasizing the credential-less local upload path not possible via remote MCP. Includes constraints like aspect ratio and read-only block.
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 notes this is the 'credential-less upload path the remote MCP can't do,' guiding when to use it. Also mentions 'Blocked in read-only mode.' Lacks explicit alternatives but provides clear contextual usage.
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 mentions that the tool is 'blocked in read-only mode' (indicating it is a write operation) and explains parameter defaults. However, it does not disclose potential side effects (e.g., whether adding an audio overwrites existing ones) or any permission requirements beyond read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose in the first sentence, followed by essential parameter guidance and a note on read-only mode. It is concise (three sentences) with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description provides sufficient context for an agent to decide when to use the tool and how to set key parameters. It could be improved by mentioning other parameters (fadeIn, fadeOut, volume) and what the tool returns, but the core behavior is well covered.
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 description adds significant meaning beyond the schema by explaining the difference between duration and sourceDuration, and by directing users to get_project for voiceover data. Schema coverage is 60%, and while some params (s3Key, fadeIn, fadeOut) are not addressed, the description compensates for the key parameters that differentiate use cases.
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: 'Place an EXISTING audio asset on the timeline at a specific point so it's in the render.' This is a specific verb-resource pair, and it implicitly distinguishes from sibling tools like add_image_from_file or add_timeline_overlay by focusing on audio assets.
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 guidance on when to use the tool (for an existing audio asset) and explains parameter choices: duration defaults to movie length (ideal for background music), while sourceDuration is for fixed clips like voiceovers. It also advises using get_project to obtain voiceover data. However, it does not explicitly compare with siblings or state when not to use this tool.
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?
Without annotations, the description fully covers the authentication flow: returns authorization URL, browser interaction required, token cached, and action retry needed. It does not discuss error states or re-login behavior, but provides adequate transparency for the intended use.
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 with no waste: first sentence states purpose, second explains the workflow and a practical caveat. Every sentence adds 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?
The description explains the main flow and a practical limitation (browser popups). Missing details on idempotency, error handling, and what happens if already authenticated, but given the tool's simplicity, it is fairly 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 input schema has zero parameters, so schema coverage is 100%. The description adds no param details because none exist, meeting the baseline of 4 for parameterless tools.
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 authenticates with the backend, explains the OAuth flow, and distinguishes from related tools like 'logout' and 'whoami' by describing the specific action of obtaining and caching a token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when not logged in and mentions retrying after approval, but lacks explicit when-not conditions (e.g., if already logged in) and does not mention alternatives among siblings.
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, description explains position coordinate system, dual modes, and read-only restriction. But it doesn't mention side effects like conflict resolution or default behaviors.
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 with key information front-loaded. Each sentence adds value without redundancy.
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?
Covers core usage but lacks return value description, error handling, and default values for some parameters (e.g., opacity, size). Given 12 parameters and no output schema, more detail would help.
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?
Adds context beyond schema by grouping parameters into image/text modes and clarifying position interpretation. Schema coverage is 75%, so description complements well.
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?
Clearly states 'Overlay an EXISTING image/logo OR a text caption on the timeline at a specific point', distinguishing between image and text overlays. This differentiates it from siblings like add_image_from_file.
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?
Specifies modes for image vs text and mentions blocked in read-only mode. However, it doesn't explicitly guide when to use this vs alternatives like add_timeline_audio.
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 provided, so description carries full burden. States it is a polling (read-only) operation via GET HTTP method, which discloses the non-destructive nature. Does not mention rate limits or error cases but is sufficient for a simple status checker.
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?
Single sentence, under 20 words, front-loaded with the key action and resource. No redundant information.
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 low complexity (one parameter, no output schema), the description covers all necessary information: what it does, how to use it, and the relationship to generate_clip. No gaps.
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 0% with one parameter 'jobId'. Description compensates slightly by indicating the job comes from generate_clip, but does not add format or constraints beyond the schema. Baseline 3 is appropriate given the single parameter and contextual hint.
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?
Clearly states the action 'poll' and resource 'clip-generation job status', explicitly references the sibling tool 'generate_clip' that starts the job, and distinguishes from other sibling tools by focusing on status checking.
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?
Implies usage context: after calling generate_clip to check job status. Mentions the HTTP endpoint but does not explicitly list when not to use or alternative tools. Context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the output as a curated, grouped catalog, which implies a read-only operation with no side effects. However, it does not explicitly state that it is safe or non-destructive, 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?
Three sentences, front-loaded with the main purpose. Every sentence adds value with no wasted words. The description is efficiently structured.
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 tool with no parameters and no output schema, the description adequately describes the output's nature (curated, grouped, not exhaustive). It is complete enough for the agent to understand what to expect.
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 coverage is 100% (since there are no properties). The description adds meaning about the output (curated, grouped), which goes beyond what the schema provides. A baseline of 4 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 it returns a curated catalog of API endpoints, grouped, for the agent to know what api_request can call. It distinguishes itself from sibling tools like api_request (makes requests) and help (general help) by specifying the scope of what it lists.
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 notes that the list is curated and not exhaustive, giving context on when to rely on it versus potentially needing a full enumeration. However, it doesn't explicitly state when not to use it or provide an alternative for exhaustive routes.
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?
Discloses that startTimes are recomputed for back-to-back playback and that the tool is blocked in read-only mode. No annotations provided, so the description covers key behaviors adequately, though authorization details are not elaborated.
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, each adding essential information. 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?
The description is fairly complete for a mutation tool: covers purpose, parameters, and behavior. However, it does not describe the return value or compare to siblings, which would add completeness.
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 description adds meaning beyond the schema: explains default track for trackId, default gap value, and omitted element behavior. Schema coverage is 75%, and the description compensates well.
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 that the tool rearranges a track's elements into a given order and recomputes startTimes, specifying the default track. This distinguishes it from siblings like move_timeline_element.
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 good context: describes how to use (pass ids in order, omitted elements appended) and when not to use (blocked in read-only mode). However, it does not explicitly compare to alternative tools like move_timeline_element.
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 bears full responsibility for behavioral disclosure. It reveals that the tool includes example arguments and mentions key gotchas (async polling, paid gating). However, it does not fully detail the exact interactive flow or output format, but for a help 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and usage guidance. It is concise for its informational load, though it could be slightly restructured for readability (e.g., breaking into two sentences).
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 that the tool has no parameters and no output schema, the description fully covers what the tool does: a walkthrough with pipeline steps, example args, and gotchas. There is no missing information for an agent to decide on 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 input schema has zero parameters with 100% schema description coverage, so no additional parameter info is needed. The description's mention of 'example args' refers to content within the walkthrough, not tool parameters, which is fine. No further semantic burden.
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 it is a 'Guided, numbered walkthrough of the whole pipeline', specifying the verb 'walkthrough' and the resource 'this server'. It distinguishes itself from sibling tools by mentioning the comprehensive pipeline steps, which no other tool covers.
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 explicitly says 'Call this first if you're not sure where to start', providing clear guidance on when to use this tool. It also outlines the pipeline steps and notes gotchas (async polling, paid gating), helping the agent decide when to invoke 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 provided, the description carries the full burden. It discloses that the tool is 'Blocked in read-only mode' and works on 'any track'. While it does not detail side effects like conflict handling, it transparently conveys a key constraint.
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 four sentences, each earning its place: purpose, usage guide, alternative, ID source, and behavioral note. No wasted words, 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 no output schema and no annotations, the description covers purpose, usage, parameter sourcing, and a key behavioral constraint. It omits error behavior but is otherwise complete for a mutation tool of moderate 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 coverage is 50% (only duration and startTime have descriptions in schema). The description adds meaning by mapping 'starts' to startTime and 'how long it lasts' to duration, and specifies that elementId comes from get_project, compensating for undocumented 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 'Change' and resource 'timeline element', clearly stating it adjusts start and/or duration. It distinguishes itself from the sibling tool 'reorder_timeline' by explicitly noting it works on a single element.
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 advises when to use this tool ('nudge a floating audio/overlay element to a new point') and provides an explicit alternative ('To resequence all clips, use reorder_timeline'). It also indicates where to obtain required IDs ('Element ids come from get_project').
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?
Describes the effect (clear cached session, best-effort revoke, next call re-authenticates). Lacks details on error handling or what happens if revocation fails, but overall transparent given no annotations.
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, no redundant words, front-loaded with core action. Every sentence adds value.
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 tool with no parameters and no output schema, the description fully explains the purpose, effect, and when to use. Complete for a simple 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?
No parameters exist, so schema coverage is 100%. Baseline for zero parameters is 4. Description does not need to add parameter info.
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 'Clear' and the resource 'cached OAuth session', also mentioning server-side revocation. It distinguishes from siblings like 'login' and 'whoami' by focusing on session termination.
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?
Explicitly states when to use: 'to switch accounts or reset a broken auth state'. This provides clear guidance on appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that free accounts are read-only over MCP and that if not signed in, it returns a 'run login' error. This reveals important behavioral traits beyond the tool name.
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 packed sentences that front-load the key outputs and then provide usage context. Every sentence adds value without redundancy.
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?
Covers all needed aspects: what it returns, why it's useful (auth check), and edge case (not signed in). No output schema exists, but description fully covers return values and behavior.
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?
No parameters exist; baseline 4 applies. No additional parameter info needed since there are none.
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 what the tool shows (URL, read-only flag, account plan, canWrite, reason, profile) and its role as an auth check. It is distinct from sibling tools like 'login' and 'list_*' tools.
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?
Explicitly says 'Good first call to confirm auth' and whether create/generate/render tools will work. Also instructs to use the 'login' tool if not signed in, providing clear when-to-use and when-not-to-use 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

Copy to your README.md:

[![reel-estate-mcp MCP server](https://glama.ai/mcp/servers/TryReelEstate/reel-estate-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TryReelEstate/reel-estate-mcp)

Score Badge

Copy to your README.md:

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

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