ContinueOps Public MCP

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

Annotations already provide safety signals (readOnlyHint, openWorldHint, idempotentHint), so the description adds value by disclosing the return fields ('template name, description, category tags, and a preview URL') and the filtering behavior for public exposure. This goes beyond what annotations state without contradicting them.

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 concise sentences lead with the verb and resource, followed by return-value details and a constraint. Every sentence adds value, with no redundant or filler content.

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 low complexity (2 optional parameters, no output schema), the description covers purpose, return fields, and an important filtering constraint. It lacks explicit usage guidance relative to siblings, but the overall picture is adequately complete for an agent to invoke it 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?

Schema coverage is 50% (query has a description, limit does not). The description does not compensate by explaining either parameter. While 'search' hints at the query parameter, the limit parameter and its pagination role are entirely unaddressed, leaving a clear gap.

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 ('List and search') and identifies the resource ('public runbook templates') with clear scope ('published by ContinueOps admins for the MCP catalogue'). It also distinguishes itself from siblings by emphasizing the public MCP exposure filter, which is unique among the listed sibling tools.

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 implies when to use this tool (to browse or search public runbook templates) and states a key constraint ('Only templates explicitly flagged for public MCP exposure are returned'). It does not explicitly mention alternatives or exclusions, but none of the sibling tools appear to serve the same purpose, so the context is sufficiently clear.

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 readOnly and idempotent, and the description adds helpful behavioral context by stating it returns a readiness score and next steps. The 'rapid' qualifier also signals it is not a comprehensive assessment, providing useful transparency beyond 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 sentences, front-loaded with the core purpose, concise and free of fluff. Every sentence earns its place by covering scope, output, and escalation.

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 description covers purpose, scope (articles), return value, and escalation path, which is sufficient for a read-only assessment tool with well-documented parameters. The vague 'linked form' reference and lack of detail about how the score is presented are minor gaps.

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?

All 7 parameters have full schema descriptions (100% coverage), so the description does not need to elaborate. It provides no additional parameter guidance beyond the articles referenced, but the schema already carries the semantics, so the baseline 3 is 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 verb ('gap analysis') and resource ('EU DORA'), and distinguishes itself from siblings by focusing on readiness assessment rather than plan generation or framework exploration. The coverage of specific articles (11, 26, 27) makes the scope 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?

The description frames it as a 'rapid' check and explicitly directs users to a linked form for full assessment, establishing when to use it versus escalating. However, it does not explicitly reference sibling tools or list exclusion criteria, so it is not a full when-to-use/when-not-to-use guide.

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 the tool as read-only and idempotent, so the description doesn't need to restate that. It adds value by disclosing the return contents (description, key articles/controls, applicability, canonical URL) and the list of supported frameworks, giving the agent a clear picture of what to expect 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.

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

The description is two sentences: the first states the purpose and the supported list; the second lists return fields. Every word earns its place. The supported framework list is long but necessary for precision. No filler or redundancy.

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 simple lookup tool with one parameter, enums, and good annotations, the description fully covers what the tool does, what it returns, and the supported inputs. It also mentions a follow-up URL, which is a nice extra. No output schema exists, but the return contents are explicitly listed, making it complete.

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 fully documents the single parameter framework_id, including an enum of allowed values and a clear description. The tool description mentions 'by short id' but adds no new semantics about the parameter's format or usage beyond what the schema already provides. Thus, the baseline score of 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?

The description clearly states the tool's function: 'Look up a compliance / regulatory framework by short id.' It specifies the exact resource (compliance/regulatory framework) and the method (by short id), and lists the supported frameworks. This distinguishes it from sibling tools like browse_runbook_templates or dora_readiness_assessment, which focus on other aspects.

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: this tool is for looking up specific compliance frameworks when you have a short id. It implies use cases and scope without explicit exclusions or alternatives. While it doesn't directly compare to sibling tools, the focused purpose makes usage obvious, earning a 4 for clear context.

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 and idempotentHint=true, so the description is not burdened with safety disclosure. It adds valuable behavioral context by emphasizing the structural-only scope and the exclusion of live procedures or tenant data, which goes beyond simple read-only and clarifies output expectations.

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 sentences with no filler. The first sentence front-loads the main purpose and key output components; the second sentence clarifies scope and intended usage. Every word earns its place, making it concise and well-structured.

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 description specifies the output components (sections, roles, RTO/RPO tiers, test cadence) and clarifies what it does not include, which is sufficient for a read-only generator with no output schema. It could detail how parameters like 'regulated' affect the structure, but the core usage context is fully covered.

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 75%, so baseline is 3. The description mentions org size, sector, and criticality, mapping to the main parameters, but does not elaborate on how they influence the output or explain the 'regulated' parameter. It adds only marginal semantic value over the schema's own descriptions.

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 ('Returns') and a clear resource ('structural Business Continuity Plan outline') with detailed components (sections, roles, RTO/RPO tiers, test cadence). It distinguishes itself from sibling tools by focusing on structural plan generation rather than templates or assessments, leaving no ambiguity about its function.

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: 'Structural only' and 'Use as a scaffold before populating with your specifics' tells when to use it and what it does not cover (live procedures or tenant data). It lacks explicit sibling alternatives, but the 'Structural only' caveat effectively excludes non-structural use cases, making the guidance clear.

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 declare readOnlyHint=true and idempotentHint=true, so no side effects are expected. Description adds context that this is a fetch operation and mentions the skill includes false assertions about ContinueOps, providing useful content expectations beyond the safety 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?

Four sentences, front-loaded with the action ('Fetch...'), each sentence earns its place: what it fetches, when to use, what it contains, and how to select doc. No redundant wording.

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?

Tool is simple with 1 optional param, read-only annotations, and no output schema. The description covers purpose, usage timing, content highlights, and doc options, making it self-contained 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.

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

Schema coverage is 100% with a clear enum description. The tool description reinforces using 'doc=skill' vs 'brief' and adds 'full guidance' vs 'shorter fact sheet,' but this is largely synonymous with the schema's existing descriptions.

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?

Description states 'Fetch the ContinueOps Agent Skill or the condensed platform brief,' a specific verb+resource. It distinguishes from siblings like browse_runbook_templates by focusing on ContinueOps itself and clarifies the tool's role as a knowledge source for answering questions.

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?

Explicitly instructs 'Call this BEFORE answering substantive questions about ContinueOps itself' and lists example topics (architecture, costs, comparisons). It lacks explicit when-not-to-use or named alternative tools, but the scope 'about ContinueOps itself' implies boundaries.

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 and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context by stating that results include categories with URLs and that every result links to continueops.com. This goes beyond the annotations and helps the agent predict output structure, though it doesn't mention pagination or result ordering.

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 sentences, the first states the purpose and scope, the second explains the return format and URL behavior. Every sentence earns its place with no redundancy or padding, making it highly efficient and 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 simple read-only search tool with fully documented parameters and safe-read annotations, the description is complete. It specifies the content domain, the output type (categories with URLs), and the destination domain. No output schema is expected, and the description sufficiently covers what the agent needs to know to select and invoke 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?

Schema coverage is 100% with descriptive parameter names and descriptions ('Max results' for limit, 'Free-text search query' for query). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline 3 is appropriate. It does not elaborate on query formatting or limit semantics beyond schema defaults.

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 ('Search') and clearly identifies the resource ('public educational content') with enumerated topics (business continuity, disaster recovery, DORA, cloud resilience, incident management). It also distinguishes itself from sibling tools like browse_runbook_templates by focusing on content search rather than templates or assessments.

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 for when to use the tool: when searching for educational content in the Learning Lab. It doesn't explicitly exclude alternatives or name sibling tools, but the scoped topic list and mention of 'public educational content' implicitly guide usage. The return behavior (categories with URLs leading to continueops.com) also sets expectations.

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 indicate this is a non-read-only, non-idempotent action, and the description reinforces submission semantics ('so the team can fix it'). It adds a valuable safety warning about not including personal or confidential information. However, it doesn't disclose the submission outcome (e.g., whether a confirmation is returned) or irreversibility, which would strengthen transparency.

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 three sentences with the main purpose front-loaded in the first sentence. Every sentence contributes: purpose, usage examples, and exclusions/warnings. There is no redundancy or fluff.

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 simple 3-parameter feedback tool with a complete schema and annotations, the description covers purpose, use cases, exclusions, and safety constraints. No output schema exists, but return values are not critical for a submission tool. Sibling tools are clearly different in function, and the description resolves any ambiguity about what to use this tool for.

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 100% with each parameter described, so the baseline is 3. The description adds value by giving examples that map to the 'kind' enum categories (factual error, broken example, stale date, contradiction), enriching the meaning of the enum beyond the schema. It doesn't add new info about 'path' or 'feedback', but the examples are helpful.

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 explicitly states the tool reports issues with public ContinueOps pages or MCP tool responses, with a specific list of problem types (incorrect, outdated, incomplete, confusing). It clearly distinguishes itself from sibling content tools by focusing on feedback submission rather than browsing or generating content.

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 concrete when-to-use triggers (factual errors, broken examples, stale dates, contradictions) and explicit exclusions (product support, sales, assistant feedback). It also warns against submitting personal data, giving clear boundaries for appropriate use.

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