Find published MYOPL Help Center instructions with source URLs. No account or conversation access.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | MYOPL feature or task for which the user needs instructions. | |
| 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_help."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 feature or task for which the user needs instructions."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "description": "MYOPL structured response for search_myopl_help.",
+ "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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the data scope: only 'published' instructions are returned, and no account or conversation data is reachable.
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 with zero waste; the core capability is front-loaded and the scope limitation follows immediately. Every clause earns its place.
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 no explanation, and the description covers the essential scope constraint. What remains missing is any hint about result volume or query phrasing, which would help an agent call it well rather than merely 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 2 parameters and 100% schema description coverage, the schema already documents 'query' and the 'language' enum. The description adds no syntax, format, or query-crafting guidance beyond what the schema provides, 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 specific verb ('Find') and resource ('published MYOPL Help Center instructions'), and the 'with source URLs' clause signals the return shape. It distinguishes itself reasonably from search_myopl_website by scoping to Help Center instructions, though it never names that sibling explicitly.
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 'No account or conversation access' clause implicitly tells the agent this is for public documentation rather than personal/account data, which is useful context. However, it gives no explicit when-to-use guidance relative to search_myopl_website, leaving the agent to infer the difference from resource wording.
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.