FLOCORE Governed MCP

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 explicitly reveals that this is WORLD-AFFECTING, requires human approval, and returns APPROVAL_REQUIRED rather than executing. This is strong, non-obvious behavioral information.

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 short sentences with no filler. The purpose is stated first, and the critical world-affecting approval warning is immediately 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?

The description covers the core purpose and a critical behavioral gate, but with no output schema, no annotations, and no parameter documentation, it leaves significant gaps: what tenant_slug should be, what a successful call returns, and how the approval flow resolves. These omissions make it incomplete for reliable invocation.

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%, and the description does not explain the meaning of tenant_slug, title, or description. It adds no parameter-level value beyond the raw schema, so an agent cannot confidently know what values to supply.

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 states a clear verb and resource: 'Raise an operational ticket.' It is immediately distinguishable from the sibling read/list tools such as flocore_list_tickets, so an agent can tell what this tool does at a glance.

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 no explicit guidance about when to use this tool versus alternatives, and it never mentions sibling tools like flocore_list_tickets or flocore_list_tenants. The approval warning is useful cautionary context, but it does not provide selection criteria.

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?

With no annotations, the description carries the full burden. It clearly indicates a read/list operation and adds the scoping constraint 'visible to your scoped token.' Minor omissions such as return shape or pagination exist, but they are not critical for a simple parameterless listing tool.

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?

A single sentence conveys the action, the resource, the domain definition, and the authorization scope. Every word contributes value, and the most important 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 parameterless tool with no annotations and no output schema, this description is nearly complete. It covers what the tool does and under what scope, but it stops short of describing expected return shape or linking to common usage in conjunction with sibling tools.

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 input schema has zero parameters, so the baseline is 4. The description adds meaningful context by explaining that the token scope determines which tenants are returned, which is the only real semantic input even though it is implicit rather than a declared parameter.

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 a clear resource ('tenants'), with a parenthetical definition ('customer/app operating boundaries') that disambiguates the domain meaning. It also distinguishes itself from siblings like flocore_list_tickets by naming a distinct resource type.

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 context for when to use the tool: when you need the tenants visible to your scoped token. It does not explicitly name alternatives or exclusion criteria, but the sibling tools operate on clearly different resources, so selection is still unambiguous.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation implicitly ('List') but does not mention pagination, ordering, whether closed tickets are included, what 'operational' means, or any rate-limit/auth considerations. For a listing tool this leaves notable gaps.

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?

One concise sentence with no filler. The main purpose and the optional filter are front-loaded, and every word contributes.

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?

With no annotations, no output schema, and no details about pagination or status values, the description is thin for a list tool. An agent can call it correctly with tenant_slug, but it won't know what the response looks like, whether there are limits, or how to distinguish it from queue_summary. The low-complexity input schema tempers the gap, but the overall context remains under-specified.

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%, so the schema already documents both parameters. The description adds the meaning of 'status' as an optional filter and clarifies that tenant_slug is the scope ('tenant to read'), but it does not enumerate possible status values beyond what the schema states. The baseline of 3 applies because structured data covers the parameter basics.

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 states a specific verb ('List') and resource ('operational tickets for a tenant') with an optional filter by status, which is clear. It doesn't explicitly differentiate from siblings like flocore_queue_summary or flocore_orch_board, but the tenant-scoped 'tickets' resource is reasonably distinct.

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 phrase 'optionally filtered by status' implies a use case, but there is no explicit guidance on when to choose this tool over alternatives such as flocore_queue_summary or flocore_create_ticket. It gives some context (tenant-scoped listing) but no exclusions or alternative routing.

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?

With no annotations, the description carries the burden of behavioral disclosure. 'List' clearly signals a read-only operation, and the description adds specific output semantics by enumerating liveness values (live | stale | offline). It does not mention pagination, performance, or error behavior, but for a zero-parameter list tool these omissions are minor.

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?

A single, tightly written sentence that leads with the action and resource, then specifies the return fields and value domain. 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 parameterless read-only list tool with no output schema, the description adequately explains what the agent will receive: kind, capabilities, and liveness with explicit status values. It could mention whether the lane list is filtered or ordered, but nothing critical is missing for selecting and invoking the 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?

The tool has zero parameters, and schema description coverage is 100%, so the schema fully covers the input surface. There is nothing for the description to add about parameters, and none are needed.

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, 'List,' and a specific resource, 'FLOCORE mesh lanes,' along with the exact fields returned (kind, capabilities, liveness). This distinguishes it from sibling tools like flocore_list_tenants and flocore_list_tickets without needing to open schemas.

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 tool's purpose is self-evident from the name and description, so when to use it is reasonably implied. However, there is no explicit guidance about when it should be preferred over sibling tools, nor any exclusions or contextual notes about mesh lane inspection.

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?

With no annotations provided, the description carries full responsibility for disclosing behavior. It clearly signals a read-only operation via 'Read' and summarizes exactly what information will be exposed. It does not mention response format, freshness, or access requirements, but these are less critical for a read-only ontology lookup.

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?

A single sentence that front-loads the verb and resource, then compactly lists the conceptual content. Every phrase adds value and there is 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?

The description is appropriately complete for a parameterless reference tool: it tells the agent what the read returns (entity types, semantics, relationships, lifecycle states). A more explicit output format would be helpful but is not essential given the clear conceptual enumeration.

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, so there is nothing for the description to document. The baseline of 4 applies because no parameter ambiguity exists.

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 states a specific verb ('Read'), a specific resource ('the FLOCORE ontology'), and enumerates the content included: entity types, semantic meaning, allowed relationships, and lifecycle states. This clearly distinguishes it from sibling tools that operate on tickets, tenants, queues, and boards.

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 makes the usage context clear: an agent should use this when it needs ontology information about entity types, meanings, relationships, or lifecycle states. It does not list exclusions or alternatives, but the tool's parameterless reference nature makes that omission low-impact.

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?

With no annotations provided, the description carries the disclosure burden. It clearly states 'Read-only' twice and describes the tool as reading control-plane state, making the non-mutating nature explicit. It also enumerates what information is returned. It does not mention rate limits, permissions, or return-shape details, but for a simple read-only board overview this is a reasonably transparent description.

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 compact and front-loaded: the first clause immediately states the action and target, the parenthetical adds context, and the colon introduces the board's contents. The final sentence reinforces the read-only nature. No words are wasted, and every sentence contributes useful 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?

For a simple one-optional-parameter read-only tool, the description provides enough context to understand what the tool does and what it returns at a high level. It does not explain output formatting or tenant-scoping behavior in detail, but the schema covers the parameter and the enumeration of board contents gives a solid picture. The lack of sibling differentiation and usage guidance is the main completeness 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 schema already documents tenant_slug as an 'optional scope' with 100% coverage, so the schema carries the descriptive burden. The tool description adds no additional meaning about how tenant_slug affects the returned board data. Baseline 3 is appropriate because the description does not need to compensate for missing schema 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 clearly identifies a specific verb and resource: 'Read the FLOCORE orchestration board.' It also enumerates the board's contents (lanes + liveness, work-queue summary, governance caps + runaway flags), so an agent knows what this tool covers. However, it does not explicitly differentiate itself from sibling tools like flocore_mesh_lanes or flocore_queue_summary, which appear to cover overlapping sub-resources.

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 does not explain when to use this tool versus the sibling alternatives. The phrase 'Read-only control-plane state' gives some context that this is for reading state, but it does not mention flocore_mesh_lanes, flocore_queue_summary, or any other alternative, nor does it suggest when the aggregate board is more appropriate than a focused sibling 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?

No annotations are provided, so the description carries the full burden of signaling behavior. It makes the read-only nature explicit with 'Read' and discloses the optional tenant scoping plus the specific data categories returned. It does not cover auth or rate limits, but for a simple queue-summary read this is adequate.

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 short sentences with no filler. The core purpose is front-loaded, and the list of summary contents is compact yet informative.

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 tool with one optional parameter and no output schema, the description covers the key context: it is a read, it reports queue health metrics, and it can be tenant-scoped. Minor gaps like exact return formatting or behavior for an unknown tenant are acceptable given the tool's low complexity.

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 input schema has no descriptions and 0% coverage, so the description's 'Optionally scoped to a tenant' adds genuine meaning beyond the bare tenant_slug name and string type. It clarifies that the parameter is optional and acts as a scope filter, though it does not explain slug format or default behavior.

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 ('Read') and names the resource ('FLOCORE work-queue summary'), then enumerates exactly what the summary contains: status, depth, oldest-queued age, awaiting-human, dead-letter, stuck. This clearly distinguishes it from sibling tools like flocore_list_tickets or flocore_orch_board.

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 use whenever an aggregate queue-summary view is needed, but it never states when to prefer this over alternatives or when not to use it. It also does not explicitly mention sibling tools such as flocore_list_tickets, so routing to the right tool relies on inference rather than explicit guidance.

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?

With no annotations, the description carries the full disclosure burden. It explicitly states read-only, silo-scoped, and provenance-stamped outputs with who/source/trust, which are meaningful behavioral traits. It doesn't detail edge cases, rate limits, or failure modes, but the core side-effect and result characteristics are disclosed.

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 short, front-loaded with the query template, and each sentence adds information about behavior or result format. The only minor issue is unexplained jargon ('hybrid-lite', 'silo-scoped') packed into a compact phrase.

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 retrieval tool with one required parameter, the description covers the core purpose and result traits, making basic invocation possible. However, with no output schema and no parameter descriptions for limit/scope, it is not fully self-sufficient for all call variations.

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 explain the three parameters. It hints at the query parameter through the 'what do I know about X' template, but it never explains limit or scope, nor how 'silo-scoped' maps to the scope parameter. This is a meaningful 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 clearly identifies a retrieval action over FLOCORE's memory/world-model, with a concrete query template ('what do I know about X?'). It also adds read-only and silo-scoped qualifiers that separate it from the ticket/tenant/queue siblings, though 'hybrid-lite' is jargon that slightly obscures the exact mechanism.

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 'ask what do I know about X' template implies when to use it, but there is no explicit when-not-to-use guidance or comparison with alternatives like flocore_ontology_entities. A capable agent can infer the use case, but it is left to implication rather than stated.

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