Find published MYOPL product and website information with source URLs. No account or conversation access.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | MYOPL product or website topic to find in published pages. | |
| language | No | Language for MYOPL content and labels: en for English or es for Spanish. | en |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / descriptionAdded value: +"Arguments for search_myopl_website."Input schema / properties / language / descriptionAdded value: +"Language for MYOPL content and labels: en for English or es for Spanish."Input schema / properties / query / descriptionAdded value: +"MYOPL product or website topic to find in published pages."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "description": "MYOPL structured response for search_myopl_website.",
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "clarification": {
+ "description": "Follow-up question when more detail is needed, otherwise null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "guidance": {
+ "description": "Citation and source interpretation instructions.",
+ "type": "string"
+ },
+ "myopl_url": {
+ "description": "MYOPL website.",
+ "format": "uri",
+ "type": "string"
+ },
+ "results": {
+ "description": "Matching MYOPL pages; empty when no page matches.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "excerpt": {
+ "description": "Matching passage from the page.",
+ "maxLength": 1800,
+ "type": "string"
+ },
+ "language": {
+ "description": "Language of the response.",
+ "enum": [
+ "en",
+ "es"
+ ],
+ "type": "string"
+ },
+ "title": {
+ "description": "Page title.",
+ "type": "string"
+ },
+ "truncated": {
+ "description": "True when the excerpt is only part of the source page.",
+ "type": "boolean"
+ },
+ "url": {
+ "description": "Published MYOPL page to cite.",
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "title",
+ "language",
+ "excerpt",
+ "truncated"
+ ],
+ "type": "object"
+ },
+ "maxItems": 5,
+ "type": "array"
+ },
+ "source": {
+ "description": "Published source collection.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "source",
+ "myopl_url",
+ "results",
+ "clarification",
+ "guidance"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "description": "Tool execution or argument error; the enclosing result has isError set to true.",
+ "type": "string"
+ },
+ "myopl_url": {
+ "description": "MYOPL website.",
+ "format": "uri",
+ "type": "string"
+ },
+ "source": {
+ "const": "MYOPL",
+ "description": "Source platform.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "error",
+ "source",
+ "myopl_url"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is largely covered. The description adds the data boundary (no account or conversation access) and that responses include source URLs, which is useful context not present in the annotations, but both are terse and no rate limits, pagination or coverage limits are mentioned.
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 short sentences, zero filler, with the primary capability front-loaded before the scope disclaimer. Every clause carries information.
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?
An output schema exists, so return values need not be explained, and both parameters are documented in the schema. Safety behavior is covered by annotations, leaving only the missing differentiation from search_myopl_help as a notable gap for a simple two-parameter search tool.
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 100%: both 'query' and the 'language' enum are fully documented in the schema, including default and allowed values. The description adds no parameter-level detail beyond that, so the baseline 3 applies.
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?
States a concrete verb ('Find') plus the resource ('published MYOPL product and website information') and notes results carry source URLs, so an agent knows this is a read search over published web content. However, it never distinguishes itself from the very close sibling search_myopl_help, leaving the boundary between 'website' and 'help' content implicit.
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 clause 'No account or conversation access' gives a negative scope boundary that implies when this tool applies (public/published content only), which is real usage guidance. But there is no explicit when-to-use statement and no alternative named, even though search_myopl_help and search_pickleball_rules are plausible competing choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.