rhodium11-mcp

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool is clearly scoped to a specific resource and action, with distinct names like projects_get_projection vs keywords_projection. The descriptions further clarify any potential overlap, making misselection unlikely.
Naming Consistency5/5
All tools follow a strict rh11_<resource>_<action> pattern with consistent snake_case. Actions are predictable (get, list, create, update, archive), and even the less common ones (quick_set, report_issue) fit the pattern.
Tool Count4/5
21 tools is on the heavier end but justified given the broad domain (account, wallet, projects, keywords, schedules, orders, feedback). Each tool addresses a distinct need, and the count remains manageable for an agent to navigate.
Completeness4/5
The surface covers core lifecycle operations for projects (list, create, get, update, archive), schedules (get, set, quick_set), and orders (list, get, report_issue). Minor gaps like subscription cancellation or wallet top-up exist but don't block primary workflows.
Average 4.2/5 across 21 of 21 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds no behavioral context such as error behavior, required permissions, or what 'detailed info' includes, making it minimally informative beyond the annotation.
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, direct sentence with no redundant information. It is front-loaded with the verb and clearly identifies the resource.
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 read-only getter with one well-documented parameter and existing annotation, the description is adequate to invoke the tool correctly. Lack of output schema details is a minor gap, but not required for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full 100% coverage for the lone parameter order_id ('Order identifier'). The description does not add further parameter-specific meaning or format details, so it stays at 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?
The description clearly states the tool retrieves detailed info for a specific order, using a specific verb ('Get') and resource ('Rhodium11 order'). It distinguishes from siblings like rh11_orders_list (listing) and rh11_orders_report_issue (write operation).
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 context implies use when you have an order ID and need details, but there is no explicit guidance on when to use this versus alternatives like rh11_orders_list. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds return field details (ASIN, keyword, active status, current service volumes), which is useful but not substantially behavioral. It does not mention pagination, ordering, or side effects, though none are expected for a read-only list. With annotation coverage, a 3 is appropriate.
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, concise sentence (18 words) that front-loads the purpose, includes scoping ('Rhodium11 Amazon'), and lists return fields without redundancy. Excellent structure for an API description.
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 there is no output schema, the description compensates by stating the returned fields. It also notes optional filters and the presence of a readOnlyHint annotation covers safety. It could explicitly state that omitting filters returns all projects and whether results are paginated, but for a simple list tool, this is nearly 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 coverage is 100%: both parameters (active and region) have descriptions and the enum for region is provided. The description merely says 'optional filters', which adds no extra semantics beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action verb 'List' and clearly identifies the resource 'Rhodium11 Amazon projects'. It distinguishes from sibling tools like rh11_projects_get and rh11_projects_create by indicating a collection-level listing operation, and specifies the returned fields (ASIN, keyword, active status, volumes).
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 through 'List' and 'optional filters', but does not explicitly state when to prefer this tool over alternatives such as rh11_projects_get for individual projects or rh11_projects_get_stats for aggregated data. No exclusions or alternative tool names are mentioned, leaving the comparison inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals a rate limit (max 5 per order) and instructs not to retry, which are key operational traits. However, it does not disclose the outcome of reporting (e.g., ticket creation, response format) or any required 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 two sentences: the first states purpose, the second packs constraints (limit, retry instruction, character range). 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?
For a simple 2-param tool with full schema coverage, the description covers the critical constraint (max 5 reports) and input requirements. It lacks return-value information, but no output schema exists and the tool's simplicity makes this acceptable.
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 covers both parameters with 100% coverage (order_id as 'Order identifier' and description with min/max). The description repeats the character limit but adds no new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Report an issue with a Rhodium11 order,' which clearly identifies the action (report), target (order), and context (issue). This distinguishes it from sibling tools like rh11_orders_get (read operations) and rh11_feedback_submit (general feedback).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage constraints: 'Maximum 5 issue reports per order — do not retry if you receive a limit error,' and specifies the character range. It does not directly compare to alternatives, but the order-specific scope implies the appropriate use case.
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?
Annotations declare destructiveHint: true, so the agent knows it's destructive. The description goes beyond this by clarifying it's a soft delete and explaining how to reactivate (by creating a new project with the same ASIN+keyword+region), which is valuable behavioral context. No contradictions.
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: the first states the operation, the second provides recovery context. No redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers the operation and its reversibility. It could mention side effects on associated data, but the core behavior is clear. The destructive annotation is already present, and the description adds the soft-delete nuance.
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 documents ui_id as 'Project unique identifier' with 100% coverage, so the baseline is 3. The description does not add additional parameter-specific information, though the reactivation note hints at project identity fields (ASIN+keyword+region), which provides some context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive (soft delete)') and the object ('a Rhodium11 Amazon project'), distinguishing it from sibling tools like create, update, get, and list. The mention of reactivation adds clarity about the operation's effect.
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 archiving a project is desired, and the reactivation note provides context on recovery, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. No alternative tools are referenced.
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 readOnlyHint annotation already indicates a safe read operation. The description adds context about the content included (schedule, services, SERP data) but does not disclose additional behavioral traits such as response format, pagination, or error conditions. It adds value beyond the annotation but not richly.
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 communicates the tool's purpose. It is front-loaded with the action and resource, and every word adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description adequately explains what is returned (schedule, services, SERP data). It lacks explicit details about response format or error behavior, but given the low complexity and read-only annotation, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents ui_id as 'Project unique identifier' with 100% coverage. The description reinforces this by mentioning 'a specific Rhodium11 project', but adds no new meaning about the parameter format, source, or usage beyond what the schema provides. Baseline 3 is appropriate given full 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 ('Get detailed info'), the specific resource ('a specific Rhodium11 project'), and the scope of information ('schedule, services, and SERP data'). This distinguishes it from sibling tools like rh11_projects_list (which likely lists projects) and rh11_projects_get_stats (which focuses on statistics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving details of a single project, contrasting with list or stats variants. It provides clear context for when to use this tool, though it does not explicitly mention alternatives or exclusions. The phrase 'a specific project' signals it is for targeted lookup rather than broad listing.
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?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral context by noting the call may be slow (~1-2s) due to 14+ backend DB queries, which is not inferable from annotations. It also enumerates data domains covered, though it does not mention response format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the tool's purpose and a concise list of data categories, followed by a brief performance note. Every sentence carries information without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a solid overview of the tool's capabilities (daily stats, specific data types, performance warning) given the absence of an output schema. It does not detail the exact response structure, but the enumerated data categories give a useful expectation. Sibling differentiation is implicit but 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 descriptions for both parameters (ui_id: 'Project unique identifier', days: 'Number of days of history (default 30, max 365)'), achieving 100% coverage. The description adds no additional parameter semantics beyond implying daily stats, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and specifies the resource as 'daily stats for a Rhodium11 project', enumerating data types (SFB, ATC, Wishlist, PGV, SERP rankings, ARA analytics, Brand Referral, Search Query). This clearly distinguishes the tool from siblings like rh11_projects_get (project details) and rh11_projects_get_projection (projections).
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 state when to use this tool versus alternatives, nor does it name sibling tools. The slowness note implies a performance consideration, but the usage context is only implicit—users can infer it is for retrieving daily stats when needed.
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 annotation readOnlyHint=true already covers the safety profile. The description adds valuable behavioral context beyond the annotation: what data is returned (per-day volumes with specific categories) and the conditional sfb_lock_info augmentation when lock-window conditions apply.
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 with the action and resource front-loaded. The second sentence adds precisely the conditional detail that matters, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description adequately conveys the return content and a key conditional field. Minor gaps such as exact date range or full response format are not critical for correct invocation.
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% for the single parameter ui_id, and the schema already describes it as 'Project unique identifier'. The description does not add further parameter nuance, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses the specific verb 'Get' and identifies the exact resource: 'current schedule for a Rhodium11 project'. Listing the per-day service volumes (atc, sfb, pgv, wishlist) adds clear scope and distinguishes it from sibling write tools like rh11_schedule_set and rh11_schedule_quick_set.
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 when-to-use or when-not-to-use guidance is provided. The usage is implied by the getter naming and read-only nature, but the description does not state when to prefer this over alternatives such as rh11_projects_get or rh11_schedule_set.
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 discloses the reactivation behavior and the 201 status code, as well as validation constraints (ASIN validity, keyword length). However, it does not mention what happens if a non-archived project with the same ASIN+keyword+region exists, nor does it describe side effects beyond 'create' (which is obvious from the name). This is adequate but leaves clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the primary action front-loaded in the first sentence. The second sentence covers an important edge case, and the third provides validation constraints. Every sentence carries meaningful information with no fluff or 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?
The tool has no output schema and no annotations, so the description must explain behavior and outcomes. It explains the 201 status for reactivation but does not describe what a successful new creation returns (e.g., project ID or 200 status). It also omits error cases for duplicate non-archived projects. Given the moderate complexity and the presence of 20 sibling tools, this is acceptable but not fully 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 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds value by explaining the uniqueness key (ASIN+keyword+region) and clarifying that ASIN must be a valid Amazon ASIN, which goes beyond the schema's example. It also reinforces the keyword length constraint, providing semantic linkage between 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 opens with 'Create a new Rhodium11 Amazon project,' a specific verb+resource statement that clearly distinguishes it from sibling tools like rh11_projects_list, rh11_projects_update, and rh11_projects_archive. It also adds a precise behavioral nuance (reactivation of archived projects) that further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when creating a new project. It also explains the special case where an archived project with the same ASIN+keyword+region is reactivated, which implicitly guides the user on behavior for existing records. It does not explicitly name alternatives or state when-not-to-use, but the context is sufficient for selection 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?
Annotations include readOnlyHint=true, so the description only needs to add context beyond that. It does so by disclosing the 'empty object if no plan is active' behavior, which is useful and not apparent from the annotation. No contradictions exist with the 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?
The description is a single sentence, directly front-loaded with the purpose and a useful edge case. Every word earns its place, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (no params, no output schema), the description is largely complete. It states what the tool does and one important return condition, which partially compensates for the lack of an output schema. However, it does not describe the structure of the returned rates object, so completeness is slightly below perfect.
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 schema description coverage is 100% (vacuously). As per guidelines, 0 params receives a baseline of 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Rhodium11 service pricing rates', making the tool's purpose immediately obvious. It also adds a behavioral detail (returns empty object if no plan is active) that further distinguishes it from sibling account tools like rh11_account_get_subscription.
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 checking current service rates but does not explicitly state when to use it versus alternatives such as rh11_account_get_subscription. It provides context (current rates, empty if no plan) but lacks explicit when-not 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?
Annotations provide idempotentHint=true, and the description adds the requirement that at least one field is required. This is useful but does not disclose other behavioral traits like return value or permissions. No contradiction with 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?
The description is two short sentences, front-loaded with the action and fields, and contains no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three string parameters and full schema coverage. The description covers the purpose and the main constraint. While it doesn't mention the return value, the lack of an output schema makes this less critical, and idempotency annotation adds safety context.
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 descriptions cover all three parameters, so baseline is 3. The description adds the meaningful constraint that at least one field must be provided, which is not reflected in the schema's required list. This enhances parameter understanding.
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 updates Rhodium11 account profile fields and lists the exact fields (first_name, last_name, company). This distinguishes it from sibling getter tools like rh11_account_get and rh11_account_get_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: updating profile fields when a user wants to change these attributes. Among siblings, this is the only profile update tool, so context is clear. It doesn't explicitly mention exclusions, but none are needed.
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?
Annotations provide readOnlyHint=true, covering safety. The description adds a behavioral nuance: it may include a warning if data is temporarily unavailable, which is useful context beyond the annotation.
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 succinct sentences with no wasted words. Front-loaded with the main action and result, followed by a single relevant caveat.
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 read-only tool, the description covers the key information: what is retrieved and a potential edge case (warning on temporary unavailability). No output schema exists, but the description adequately sets expectations.
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, so the baseline is 4. The description adds value by explaining what the response contains (credits and USD), which is not required by the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Rhodium11 wallet balance', specifying it returns credits and USD. This distinguishes it from sibling tools like rh11_wallet_get_transactions.
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 this tool (to fetch wallet balance) but does not explicitly contrast with alternatives or state exclusions. The tool name and sibling list make the purpose obvious.
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 adds useful behavioral context beyond the readOnlyHint annotation by explicitly noting pagination and the quirk that the last page may include legacy entries beyond the per_page count. This is valuable for managing expectations about response size and content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and the additional sentence about legacy entries is valuable and not redundant. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key operational aspects: pagination, per_page limits, and the legacy-entry behavior. While there is no output schema to document return format, the simplicity of the tool and the annotation coverage make it adequately complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters with descriptions (page, type, per_page), achieving 100% coverage. The tool description does not add extra parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Rhodium11 wallet transaction history, using the specific verb 'Get' and resource 'wallet transaction history'. It distinguishes itself from the sibling tool rh11_wallet_get_balance by focusing on transactions rather than balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when transaction history is needed. It doesn't explicitly mention alternatives, but the purpose is self-evident and the sibling tools cover different domains (balance, projects, orders), so no confusion is likely.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context: pagination, newest-first order, and the specific data fields included. This goes beyond what annotations provide, though it could mention response shape or edge cases.
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, front-loaded sentence that states the verb, resource, key behaviors, and included fields. Every word earns its place; no redundancy or fluff.
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 read-only list tool with two optional parameters and no output schema, the description provides sufficient context: pagination behavior and field coverage. The simple nature of the tool does not demand a lengthy description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both 'page' and 'per_page' have clear descriptions. The tool description does not add parameter-specific details beyond noting pagination, which is already implied. Baseline 3 is appropriate since the schema carries the 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 uses a specific verb ('List') and resource ('Rhodium11 orders'), and adds distinguishing details: paginated, newest first, and the fields included. It clearly differentiates from siblings like rh11_orders_get and rh11_orders_report_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is the list operation for orders, with pagination and ordering info, making the use case obvious. It does not explicitly mention alternatives or when not to use it, but the sibling tools make that context implicit. No misleading guidance.
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 adds behavioral context by stating the tool 'currently supports toggling the active status (pause/resume)', indicating its limited scope. It does not contradict the idempotentHint annotation; in fact, the description's pause/resume semantics align with idempotent set operations. The description also points to archive as a separate operation, providing useful behavioral guidance.
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 short sentences, each informative and necessary. It front-loads the main purpose, then scopes the behavior, then provides an alternative. No fluff or 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?
Given the simple tool with two parameters, full schema coverage, and an idempotency annotation, the description is complete. It explains the operation, scope, and points to the archive alternative. No output schema exists, so no return value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both ui_id and active documented. The description mentions 'active status (pause/resume)', which echoes the schema's parameter description but does not add new meaning beyond what the schema already provides. Thus, 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 tool updates a Rhodium11 project and specifies the exact operation: toggling the active status (pause/resume). It distinguishes itself from the sibling tool rh11_projects_archive by explicitly pointing to that tool for archiving, making the purpose 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 that this tool is for toggling active status and explicitly directs users to rh11_projects_archive for archiving. It does not explicitly mention other sibling tools like create or get, but the scope is well-defined and the main alternative is named.
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 is consistent with the readOnlyHint annotation and adds value by enumerating the returned fields (email, name, company, plan, account type). This defines the tool's observable behavior beyond simply stating it is a 'get'. It does not cover auth or response details, but for a simple no-parameter read, the field enumeration is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the verb and resource immediately. It contains no filler and every word contributes to understanding the tool's purpose.
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 no-parameter, read-only getter, the description fully covers what the tool does and what data it returns. The explicit field list mitigates the absence of an output schema, and the sibling list provides sufficient context for distinguishing it from related account tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema places no semantic burden and the baseline is 4. The description's field list indirectly clarifies what output to expect, which helps compensate for the lack of an output schema, though there is no parameter-specific detail to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('Rhodium11 account info') along with a field list. This distinguishes it from sibling tools like rh11_account_get_subscription and rh11_account_get_service_rates, which target more specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving general account-level information (email, name, company, plan, account type), providing clear context. However, it does not explicitly state when to use this over related account getter tools, so the guidance is implicit 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?
Annotations already provide readOnlyHint=true, so the safe-read nature is covered. The description adds value by enumerating the specific data fields returned (plan label, fee, discount, wallet usage), giving agents a clearer expectation of the response without any contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action ('Get') and resource ('Rhodium11 subscription info') while parenthetically listing key return fields. No redundant or filler content.
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?
This is a simple read-only tool with no parameters and no output schema. The description fully covers what the tool does and the nature of the returned information, making it adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete. The description does not need to explain parameter syntax or defaults, and the baseline for 0 params is 4. The description's focus on output fields is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: "Get Rhodium11 subscription info" with a clear scope including plan label, fee, discount, and wallet usage. This distinguishes it from siblings like rh11_account_get (general account) and rh11_wallet_get_balance (wallet balance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when subscription details are needed. There is no explicit exclusion or alternative mentioned, but the context is obvious given the sibling names and the description's specificity.
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 transparency burden. It discloses the character constraints and importantly that identical duplicate text will be rejected, which is a behavioral trait. It does not describe post-submission response, but the absence of an output schema reduces that need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose. Every word adds value, with no fluff.
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 single-parameter tool with no output schema and no annotations, the description adequately covers purpose, constraints, and a key behavioral rule. It is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a descriptive property, but the description adds the duplicate-rejection rule which is not in the schema, thus providing meaningful additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit feedback') and the specific resource ('to Rhodium11'), with a character range. No sibling tool handles feedback, so it is distinct.
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 gives clear context including the character limit and an explicit 'do not' instruction about duplicate feedback. It does not mention alternatives, but there are no feedback-related siblings, so the absence is acceptable.
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?
The description goes far beyond the readOnlyHint annotation, explaining low_demand for sparse keywords, budget tracking with daily_budget and daily_budget_used, cached keywords being free, confidence ranges, and how to interpret third_place_share_basis. This gives substantial behavioral insight for safe invocation.
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 dense but well-structured: it opens with the purpose, then moves through usage, result interpretation, and budget behavior. Every sentence contributes useful information without redundancy or 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 output schema, the description compensates thoroughly by explaining the returned structure ({projections, budget}), key fields, confidence handling, and cost semantics. It is complete for an agent to decide and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (region enum/default and keywords array with max 100). The description adds broader context about what the keywords are used for and confirms the max, but it does not introduce new parameter-level meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool researches keywords before creating projects and returns per-keyword metrics (size, third-place share, daily purchases needed). It distinguishes itself from project creation and other project-level tools by focusing on pre-launch keyword evaluation.
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 gives explicit use cases: 'compare candidates, size a launch, or check whether a keyword is worth targeting at all' and positions it BEFORE creating projects. It does not name alternative tools or explicitly say when not to use it, but the context is clear enough for selection.
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?
Despite annotations already indicating destructive and idempotent hints, the description adds crucial context: it clears existing schedules, omits fields default to 0, and discloses the SFB lock behavior with a configurable env var and response field. This goes well beyond the structured 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?
The description is three sentences, front-loaded with the purpose and the most important warning. Every sentence adds distinct value—purpose, destructive behavior, defaults, and SFB locking nuance—without wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the absence of an output schema, the description covers key operational risks: clearing the schedule, default values, SFB lock timing, configurable env var, and the response field surfacing lock info. This is sufficiently complete for safe invocation.
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 each parameter already described and default values provided. The description's mention that 'all omitted fields default to 0' reinforces the schema but adds no new semantic information beyond what the schema already states.
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 begins with a specific verb+resource: 'Quick-set uniform daily volumes for a Rhodium11 project.' It clearly differentiates from the sibling 'rh11_schedule_set' by emphasizing uniform values and the destructive replace behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is for quickly setting uniform daily volumes, with an explicit warning that existing per-day schedules are replaced. However, it does not explicitly name alternative tools like 'rh11_schedule_set' for non-uniform schedules 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotent and destructive hints in annotations, the description adds significant behavioral detail: it explains that 'Replaces any existing schedule' (confirming destructive semantics), caps at 365 entries, and details the SFB locking mechanism (LOCK_SFB_DAYS, configurable via RH11_LOCK_SFB_DAYS) and the appearance of 'sfb_lock_info' in the response. This provides valuable context not present in the 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?
The description is three sentences, each earning its place: the first states the core action, the second clarifies the destructive replacement, and the third adds essential constraints and locking behavior. It is efficiently front-loaded with the main purpose and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (nested schedule array, max 365 entries, no output schema), the description covers all critical aspects: full replacement, entry structure, limits, and the locking behavior with response field visibility. The annotations provide safety context, and the schema covers parameters, so the description completes the picture without needing to reiterate structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear per-parameter descriptions for ui_id and schedule items (including the 'ongoing' date option and 'wishlist must be 0'). The description adds little beyond the schema: it re-mentions the volume fields and the max 365 entries, but does not introduce new parameter-level meaning.
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 'Set' and the resource 'full per-day schedule for a Rhodium11 project,' and explicitly notes it 'Replaces any existing schedule,' distinguishing it from sibling tools like rh11_schedule_get and rh11_schedule_quick_set.
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 gives clear context by emphasizing 'full per-day schedule' and replacement, which implies it is for wholesale scheduling rather than partial updates (like rh11_schedule_quick_set). However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.
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?
Annotations only declare readOnlyHint=true, so the description carries the full burden of behavioral disclosure. It explains the meaning of third_place_share_basis, the interpretation of low_confidence, and the nature of different statuses ('temporary' vs 'not'), far exceeding what the annotation provides.
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 dense but every sentence adds meaningful guidance—sizing context, usage advice, interpretation rules, and edge-case statuses. No filler or repetition; it's structured with logical progression from output to interpretation to edge cases.
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?
There is no output schema, yet the description explains all key return semantics, including confidence range behavior, share basis interpretations, and status handling. It provides a complete mental model for using the tool correctly without needing external documentation.
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 parameters with ui_id already described as 'Project unique identifier'. The description adds no extra parameter detail, but the baseline for high schema coverage is 3, and it doesn't need to compensate.
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 explicitly states the tool retrieves recommended daily purchase quantities for a project's keyword, with confidence ranges and supporting volumes. This is a specific verb-resource pairing that clearly distinguishes it from sibling tools like rh11_keywords_projection or rh11_schedule_get.
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 clear guidance: 'Use this before changing a schedule, or to check whether current volumes are sensible.' It also explains when to rely on low/high estimates and how to interpret status values, providing actionable decision criteria.
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:

[![rhodium11-mcp MCP server](https://glama.ai/mcp/servers/Rhodium11/rhodium11-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Rhodium11/rhodium11-mcp)

Score Badge

Copy to your README.md:

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

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