FLOCORE Governed MCP

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is in structured data. The description adds genuinely new behavior: the return contract ('risk score (0..1), the detected intents, and whether it is suspicious'), the data-handling guarantee ('nothing stored, no tenant data'), and the auth requirement ('No token needed'). This exceeds what annotations convey.

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 with zero filler: the first states the core function, the second front-loads the operational facts an agent needs (cost, auth, storage, output). No sentence is redundant with the schema or annotations.

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 low-complexity tool (3 params, no nested objects), the description compensates for the missing output schema by stating the result shape (score, intents, suspicious flag). It covers auth, retention, and purpose; minor omissions like rate limits or the exact JSON envelope are not critical for a read-only screening call.

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 baseline is 3. The description's 'prompt or text' phrasing maps to the required `text` parameter, and 'No token needed' clarifies why `agent` is optional, but no parameter-specific semantics are added beyond what the schema already documents.

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 opens with 'Screen a prompt or text for injection, jailbreak and exfil intent,' a specific verb+resource+purpose that clearly distinguishes this from the flocore_* siblings (tickets, tenants, queues, mesh lanes), none of which perform screening. The title 'Screen for prompt injection' reinforces the same specific purpose.

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 the tool is appropriate: 'Free, public, defensive-only… No token needed' signals that it requires no credentials and is safe to invoke, which an agent needs before calling it. It does not name alternatives or explicit when-not conditions, but the sibling set is topically distinct enough that the intended use (pre-screening untrusted text) is 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?

Even with readOnlyHint=true, the description adds substantial behavioral context: grounding in tenant data, validation, refusal of unsupported answers, never inventing facts, cost-capped LLM routing, on-box backup, and AEGIS screening. This goes well beyond what the annotations convey and helps the agent trust and handle the tool's responses.

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 core purpose is front-loaded in the first clause, which is good. However, the long parenthetical about Smart Switch Sentinel's routing, cost-capping, on-box backup, and model distillation is marketing-style detail that does not help an agent invoke the tool correctly, making the description more bloated than necessary.

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 QA tool with two self-documenting parameters and no output schema, the description covers the purpose, input scope, and the key behavioral trait (unsupported answers are refused). The exact return structure is not spelled out, but the answer/refusal behavior is transparent enough for an agent to use 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% and both parameters are already self-described in the schema ('your plain-English question' and 'the tenant to ask about'). The description reinforces the tenant scoping but adds no meaning beyond the schema, so the baseline 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 states a specific verb ('Ask') and resource ('tenant's FLOCORE operations') with concrete scopes (tickets, queue, state). This clearly differentiates it from the structured siblings like flocore_list_tickets, flocore_queue_summary, and flocore_create_ticket by emphasizing natural-language question-answering grounded in tenant data.

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 alternatives are named and no exclusion criteria are given, leaving the agent to infer when to use this tool versus siblings like flocore_recall or flocore_verify_counterparty. The context is clear enough to imply usage — when a plain-English question about tenant operations needs answering — but no explicit routing guidance is provided.

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?

The description discloses a critical behavioral trait: it is 'WORLD-AFFECTING' and gated on human approval, returning APPROVAL_REQUIRED rather than executing. This goes beyond the sparse annotations (e.g., readOnlyHint=false, destructiveHint=false) by clarifying the approval gate and the expected return value. It does not, however, describe the full post-approval behavior or output, leaving a minor gap.

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 the core purpose front-loaded and the key behavioral caveat (approval requirement) placed immediately after. Every word is informative, and no fluff or repetition exists.

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 four simple parameters and no output schema, the description covers the purpose and the most important behavioral nuance (approval gate). However, it lacks explicit usage guidance (when to use vs. siblings) and does not mention potential side effects beyond world-affecting. These are moderate gaps, but the tool is relatively simple, so a score of 4 reflects adequate completeness with minor opportunities for improvement.

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%, meaning all four parameters already have documented meanings in the input schema. The description adds no parameter-specific details beyond what the schema provides, so the baseline of 3 applies. No extra semantic benefit is delivered.

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 ('Raise') and a concrete resource ('an operational ticket'), which clearly distinguishes it from sibling tools like flocore_list_tickets (listing tickets) or flocore_ask (querying). The purpose is unambiguous and immediately usable by an agent.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or conditions that would route an agent to a different sibling tool (e.g., 'for read-only operations use flocore_list_tickets'). The usage context is only implied by the verb and resource.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by disclosing that results are filtered by token scope and clarifying what a tenant is, but it does not mention return format, pagination, ordering, or potential error behavior.

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 sentence with no filler. It front-loads the action ('List') and then efficiently adds definition and scope information, every word earning 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?

For a zero-parameter, read-only list operation, the description covers the essential operational fact—token-scoped visibility—and defines the resource being listed. It does not describe the response shape, but given the tool's simplicity and the annotations, this is a minor gap rather than a blocking omission.

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 the baseline is 4. The description adds domain context by explaining that tenants are 'customer/app operating boundaries', which helps the agent interpret whatever response comes back. There are no parameters for the description to elaborate on.

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 opens with a specific verb ('List') and a clear resource ('tenants'), and the parenthetical defines exactly what a tenant is: 'customer/app operating boundaries'. This clearly distinguishes it from sibling tools like flocore_list_tickets and gives the agent a precise sense of the operation's scope.

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 useful context by saying results are limited to the scoped token, which implies this is the tool for discovering which tenants the agent can access. However, it never explicitly states when to use this tool versus alternatives or when not to use it, so the usage guidance remains implicit rather than direct.

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, idempotentHint, and destructiveHint, covering the safety profile. The description adds minimal behavioral context beyond the schema, such as the 'operational' qualifier and the optional status filter, but does not disclose potential limits, pagination, or access scoping. This is adequate but not enriched.

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, front-loaded sentence with no wasted words. It states the core action and primary parameters efficiently, earning 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?

For a simple list tool with two parameters, the description covers the essential purpose. It does not explain the return format, but that is not required given no output schema. Combined with annotations and schema, it is nearly complete, though it could explicitly mention that it returns a list of tickets.

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 both tenant_slug and status are already documented. The description merely rephrases the status filter without adding syntax, format, or enum details. It meets the baseline but does not enhance parameter understanding.

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 action (list), the specific resource (operational tickets), and the scope (for a tenant) with an optional status filter. This distinguishes it from siblings like flocore_create_ticket and flocore_list_tenants without requiring schema inspection.

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 tickets of a tenant but does not explicitly mention alternatives or when not to use this tool. Sibling tools like flocore_queue_summary might overlap, but no guidance is provided to differentiate them, so the usage context is only implied.

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, so the agent knows it is a safe read operation. The description adds context about the liveness statuses (live | stale | offline) and the specific attributes returned, which goes beyond the annotation metadata. This is useful because it tells the agent what to expect in terms of the data's nature without needing to call the 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?

The description is a single sentence, efficiently conveying the purpose and the key attributes (kind, capabilities, liveness) and the statuses. It is front-loaded with the action and resource, and there is no unnecessary detail, making it highly concise.

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 with no parameters and no output schema, so the description is complete for an agent to understand what it does and what data it returns. It could mention the potential use cases or the significance of liveness states, but given the tool's simplicity, it is adequate.

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 the description doesn't need to explain parameter semantics. The schema is empty, and the description adequately covers what the tool returns, earning a baseline of 4.

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 it lists FLOCORE mesh lanes and specifies what attributes are included (kind, capabilities, liveness). The verb 'List' identifies it as a read operation, and the resource 'FLOCORE mesh lanes' is specific, distinguishing it from sibling tools that deal with tickets, tenants, or onboarding.

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 the tool is used to inspect mesh lanes, but it does not explicitly say when to use it versus alternatives, nor does it mention any exclusions or prerequisites. Given the sibling tools, the context is clear enough that this is for mesh-related queries, but no explicit guidance is provided.

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?

Beyond the annotations, it discloses the key behaviors: the call registers a request for human review, deliberately issues NO token, returns only a request id, and results in later contact after approval. This is essential non-obvious behavior an agent needs to set 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?

Two dense, front-loaded sentences cover purpose, access requirement, behavioral outcome, and follow-up. Every clause earns its place with no filler or repetition.

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 request-submission tool with no output schema, the description explains what response to expect (request id and later contact) and what not to expect (no token). Combined with the fully documented schema, an agent has enough 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?

Input schema has 100% description coverage and all five parameters are described, so the baseline applies. The tool description does not add parameter-level meaning beyond the schema, though it reinforces the idea that the requester will be contacted after approval.

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+resource ('Request onboarding to FLOCORE governance') and clarifies scope ('world-affecting actions'). Distinguishes itself from sibling tools by emphasizing it is the onboarding request path and issues no token, which differentiates it from ticket creation or governance queries.

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?

Clear context is given: use it for governance onboarding of world-affecting actions, it is public and needs no token, and it is for human-gated review rather than immediate token issuance. It does not explicitly name alternative sibling tools or conditions when not to use it, so a small gap remains.

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, so the safety profile is fully covered. The description adds the scope of what is read (entity types, semantics, relationships, lifecycle states) but does not disclose return format, size, or whether it reflects a static snapshot. With annotations covering the key behavioral traits, a 3 is appropriate.

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, front-loaded sentence that names the resource and lists the four content categories. Every word earns its place; there is no filler or repetition of the title.

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 tool with strong annotations, the description is nearly complete. It tells the agent what content to expect, which is the main thing needed to decide to call it. It does not describe the output structure, but there is no output schema and the tool is simple enough that the absence is a minor gap rather than a critical one.

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 no parameter semantics burden. The description compensates by explaining what the ontology contains, which is the only meaningful semantic context for a parameterless read tool. Baseline 4 for zero parameters is correct.

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 reads the FLOCORE ontology and enumerates the specific content it provides: entity types, semantic meaning, allowed relationships, and lifecycle states. The verb 'read' is specific and the resource is named, distinguishing it from sibling tools that inspect, ask, create, or list other things.

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 this is the tool to use when an agent needs ontology-level knowledge about FLOCORE entities, relationships, and lifecycle states. It does not explicitly name alternatives or state when not to use it, but the context of sibling tools (e.g., flocore_ask, flocore_recall) makes the use case reasonably clear. A small gap is the lack of explicit routing guidance versus flocore_ask or aegis_inspect.

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?

The read-only, idempotent, non-destructive annotations are consistent with the description's 'Read-only control-plane state' claim, so there is no contradiction. Beyond that, the description adds context about what the board contains (governance caps, runaway flags, lane liveness), but it does not reveal additional behavioral traits such as staleness, scope defaults, or output limits. Given the rich annotations, 3 is appropriate.

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 compact sentences with the core action and content categories front-loaded. No filler or repetition of annotation 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?

With no output schema, the description compensates by enumerating the returned aspects (lanes/liveness, work-queue summary, governance caps, runaway flags) and by framing the tool as read-only control-plane state. It does not detail output shape or pagination, but for an optional-scope read tool with rich annotations this is 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 only parameter, tenant_slug, is already described as 'optional scope' in the schema, and schema coverage is 100%. The description adds no further semantic detail about how tenant_slug affects the board read. Baseline 3 is appropriate because the schema carries the parameter documentation.

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 a concrete resource, the 'FLOCORE orchestration board (W113 active mesh)', then lists the content categories (lanes + liveness, work-queue summary, governance caps + runaway flags). This makes the tool's purpose clear, though it does not explicitly distinguish itself from closely named siblings like flocore_mesh_lanes and flocore_queue_summary.

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 when-to-use or alternative guidance is given. The description only says it reads control-plane state; it does not tell an agent to choose this aggregate board over flocore_mesh_lanes, flocore_queue_summary, or flocore_list_tickets. The overlapping sibling names leave the agent to infer 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?

Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It adds useful context by disclosing what the summary contains and that it can be scoped to a tenant. No contradictions or hidden side effects are present.

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 one focused, front-loaded sentence that names the resource, lists the summary metrics, and states the only scoping option. There is no filler, redundancy, or buried caveat.

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-parameter read with rich annotations, the description covers the essential return content and the optional tenant scope. There is no output schema, so a fully explicit response shape would help, but the enumerated metrics close most of that 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?

Schema description coverage is 100% for the single optional tenant_slug parameter, so the schema already carries the semantic weight. The description only repeats 'Optionally scoped to a tenant' without adding format, defaults, or behavior beyond the schema.

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 the FLOCORE work-queue summary') and enumerates concrete metrics: status, depth, oldest-queued age, awaiting-human, dead-letter, stuck. This makes the tool's purpose unmistakable and distinguishes it from siblings 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 use case is implied: an agent would call this when it needs an aggregate work-queue summary rather than individual ticket details. However, there is no explicit when-to-use guidance or mention of alternatives, leaving routing to siblings like flocore_list_tickets 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond those annotations: every result is provenance-stamped with who/source/trust, and retrieval is hybrid-lite over the semantic world-model. No contradiction with annotations exists.

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 with the core usage pattern. Both sentences earn their place: the first establishes what the tool does, the second adds retrieval mode, provenance behavior, and safety context. There is no filler.

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 no output schema, the description does provide some useful return context by noting provenance stamping, but it does not fully describe the result shape, behavior with no matches, or how scope values relate to silos. Still, for a three-parameter read-only tool with full schema coverage and strong annotations, the core information an agent needs to call it correctly is present.

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 all three parameters. The description's 'what do I know about X?' and 'silo-scoped' loosely reinforce query and scope semantics but add little beyond what the schema fields already state.

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 ('Ask') and resource ('FLOCORE's MEMORY') and gives an illustrative query pattern, so the operation is clear. It is distinguishable from the ticket/tenant tools, but it does not explicitly contrast with the similarly named flocore_ask sibling, so it stops short of full differentiation.

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 context through 'Ask FLOCORE's MEMORY' and 'Read-only, silo-scoped', signaling it is a safe retrieval operation. However, it does not state when to use this tool instead of flocore_ask or other siblings, nor does it give any exclusions or alternatives.

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, so the description correctly aligns with these. It adds context about the governance model (human-approval gate, Ed25519 signatures) and emphasizes that the tool is public and intended for counterparties, which is beyond the annotation's scope. No contradiction.

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, focused sentence that front-loads the primary use case. It includes a second sentence about public access, which is useful but could be seen as slightly tangential. The structure is effective, though it could be tightened by trimming the exclamation.

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 verification tool with full schema coverage and annotations covering safety, the description is largely complete. It explains the purpose, the context (pre-transaction), and the security model. It doesn't mention error handling or what happens if the verification fails, but that is often not necessary given the simplicity and annotations.

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 coverage is 100%, so the schema already documents all three parameters. The description adds context about the receipt's `canonical` and `signature_ed25519` fields being used together for verification, but it doesn't add much beyond what the schema descriptions state. The description implies the semantics but the schema already covers it.

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 ('check'/'verify') and a clear resource (counterparty agent governance). It distinguishes this tool from siblings by focusing on governance verification and receipt checking, which is unique among the listed siblings that involve tickets, tenants, and mesh lanes.

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 states when to use: 'Before transacting with another agent'. It also indicates the verification of receipts if one was handed over. No explicit alternatives are named, but the context is clear and it implies this is the pre-transaction check, setting it apart from other actions like onboarding or creating tickets.

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