MRX Public MCP

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral detail: it returns source text, attribution, and dates when available, and must never infer a review—consistent 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.

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

Two tightly written sentences, front-loaded with the core action and followed by output expectations and a behavioral guardrail. No filler or repetition of schema or annotation details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: one parameter, output schema present, and annotations covering safety and idempotence. The description supplies the remaining essentials—provenance of the ID, return contents, and an important constraint—so nothing critical is missing.

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

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

Schema coverage is 0%, but the description compensates by defining 'id' as the canonical URL ID returned by search. This adds real meaning beyond the bare string parameter name and is sufficient for a single-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'fetch a verified public document' by canonical URL ID, and adds scope by tying the ID to search results. It also distinguishes itself from sibling read/search tools by specifying return content and the explicit 'never infer a review' constraint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly signals when to use the tool: after search, with the canonical URL ID. It does not explicitly name alternatives or exclusions, but the usage context is otherwise unambiguous for a one-parameter tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description usefully adds that the tool reads the 'current public' homepage and that it performs no case creation or human review, reinforcing the absence of side effects beyond the read.

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

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

The description is two concise sentences. The primary action and resource are front-loaded in the first sentence, and the second sentence adds only meaningful exclusions with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only, idempotent tool with rich annotations, the description is nearly complete. It identifies the resource and the nature of the output (homepage content plus source-linked next-step links). It does not describe exact return format, but the absence of an output schema and the simplicity of the operation make this a minor gap.

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

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%, so the schema provides complete parameter information. There is no parameter meaning for the description to add; the baseline for a zero-parameter tool is therefore appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Read') and resource ('MRX's current public homepage'), and adds the distinctive detail of 'source-linked next-step links'. It does not explicitly name a sibling to differentiate from, but the scope is concrete enough to avoid confusion with a generic fetch or search tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving the public homepage and next-step links, and explicitly states what it does not do ('does not submit a request, create a case, or perform a human review'). However, it does not say when to prefer this tool over siblings like mrx_read_page or mrx_status, leaving the routing decision partly to inference.

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

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

Annotations already mark the tool as read-only and idempotent, and the description adds meaningful behavior beyond that: it performs 'sitemap, hash and indexability checks' and rejects non-canonical URLs. This tells the agent the tool may fail or refuse even valid-looking URLs, which is valuable operational context.

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

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

Two tight sentences deliver the core purpose, the acceptance criteria, and the rejection cases without any filler. The most important constraint is front-loaded in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with strong annotations and no output schema, the description provides everything needed to invoke it correctly. The acceptance and rejection rules fully define the input domain, and the annotation hints cover safety and idempotence.

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

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

The schema provides only a 'url' string with no description (0% coverage), so the description carries the full burden. It compensates well by specifying the exact allowed origin, the requirement that URLs come from search, and which URL variants are rejected.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Read one canonical public MRX page.' It adds scope by requiring mineralrightsxchange.com URLs and excluding private routes, redirects, and off-site URLs, which clearly distinguishes it from a generic fetch tool. The agent can understand exactly what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: this tool should be used only for MRX URLs 'returned by search,' and it explicitly lists rejected inputs such as private routes, off-site URLs, queries, fragments, and redirects. It implies when not to use it, though it does not explicitly name an alternative tool for those cases.

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

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

Adds meaningful behavior beyond the annotations: 'source-text matches, not legal conclusions' prevents over-interpreting filter results, and 'Coverage reports omissions' tells the agent how incomplete coverage is surfaced. No contradiction with readOnly/openWorld/idempotent/destructive hints.

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

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

Three short sentences, front-loaded with the action and corpus, followed by caveats that each earn their place. No filler or repetition of schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with no output schema, the description gives enough to invoke it correctly: corpus, filter semantics, coverage behavior, and a privacy rule. It stops short of a 5 because it does not describe result shape or `limit` behavior.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies that jurisdiction/topic filters are literal source-text matches and that query is a research query, but it does not explain `limit` or the expected string formats for filters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Search verified public MRX titles, headings and article text.' This clearly states what the tool does and distinguishes it from the generic `search` sibling by limiting the corpus to verified public MRX materials.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage context: optional jurisdiction/topic filters are described as source-text matches, and the description explicitly warns not to include personal data in research queries. It does not explicitly name when-not conditions or alternatives among siblings, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about what is checked (sitemap, capabilities, boundaries), which is valuable beyond the annotations. It does not contradict the annotations, and it clarifies the scope of the read operation.

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

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

The description is a single concise sentence that immediately conveys the tool's function. There is no extraneous content, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only, idempotent tool with rich annotations, the description is sufficient. It clearly states what the tool checks, though it does not specify the output format. Given the simplicity and the absence of an output schema, this is an acceptable level of completeness.

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

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

The tool has zero parameters and schema coverage is 100% (vacuously). With no parameters, the description need not explain them, and the baseline is 4. The description does not need to compensate for any missing parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'check' and identifies clear resources: 'current public sitemap/manifest, server capabilities and boundaries.' This distinguishes it from sibling tools like search_guides, read_page, and get_started, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given for when to use this tool versus alternatives. However, the name 'status' and the description imply it should be used to inspect server state before other operations. This is implied usage, not explicit.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds specific behavioral detail: that an incomplete index produces an error rather than a seemingly exhaustive response, and that fetched sources must be relied upon. This goes beyond the openWorldHint and provides actionable guidance.

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

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

The description is four sentences long, with no wasted words. Each sentence adds value: the purpose, the scope limitation, the fetch instruction, and the error behavior. The critical information is front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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), the presence of an output schema, and rich annotations, the description covers the essential aspects: scope, return type, and error behavior. The only notable gap is the lack of differentiation from mrx_search_guides, but this is not critical for calling the tool correctly.

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

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

With 0% schema description coverage for the single 'query' parameter, the description must carry the burden of explaining parameter semantics. It only implies that 'query' is the search term through the tool's purpose, but does not elaborate on format, constraints, or how the query is interpreted. This is insufficient given the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the resource 'public MRX educational guides,' and specifies that it returns citable canonical document IDs. However, it does not differentiate from the sibling tool mrx_search_guides, which likely serves a similar purpose, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it is for public guides only ('No private cases') and instructs the agent to 'Fetch each source before relying on it.' It does not explicitly name an alternative or specify when to use this tool versus mrx_search_guides, but it gives enough context to guide usage in most cases.

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