ASTRA Unified Research Lab MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.0.0
Disambiguation3/5
The prefix-based names help distinguish subsystems, but there is overlap among status/metrics tools (e.g., get_metrics vs tcai_metrics vs np_status) and multiple consciousness-assessment tools (tcai_metrics, tcai_metaconsciousness, get_acm_score) that could confuse an agent. The descriptions clarify, but the boundaries are not always distinct.
Naming Consistency4/5
Most tools follow a prefix_noun_action pattern (e.g., tcai_memory_retrieve, orch_gate_config, wm_predict), and the non-prefixed tools consistently use verb_noun (get_system_status, set_parameter). Naming is largely predictable, though a few tools like simulation_control or export_snapshot deviate slightly in placement of the verb.
Tool Count2/5
With 62 tools, the server is far above the typical 3-15 well-scoped range. The broad domain justifies some expansion, but the large number of status/query tools (get_system_status, get_metrics, get_snn_state, wm_status, sensor_status, np_status, ovo_status) feels redundant and could be consolidated.
Completeness4/5
The tool surface covers the main workflows across TCAI, Orch OR, sensors, world model, and NeuroPlatform, with a strong mix of actions and queries. Minor gaps exist, such as no direct memory update/delete beyond store/retrieve, and no granular sensor configuration other than set_parameter.
Average 2.8/5 across 62 of 62 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the full burden. It discloses no behavioral traits: no effects, no side effects, no return behavior, no mention of what happens to the sensor data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specification rather than effective conciseness. A four-word phrase conveys no operational meaning and fails to earn its place; more detail is needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no annotations, and no output schema, the description provides zero actionable context. It does not help the agent understand inputs, outputs, or the tool's role within the larger system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has three booleans (includeAudio, includeVisual, includeOlfactory) with 0% description coverage. The description does not mention these parameters or explain their role in fusion, leaving the agent without semantic understanding of how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is 'Cross-Modal Attention Fusion' – a noun phrase with no verb. It merely restates the tool name 'sensor_fuse' in different words, offering no concrete action or resource. It does not distinguish from sibling sensor tools like sensor_audio or sensor_visual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention any condition for use, nor does it differentiate from other fusion or sensor-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 says nothing about side effects, read-only nature, return values, or any other behavior. The phrase 'Bio-Computing Platforms' is opaque and gives no clue about what the tool actually does or what happens when invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not appropriately concise; it is an under-specified label that fails to communicate any actionable information. A single vague phrase does not earn its place and would ideally be replaced with a meaningful sentence describing the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple tool with no parameters, the description is incomplete. It does not explain what 'platform status' refers to, what data or information is returned, or how it relates to sibling tools. The lack of annotations and output schema further increases the burden on the description, which it completely fails to meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and is fully covered by the schema itself (100% coverage), so there are no parameter meanings for the description to clarify. Following the baseline for 0 parameters, a score of 4 is appropriate, though the description itself adds no value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bio-Computing Platforms' is a noun phrase that does not state what the tool does. It lacks a verb and resource, and fails to distinguish the tool from siblings like get_system_status or get_metrics, which likely return status/metrics. The tool name 'get_platform_status' suggests a status retrieval, but the description does not confirm or explain this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided. Sibling tools with similar names (get_system_status, get_metrics) exist, but the description does not clarify which one to choose for a given task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only says 'Spike Injection' and gives no indication of state changes, side effects, or consequences, making the tool's behavior completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than effective conciseness. It wastes the opportunity to convey critical operational details, making it almost useless for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and two parameters, the description is supposed to provide essential context. It provides none, making the tool impossible to invoke correctly based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines neuronIds (array of integers) and strength (number, default 15), but the description adds no meaning to these parameters. With 0% schema description coverage, the description fails to compensate for the lack of parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Spike Injection' is essentially a restatement of the tool name, providing no concrete action or resource. It does not distinguish the tool from siblings or explain what 'spikes' are being injected into, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description lacks any context, preconditions, or exclusions, leaving the agent without direction on appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 fails to disclose what 'advancing' does to the simulation state, whether it mutates internal state, whether it requires initialization, or what side effects occur. The description provides zero behavioral information beyond the word 'advance'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (four words), but this is under-specification rather than effective conciseness. It does not provide enough information to be useful, so the single sentence does not 'earn its place'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and minimal input schema, the description needed to explain what the tool does and what happens when invoked. It fails to provide any meaningful context, making the description inadequate for an agent to understand the tool's role or effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'steps' with a default, minimum, and maximum, but no description. The schema description coverage is 0%, so the description must compensate. It does not mention 'steps' at all, leaving the parameter's meaning and usage completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Advance SNN Simulation' provides a verb and a resource, but it is essentially a paraphrase of the tool name 'snn_step' and lacks specificity about what advancing entails (e.g., number of steps, time increment). It does not distinguish this tool from siblings like 'snn_reset' or 'get_snn_state', making the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any preconditions, frequency of use, or contexts where another tool would be more appropriate. With no usage context provided, the agent is left to guess when this tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It gives no indication of whether this is a read-only operation, whether it persists data, or what side effects might occur. The cryptic pipeline label offers no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, bordering on under-specification. While it avoids verbosity, it also fails to provide meaningful content, making the brevity a liability rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested object schema, no annotations, and no output schema, this description is grossly inadequate. The agent cannot determine the tool's purpose, input requirements, or expected output, making it impossible to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter ('input') with a description, yielding 100% coverage, so the baseline is 3. However, the description text adds no parameter information, and the nested properties lack individual descriptions, leaving the agent to infer meanings from names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Koniku Kore Olfactory Encoding (Chemoreceptor → Latent)' reads as a title rather than a clear functional statement. It hints at a transformation from chemoreceptor signals to latent representations but lacks a specific verb and resource, and does not distinguish it from sibling tools like sensor_visual or sensor_audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without any contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a description that merely repeats the name, the tool fails to disclose any behavioral traits such as side effects, state changes, or whether operations are destructive. The commands start/stop/status imply state transitions, but the description offers no explanation of their consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than concise. It contains no useful information and does not earn its place; it is essentially just the tool's title with no elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for a tool that controls a simulation. It lacks any explanation of what the commands do, what the output might be, or how this tool fits into the broader system, making it impossible for an agent to use it correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for parameter semantics. It does not, leaving the agent to rely entirely on the enum values start/stop/status, which are self-explanatory but lack any added context about required arguments, defaults, or effects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Simulation Control" is a tautology that restates the tool's name without specifying a verb or resource. It does not clarify what the tool actually does, making it indistinguishable from many sibling tools that also operate on simulations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description gives no context about appropriate scenarios, prerequisites, or exclusions, leaving the agent to infer usage solely from the name and the command enum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention whether the tool mutates the model, what side effects occur, if it requires prior observations, or whether it is a training step that adjusts weights. The description is completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single nominal phrase and contains no redundant words, but it is severely under-specified. This is not conciseness but lack of information, matching the calibration for under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested action object and represents a training step, yet the description provides no elaboration on the training process, expected outcomes, or preconditions. Without annotations or an output schema, this is completely inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 'action', 'targetNeurons', 'strengths', and 'duration' (100% coverage). The tool description adds no further meaning to these parameters, but because the schema already covers them, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Online World Model Training Step' is essentially a restatement of the tool name 'wm_train_step'. It fails to specify what action the tool performs (e.g., 'Trains the world model on a given action') and does not distinguish itself from sibling training-related tools like wm_encode or wm_predict. The purpose is only vaguely implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or relationships to sibling tools such as wm_predict or wm_surprise, leaving the agent without context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals nothing about side effects, permissions, return values, or whether this is a safe read operation. The description is effectively empty of 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It does not earn its place because it adds no meaningful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter details, the description is drastically incomplete. It fails to convey what the SNN engine state includes, how it might be used, or what the agent should expect from the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. Per the rubric, a zero-parameter tool receives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'SNN Engine State' is a noun phrase that merely restates the tool name without a verb or resource action. It does not differentiate from sibling tools like get_system_status or get_acm_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as snn_step, snn_reset, or get_metrics. The description lacks any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must convey behavioral traits. 'Modify' implies mutation, but no details are given about side effects, persistence, reversibility, permissions, or what happens to existing state. This is minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks the substance needed to make the tool safely usable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a large set of sibling tools, this description is inadequate. It does not explain the scope of the state parameter, the expected path format, or the effect of setting a value, leaving too much ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 'path' or 'value', their relationship, expected formats, or any constraints. The parameter names are somewhat self-evident, but the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Modify State Parameter' essentially restates the tool name and does not specify which state parameter is being modified, how, or in what context. It fails to distinguish this tool from the many sibling tools that deal with state management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the large sibling list with many state-related tools, the absence of any usage context makes it difficult for an agent to select this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, but it reveals nothing about side effects, permissions, input/output behavior, or whether this is a read or mutating operation. The one-line label provides no actionable 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, this is under-specification rather than effective conciseness. It is a single phrase that fails to utilize the space to convey anything useful about the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with a nested parameter object and no annotations or output schema, yet the description provides no context about what surprise detection does, how it uses the action, or how it relates to other working memory tools. Highly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'action' object and its properties are fully described in the schema), so the baseline is 3. The description adds no extra parameter meaning, but the schema already documents targetNeurons, strengths, and duration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Violation-of-Expectation Detection' is a noun phrase that essentially restates the tool name (surprise = violation of expectation). It lacks a specific verb and resource, and does not differentiate from sibling prediction tools like wm_predict. This is tautological rather than explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information about when to use this tool versus alternatives such as wm_predict or wm_encode. Completely lacks context or exclusions, providing zero guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects, output characteristics, or whether the operation is read-only. 'Full State Snapshot' reveals nothing about behavior beyond the tool's name, leaving the agent completely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than effective conciseness. A three-word noun phrase does not provide enough content to fulfill the tool's documentation purpose, mirroring the 'Process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameters, the description needed to explain what 'full state' includes, how the snapshot is returned, and how to interpret results. It provides none of this, making the tool nearly unusable for an AI agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema contains no properties to document. Per baseline rules, a 0-parameter tool receives a 4 for this dimension, even though the description adds no parameter-related value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full State Snapshot' is essentially a restatement of the tool name 'export_snapshot'. It does not include a specific verb or clarify what the snapshot contains, and it fails to distinguish from sibling tools like get_system_status or orch_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about typical use cases, prerequisites, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only says 'Consciousness Assessment (Proxy)' with no mention of side effects, return values, or operational characteristics, making the tool completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. The phrase 'Consciousness Assessment (Proxy)' is a vague label that doesn't earn its place because it provides no actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description needed to explain the return value and interpretation. It doesn't. The tool's purpose, output, and context are all missing, making it inadequate even for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100% trivially. The description adds no parameter information, but with no parameters, there is nothing to explain. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Consciousness Assessment (Proxy)' is a noun phrase without a verb, essentially restating the tool's name (get ACM score = consciousness assessment). It adds only the vague qualifier 'Proxy' and fails to specify what action is performed or what the score represents, nor does it distinguish from sibling tools like tcai_metaconsciousness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No use cases, prerequisites, or exclusions are mentioned. Among many tcai_* and get_* sibling tools, this description provides no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of disclosing behavior. It fails to mention whether this is a safe read operation, what data is returned, or any side effects, offering only a static label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words is under-specification rather than conciseness. The description lacks any useful structure, front-loading, or informative content that would help the agent understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With many status-related siblings, this description is completely insufficient. It does not describe what 'system status' includes, the return format, or any operational context, making the tool's behavior opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema fully covers them (vacuously), so the description does not need to explain parameters. The minimal description does not add parameter info, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ASTRA System Status' is a short label that restates the tool's name without a clear verb or resource scope. It does not differentiate from sibling tools like get_platform_status or get_metrics, leaving the agent unsure what specific status it retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description gives no indication of when to choose this tool over alternatives such as get_platform_status, wm_status, or get_metrics, making it hard for the agent to make an informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but 'Real-time Metrics' reveals nothing about side effects, permissions, return format, or whether it is read-only. It fails to disclose any behavioral traits beyond a vague temporal attribute.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a two-word fragment. While extremely short, it is under-specified rather than appropriately concise. It lacks a full sentence structure and fails to convey enough information to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a highly ambiguous description, the tool's behavior and return values are unexplained. The sibling list includes several metrics-related tools, further increasing the need for contextual clarity that this description does not provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). Per the instructions, a baseline score of 4 applies for 0-param tools. The description adds no parameter-specific meaning, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Real-time Metrics' is a noun phrase that essentially restates the tool name 'get_metrics' with the modifier 'real-time'. It does not specify an action (e.g., 'retrieve', 'fetch') and does not distinguish itself from siblings like tcai_metrics or get_system_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no indication of preferred contexts, exclusions, or even a hint about what distinguishes 'get_metrics' from other metric-related tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, whether it mutates state, what it returns, or what side effects it may have. The phrase 'Planning' alone is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically concise but under-specified. It is a single phrase that does not convey enough information to be useful. The lack of structure and detail constitutes under-specification, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects, two parameters, no output schema, and no annotations, the description must explain purpose, behavior, and outputs. It only gives a vague title and fails to describe how the goal and horizon parameters relate to the planning process or what the result looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (goal and horizon both have descriptions). The tool description adds no parameter-specific meaning, but the baseline of 3 applies because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'CEM Planning for Optimal Spike Injection' is a noun phrase that vaguely indicates the tool performs planning for spike injection, but it lacks a clear verb and resource. It does not distinguish the tool from siblings like wm_predict or wm_surprise, and the acronym 'CEM' is unexplained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of contexts, prerequisites, or exclusions, leaving the agent to infer usage purely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only contains a short label with no explanation of side effects, return values, permissions, or what the 'check' involves. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, which is concise, but it sacrifices clarity. It is not a tautology, but it is under-specified. The phrase 'Neural Welfare Check' is likely a domain-specific term that is not defined, so it fails the 'every sentence earns its place' test because it doesn't communicate enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameter details, the description is the sole source of context. It is far too incomplete to allow an agent to understand what the tool does, when to call it, or what to expect from it. The tool's behavior remains entirely opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter syntax or meaning. The baseline of 4 applies, and the description adds no unnecessary information, but also no useful context about what the check covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'IRB Neural Welfare Check' suggests the tool performs a welfare/ethics check on a neural system, but it lacks a clear verb and resource. It distinguishes from siblings by topic, but the exact action is vague. A more explicit phrase like 'Check the ethical/welfare status of the neural system' would be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. With a large list of sibling tools like tcai_metrics, get_metrics, and sensor_status, the description provides no context about scenarios where check_ethics is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only hints at the output ('descriptor + viability'). It does not state whether the operation is read-only or has side effects, nor does it mention permissions, rate limits, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It reads as a fragment and omits essential information such as the action performed, making it less useful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain what 'descriptor + viability' means in return terms, but it does not. It also fails to clarify whether this is a capture or retrieval operation, leaving major gaps in understanding the tool's purpose and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'mea', which is fully described with constraints and default. The tool description adds no additional parameter meaning, but the schema already handles it, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks a clear verb; 'Last MEA camera capture' is a noun phrase, so it's unclear whether the tool performs a capture or retrieves the last capture. It mentions the resource (MEA camera) and output (descriptor + viability), but does not explicitly state the action or distinguish from sibling tools like sensor_visual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without context for selecting it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only lists state labels and does not indicate whether this is a read-only operation, what the response format is, whether it triggers side effects, or any permissions required. The lack of behavioral context makes the tool unpredictable for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient line with no filler or unnecessary words. It is front-loaded with the main topic and then enumerates specific state aspects. The lack of a verb is a content issue, not a conciseness issue, so conciseness merits a full score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must stand alone, but it is too sparse. It names several state dimensions but does not explain their meaning, format, or interpretation. The tool appears to be a state accessor, but the description does not provide enough context for correct invocation or expectation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so there is no obligation to document parameter meaning. The schema is empty, and the baseline for zero-parameter tools is 4. The description's list of state components likely refers to output fields, not inputs, so no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase listing components ('ignition, focus, qualia, sync R, unity metrics, access history') with no verb indicating the tool's action. It doesn't explicitly state whether the tool retrieves, computes, or updates state, making the purpose ambiguous. It does list specific metric names, slightly distinguishing it from siblings, but the core action is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like tcai_metrics, get_metrics, or tcai_self_model. There are no context cues, prerequisites, or exclusions mentioned, leaving the selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of disclosing behavior. The word 'Status' weakly implies a read-only operation, but the description does not explicitly state that it returns information, what information it provides, or whether any side effects exist. It adds very little beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single noun phrase without a verb or context does not earn its place; it reads like a title, not a functional description. There is no structure that helps an agent understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of numerous sibling status tools, the description is not complete enough to disambiguate. It fails to explain what 'Platform & Controller' encompasses, what output to expect, or how this differs from get_system_status, get_platform_status, or other status tools. The lack of annotations and output schema makes this minimal description insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does not need to explain parameter semantics, and there is no schema information to supplement. It cannot add value beyond the empty schema, so the baseline score holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Platform & Controller Status') rather than a clear verb-action statement. It implies the tool reports status but does not explicitly state what it does (e.g., 'Retrieves current platform and controller status'). It also does not distinguish this from several sibling status tools like get_system_status, get_platform_status, or ovo_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it differs from alternatives. With several status-related siblings, the description should mention that this is the go-to for platform/controller health or clarify its scope, but it omits any such context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the model name and modality, omitting any details about side effects, whether it captures from a camera, the role of the 'simulate' flag, return values, or whether it is a read-only operation. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single noun phrase, which is concise but severely under-specified. It lacks sentence structure and does not expand on what the tool does beyond the name. This is closer to a title than a description, reflecting under-specification rather than effective brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters with a nested object, no output schema, and no annotations. The description fails to explain the purpose of the encoding output, usage context, or relationship to other sensor tools. It is far from complete for an agent to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds the dimorphic 'Image/Video' context, but the schema already explains videoFrames with '>1 = video'. The description does not add meaningful semantics beyond the schema, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'V-JEPA 2 Visual Encoding (Image/Video)' identifies the specific model (V-JEPA 2) and the modality (image/video), clearly distinguishing it from sibling sensors like sensor_audio and sensor_olfactory. While not a full verb phrase, it conveys the tool's function as an encoding operation for visual input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include sensor_audio and sensor_olfactory, but the description does not mention any selection criteria, prerequisites, or contrast with other sensors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the operation is read-only, what data is returned, or any side effects. This is a significant gap for a tool that presumably queries status/metrics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it is essentially just a title. It fails to provide any explanatory value beyond what the name already implies, so while there is no waste, it does not earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and many sibling tools, the description should clarify what specific status/metrics are included and what makes it unique. It does not, leaving the tool's functionality and scope ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty property set). Per the rubric, the baseline is 4 even if the description adds no parameter details, which is the case here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'World Model Status & Metrics' indicates the tool provides status and metrics about the world model, but it lacks a clear verb and does not differentiate from similar sibling tools like get_metrics or get_system_status. It's a noun phrase rather than a specific action or resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With siblings like get_metrics, get_system_status, and wm_surprise, the description does not state any distinguishing conditions or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose side effects and safety. It mentions optional SNN driving and ethics coupling, which hint at state changes, but does not explain whether the operation is read-only, modifies the organoid/SNN state, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the platform name and core concept. Every word contributes; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 4 parameters and no output schema, yet the description provides only a high-level pipeline. It doesn't explain expected return values, invocation behavior, or how parameters affect the closed loop, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 75% of parameters with descriptions. The description rarely references the parameters: 'optionally drive the SNN' corresponds to drive_snn, but window_ms and drive_strength are not addressed. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a closed-loop coupling action ('read organoid → couple to ASTRA fusion/ROS/ethics, optionally drive the SNN') but lacks an explicit verb naming the operation (e.g., 'run', 'trigger', 'configure'), making it ambiguous what invoking the tool does. It partially differentiates from siblings by mentioning ASTRA/ROS/ethics, but the purpose remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like np_send_trigger or inject_spikes. The description implies a closed-loop use case but does not state conditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states that the tool returns spike timings over a window, but does not explain whether the window is relative to current time, how limit affects results, or what fsname refers to. This lacks the detail needed to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, making it concise and front-loaded with the core concept. It is not overly verbose, but it could be slightly more structured by explicitly naming parameters or the action. Still, it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description is too brief. It does not describe the return format, the meaning of the parameters beyond 'window', or any edge cases or limitations. The tool may be simple, but the description lacks essential context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only window_sec has a schema description). The description adds minimal context by mentioning 'over a window,' which aligns with window_sec, but it says nothing about limit or fsname. Thus, it does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'individual spike timings over a window,' which identifies the resource (spike events) and distinguishes it from sibling count tools like np_count_spikes and np_query_spike_count. However, the verb is implied by the tool name ('query') rather than explicitly stated, and there's no explicit differentiation from other spike-related queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or comparisons to siblings such as np_query_spike_count, np_count_spikes, or np_query_triggers, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose side effects, state changes, output, or prerequisites. It only names the pipeline and output ('Fused z'), offering no behavioral detail. No contradictions with annotations since none were provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact phrase with no filler or redundant words. It is front-loaded and readable, though arguably too terse to convey much substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should explain what 'fused z' is, whether the pipeline mutates state, and how this differs from sensor_fuse. The current one-liner leaves too much implicit for an AI agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description need not repeat parameter details. It adds no semantic value beyond the schema, but the baseline of 3 applies because all three properties (compounds, visualSource, audioFrequency) are already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description identifies tool as a full multimodal pipeline that processes all modalities and produces a fused 'z', which distinguishes it from individual sensor tools. However, it lacks an explicit action verb, relying on the noun 'Pipeline' to imply execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus sensor_visual, sensor_audio, sensor_olfactory, or sensor_fuse. The phrase 'All Modalities' implies broad use, but there are no explicit conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action 'Configure' without mentioning side effects, reversibility, authorization requirements, or whether changes take effect immediately or persist. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and object, with no redundant or extraneous information. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration tool with 5 optional parameters and no output schema, the description is too brief. It omits essential context such as the effect of setting these policies, whether protocolReference is required to arm the control loop, and how this tool relates to the broader OVO workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only protocolReference has a description). The description mentions the two policies but does not map them to specific parameters like dominancePolicy or controlEnabled, nor does it explain the enum values or the role of maxStepPerCycle. It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Configure' and identifies two clear targets: the Russell→PAD dominance policy and the closed-loop control policy. This differentiates it from sibling tools like ovo_status or ovo_read, though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related tools such as ovo_arm_control or set_parameter. No prerequisites, conditions, or context are provided, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Status' implies a read-only operation but does not explicitly state behavioral traits, what is returned, or any side effects. The description adds minimal transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It is concise but reads as a title rather than a complete sentence with a verb. It could be improved by adding a verb and more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is minimal. However, there are many sibling status/state tools, and 'status' is ambiguous (health, metrics, configuration, etc.). More context would be helpful, but for a 0-parameter tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is trivially 100%. With no parameters to describe, the baseline of 4 applies as the description does not need to compensate for missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Multimodal Sensor Pipeline Status' is a noun phrase without an explicit verb. It indicates the tool reports status of a multimodal sensor pipeline, but it is vague and doesn't clearly distinguish from sibling status tools like sensor_fuse or get_system_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as sensor_visual, sensor_audio, sensor_fuse, or get_system_status. No context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. 'Reset SNN Engine' discloses no side effects, state changes, whether it is destructive, or what the tool actually resets. For a mutation-like operation, this is a critical transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the essential action. It is efficient, though possibly too sparse to fully inform an agent, but it earns a good score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely side effects and lack of annotations or output schema, the description is insufficiently complete. It does not explain what state the SNN engine resets to, what is cleared, or what the agent should expect, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description adds no parameter information, but none is needed; the empty schema already fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reset SNN Engine' uses a specific verb and resource, clearly indicating the action on the SNN engine. It distinguishes from siblings like snn_step and get_snn_state, though it does not explicitly contrast with tcai_reset, leaving minor ambiguity among reset tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as snn_step or get_snn_state. No context, prerequisites, or exclusions are given, leaving the usage conditions entirely unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior (e.g., read-only, side effects, required permissions). It only says 'Closed-loop', which is vague and does not clarify whether the operation is safe or part of an active control loop. No behavioral traits are explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and does not waste words. It is front-loaded with the tool name and purpose, though the phrasing is somewhat awkward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema, so the description does not need to be lengthy. However, it lacks context about the meaning of 'closed-loop' and does not explain what the tool returns (e.g., a list of electrode counts). This leaves gaps for a non-expert agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'top_k' and 'window_ms' having descriptions. The description adds no additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates a spike-counting function over a time window ('spikes per electrode over an N-ms window'). However, it does not explicitly differentiate from the similar sibling tool 'np_query_spike_count', and the phrase 'Closed-loop _count_spike' is somewhat cryptic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as 'np_query_spike_count' or 'np_query_spike_events'. There is no mention of conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does not state whether the operation is read-only, what the return format is, or whether there are side effects. It only labels the query without adding context beyond the schema's window and dedup parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and front-loaded, with no filler or redundant content. It sacrifices behavioral detail for brevity, but as a one-phrase description it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks an output schema and provides no usage context, leaving gaps about response contents and differentiation from sibling tools. The parameter schema is strong, but the description alone is incomplete for an agent deciding whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (dedup and window_sec) having clear descriptions, so the description adds no extra parameter semantics. Baseline 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a query for triggers sent to an organoid over a window, distinguishing it from trigger-sending tools like np_send_trigger. However, it lacks an explicit verb (e.g., 'Lists' or 'Retrieves'), relying on the noun phrase 'TriggersQuery'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like np_query_spike_events or np_query_spike_count. The description does not mention use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not explain side effects, safety, reversibility, permissions, or what happens when triggers are fired (e.g., hardware activation). This is a significant gap for a tool that likely has physical or system-level consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and concise, but it uses jargon ('NeuroPlatform v2', 'StimParams', '16-bit trigger array') that might reduce clarity. It is not verbose, and every word adds some information, though the structure could be improved by separating context from action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema but no output schema and no annotations. The description is insufficient for an agent to understand the full context: it lacks return behavior, side effects, prerequisites, and integration with sibling tools. For a trigger-sending tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters with clear descriptions for 'repeats' and 'triggers'. The description adds the context of 'uploaded StimParams' and '16-bit trigger array', which gives some extra meaning, but the schema already provides sufficient parameter documentation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fires triggers and executes uploaded StimParams via a 16-bit trigger array, using specific verbs like 'fire' and 'execute'. While it doesn't explicitly distinguish from siblings, the purpose is understandable, though the meaning of 'execute uploaded StimParams' could be clearer for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like np_configure_stim or np_query_triggers. It does not mention prerequisites (e.g., StimParams must be uploaded first) or when not to use it. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It says the tool 'run[s] a TCAI cycle' and 'pass[es] the workspace competition through the gate', implying state changes, but it only mentions reporting a count. No info on side effects, prerequisites, reversibility, or failure behavior is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It packs a lot of information into a compact format and ends with a clear statement about the report. Well-structured for the amount of content it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the operation, the absence of annotations, an output schema, and any explanation of the parameter, the description is incomplete. It does not clarify what 'epoch-quantised surrogate gate' means, prerequisites, or why this composite cycle exists versus calling sibling tools separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'controllability', is completely unexplained in both the schema and the description. Schema coverage is 0%, and the description does not mention the parameter at all. The agent has no way to know what values to supply or the effect of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific orchestrated action: reading an OVOMIND affect frame, running a TCAI cycle, and passing the workspace competition through a surrogate gate. This involves distinct verbs and resources, and the mention of the 'epoch-quantised surrogate gate' helps differentiate it from sibling tools like tcai_cycle or ovo_cycle. However, heavy jargon limits universal clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a composite use case but does not explicitly explain when to prefer this tool over alternatives like tcai_cycle, ovo_cycle, or orch_gate_config. No exclusion or alternative guidance is given, leaving the agent to infer usage from the action list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of disclosing side effects and operational characteristics. It does not state whether the tool is read-only, computationally expensive, requires specific permissions, or how it interacts with ASTRA's channel beyond the output components. The description focuses on content rather than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, listing the key output components in a compact structure. While it is efficient, the sentence is somewhat dense and would benefit from a clearer subject-verb-object structure to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the domain (Orch OR, ASTRA, multiple optional parameters) and the lack of an output schema and annotations, the description is insufficient for an agent to confidently call the tool. It does not explain the semantics of the optional parameters, the expected return format, or enough context about the 'verdict' to interpret results. The description is a minimal stub rather than a complete usage guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameter meaning and usage. It explicitly references only 'substrate' via the phrase 'for one substrate'; the other parameters (neuronCount, channelLatencyMs) are not mentioned. The description does not clarify whether these parameters influence the verdict or how they relate to the listed output components.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool provides an 'Orch OR verdict for one substrate' and enumerates the components (tubulin budget, epochs, reasoning), which distinguishes it from sibling tools that operate on different scopes or criteria. However, it lacks an explicit verb like 'retrieves' or 'computes', and the jargon (Orch OR, ASTRA's channel) is not explained, making the purpose somewhat opaque.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one substrate' implies that this tool is appropriate when a verdict for a specific substrate is needed, offering a context hint. However, it does not explicitly state when to use it over alternatives (e.g., orch_report, orch_criterion) or provide any exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behaviors. It only sketches a processing pipeline (Waveform → Mel → Latent) but does not mention whether it captures from a real microphone, whether simulation is the default, what the output looks like, or any side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, using a compact pipeline notation. It packs the core transformation into one line, but sentences are not sacrificed; this is appropriately terse for a simple sensor tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested input object with six properties, no output schema, and no annotations, a one-line description is inadequate. It fails to explain the return value, the meaning of the parameters, or the context in which audio encoding is needed, leaving agents under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond the schema. Although schema description coverage is reported as 100%, the schema itself leaves several nested properties (source, channels, durationMs, sampleRate) without descriptions. The baseline of 3 for high coverage applies, but the description does not compensate for those gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'A-JEPA Audio Encoding (Waveform → Mel → Latent)' clearly indicates the tool converts audio waveforms into a latent representation via mel spectrogram, specific to audio and distinct from sibling sensors. However, it is a noun phrase rather than an active verb construction, slightly reducing directness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sensor_visual or sensor_olfactory. The schema's simulate flag is not explained in the description, nor are any prerequisites or use cases mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It only provides a nominal label and metric list, without stating whether this is a read-only report, what side effects exist, or what the output looks like. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, a single fragment that efficiently lists the report type and key metrics. It is not verbose and every word adds information, though it is structurally a fragment rather than a complete sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no parameters, so the description is the only source of information. It names the metrics but doesn't explain what 'composite score' means, how the report is presented, or how to interpret the values. This is a notable gap for a report tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered by default. There are no parameter semantics to describe, and the baseline of 4 applies because the description doesn't need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'Consciousness proxy report' and names specific metrics, which gives it some clarity. However, it lacks an explicit verb like 'get' or 'generate', making the action somewhat implied. It does distinguish from siblings by naming unique metrics like GNW and Φ̃-RIIU, but only partially.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as tcai_self_model or get_metrics. No usage context, when/when-not conditions, or alternative references are provided, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states 'Predict', which implies a non-mutating operation, but does not clarify whether it requires prior encoding, whether it has side effects, or what the output format is. 'In Latent Space' adds minimal context but not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 7-word sentence with no filler or redundancy. It front-loads the primary verb and object, achieving maximum efficiency. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns, preconditions, and how the action affects the prediction. It provides only a high-level phrase, leaving the agent to guess at critical behavioral details. The rich schema helps but cannot compensate for the absence of output and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters ('steps' as 'Number of prediction steps (rollout)' and 'action' as 'Spike injection action to condition prediction on'), so schema coverage is 100%. The description itself adds no parameter details, but the baseline score of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Predict' and names a specific resource 'Next SNN State in Latent Space', making the core action clear. However, it does not explicitly distinguish itself from sibling tools like wm_plan or snn_step, which could also involve prediction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description gives no indication of when to use this tool versus alternatives like snn_step or inject_spikes, nor does it mention that prediction is conditioned on the 'action' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It reveals the content areas of the state but says nothing about side effects, access requirements, or whether the state is computed on demand or cached. It does not explicitly state that this is a read-only operation, which is a significant gap for a tool that likely returns a snapshot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact phrase that front-loads the core concept ('Self-representation state') and then lists four concrete components. There is no redundancy or filler. Every word contributes to the meaning, making it appropriately concise and well-structured for a zero-parameter state query.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description gives enough to infer the tool's domain but not the full picture. It fails to mention the return type or how the state is presented (e.g., JSON object, numerical values). It is minimally viable but leaves notable gaps, especially around interpreting the listed components.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 correctly does not need to elaborate on parameter meaning. The empty input schema is consistent with the description, and no further clarification is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as exposing 'Self-representation state' with specific components (interoception, epistemic model, etc.), which gives a clear subject area. However, it lacks an explicit verb (e.g., 'get', 'retrieve', 'display'), so the exact action is implied rather than stated. It partially distinguishes from siblings by listing unique aspects, but without a verb it remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like tcai_second_order or tcai_workspace_state. It does not mention any exclusions, prerequisites, or typical use cases. The reader is left to infer that this is a state query, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions 'NeuroPlatform v2 DB' and 'query', implying a read-only database operation, but it does not explicitly confirm read-only behavior, side effects, output format, or performance characteristics. Minimal contextual information beyond the tool's existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler. It immediately conveys the tool's purpose, data source, and key output metric, using a clear front-loaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has no output schema. The description communicates the core output concept (spikes/minute per electrode) but omits details about the exact return structure, defaults, or how window_sec and nonzero_only affect the response. It is adequate for a basic query tool but leaves room for interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover fsname and window_sec, while nonzero_only lacks a description. The tool description's phrase 'over a time window' adds context to window_sec, but it does not explain nonzero_only or add meaning to fsname beyond the schema. With 67% schema coverage, the description only partially compensates for the missing parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description defines the tool as a 'SpikeCountQuery' returning 'spikes/minute per electrode over a time window', clearly identifying the resource (spike counts per electrode) and the computation. However, it lacks an explicit verb like 'queries' or 'returns', and while it differentiates from event-based tools such as np_query_spike_events, it does not clearly distinguish from the similarly named np_count_spikes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool instead of siblings like np_query_spike_events or np_count_spikes, nor does it mention prerequisites, limitations, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one important behavioral trait: the human valence is NOT routed to rewardSignal. However, it omits other behavioral details such as side effects, state changes, or prerequisites for running the cycle, leaving the agent to infer the full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, consisting of two sentences that state the core action and a key exception. It avoids filler but uses domain jargon without explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a non-trivial execution (running a cycle), the description is too sparse. It doesn't explain return values, side effects, or how this tool relates to sibling tools, making it incomplete for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 'actuate' but leaves 'controllability' undescribed, and the tool description doesn't elaborate on either parameter. With only 50% schema description coverage, the description should compensate but doesn't, leaving the agent without semantic clarity on the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one affect frame and runs a TCAI cycle, with the human channel as 'body' specialist. It adds a specific behavioral exception (valence not routed to rewardSignal), which differentiates it from generic TCAI/OVO siblings, though it doesn't name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like tcai_cycle or ovo_read. The description implies a specific use case (human affect frame processing with a routing exception) but doesn't provide exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists the kind of status data returned but does not state whether the operation is read-only, has side effects, or requires any setup. With no annotations provided, the description carries full responsibility for behavioral disclosure, and it falls short by not confirming it is a safe, non-mutating status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loads the core concept 'OVOMIND bridge status'. It is efficient, though the dense jargon ('adapter mode', 'substrate descriptor', 'synthetic-phenomenology ethics assessment') could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the returned status looks like. It lists the categories of information but does not provide format, units, or examples. This is acceptable for a status tool but lacks completeness for a fully self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline for this dimension is 4. The description correctly does not add parameter-specific information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports OVOMIND bridge status, listing specific components (adapter mode, substrate descriptor, frame counters, ethics assessment). This distinguishes it from generic status tools like get_system_status or get_metrics, though it lacks an explicit verb like 'retrieve' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies it is for OVOMIND-specific status, but it does not mention when not to use it or compare to sibling tools such as ovo_read or tcai_self_model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits fully. It mentions 'inertia' implying statefulness or temporal dependency, but does not explain side effects, return format, or whether it modifies internal state. The absence of explicit behavioral disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence with no redundant words. It front-loads the core purpose and the key behavioral nuance (inertia), making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, annotations, and parameter descriptions, this tool description is incomplete. It does not explain return values, how parameters interact, or what 'inertia' entails operationally. The agent would struggle to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the four parameters. However, it only refers to 'raw signals' without mapping to threat, novelty, rewardSignal, or controllability. Parameter meanings are left to name inference, which is insufficient for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Appraise' and clearly states the transformation into PAD emotional space (Mehrabian), which distinguishes it from sibling tcai tools focused on memory, curiosity, or meta-cognition. The inclusion of 'with inertia' further indicates a unique temporal aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without specifying scenarios, prerequisites, or exclusions, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. 'Encode' implies a transformation, but the description does not disclose whether this is read-only, mutates internal state, requires specific conditions, or what the output is. No behavior beyond the bare operation is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase with no filler words. It is appropriately short for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters, the description lacks any context about return values, side effects, or the meaning of 'latent space' in this system. With no annotations and no output schema, the agent is left to guess what this tool actually does beyond the phrase. It is more informative than a tautology but still incomplete for a real-world use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, and per the baseline for zero-parameter tools, the description adds context by naming the entity being operated on (SNN State) and the output representation (Latent Space), which is sufficient given there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('encode') and resource ('SNN State') with a clear target ('latent space'), distinguishing it from sibling tools like get_snn_state or wm_predict. However, it doesn't explicitly call out alternative tools, but the operation is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_snn_state or wm_predict. The one-line description lacks any context about prerequisites, typical use cases, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Define, validate & upload.' It does not mention side effects on hardware, permission requirements, reversibility, error behavior, or confirmation of successful upload, so the agent is left guessing about what actually happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise, front-loaded with the action, and contains the key domain context. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the description is too sparse for an 11-parameter hardware-upload tool with no annotations and no output schema. It does not describe what the tool returns, how uploads are confirmed, failure modes, or prerequisites, so the agent would lack essential context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 82%, so the parameters are mostly self-documenting with units, defaults, and ranges. The description adds the context of 'charge-balanced biphasic stimulation' but does not elaborate on how parameters interact or what 'validate' means for the charge-balance constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb set ('Define, validate & upload') and names a concrete resource ('StimParam (charge-balanced biphasic stimulation)'), clearly distinguishing this hardware-configuration tool from siblings like np_send_trigger or np_count_spikes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description implies an upload/configuration action but does not explain when an agent should choose it over related np_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosing side effects and state changes. It explains the computation and the default broadcast source but does not state whether the tool is read-only, whether the predictor is updated, or what the return value is. This is a significant transparency gap for a tool that may have internal state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core concept, and efficiently conveys the algorithm, interpretation, and default. The use of jargon (RND, EFE, GNW) adds density but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only one optional parameter, yet the description does not explain the return format (e.g., a scalar value). It provides good conceptual context but leaves out practical details about what the agent can expect as a result, making it adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, with the 'embedding' property described as 'Representation vector (defaults to current broadcast)'. The description reinforces the default behavior but adds no new semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an intrinsic-reward/curiosity mechanism based on prediction error, referencing RNDCuriosity and explaining the high-error-equals-novelty relationship. It distinguishes itself from sibling tcai tools by its specific algorithm and purpose, though it lacks an explicit verb like 'computes' or 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exploration or novelty-seeking ('exploration drive (EFE epistemic value proxy)') but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. The usage context is present but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden. It discloses the scoring criteria but does not explain what happens when no memories match, whether the operation is read-only, the format of returned data, or what 'blended' and 'salience' mean. 'Retrieve' implies read-only, but explicit side-effect disclosure is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and contains no redundant or filler words. It is appropriately concise for a retrieval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters, no output schema, and no annotations. The description does not mention return values, default behavior for missing parameters (only embedding has a documented default in schema), or how topK bounds results. This is insufficient for a retrieval tool where callers need to know what to expect back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80% (4 of 5 parameters have descriptions). The description adds context by linking PAD congruence to the arousal/valence/dominance parameters, but topK remains undocumented in both schema and description. The description does not add syntax or format details beyond what the schema provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with resource 'memories' and explicitly names the retrieval criteria: 'blended cosine similarity, PAD congruence and salience'. This clearly distinguishes it from sibling tools like tcai_memory_store (store) and wm_* (working memory) tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes several memory-related tools (tcai_memory_store, wm_encode, wm_recall, etc.), but the description does not mention any exclusions, prerequisites, or comparison to other retrieval mechanisms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the computation but does not disclose whether it has side effects, requires specific conditions, or what exact output format/residual gap means. It doesn't mention error behavior or assumptions. The description adds minimal behavioral context beyond the calculation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler words. It efficiently packs the key information: the quantity (decoherence time budget), the scope (target coherence window), the models compared, and the residual gap. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter, no output schema, and no annotations. The description gives the core purpose but lacks details about the return value, interpretation of the residual gap, or edge cases. It is minimally viable for an expert but leaves gaps for an automated agent that needs to know what to expect as output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, requiredCoherenceS, with 0% description coverage. The description mentions 'target coherence window' which arguably maps to the parameter, providing some semantic context. However, it doesn't explicitly explain units, constraints, or how the parameter affects the calculation beyond what the schema already states (exclusiveMinimum: 0). The parameter name is self-explanatory, so the description adds limited value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a decoherence time budget for a target coherence window, comparing Tegmark (2000) with the Hagan/Hameroff/Tuszyński (2002) correction and reporting the residual gap. This is a specific, concrete function that distinguishes it from sibling tools like orch_criterion or orch_gate_config, which address different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No exclusions, no alternative tool names, no context like 'use when X'. The only hint is 'for a target coherence window', but no comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the responsibility of behavioral disclosure. It reveals return value details ('Every axis is returned with its epistemic tier, provenance and basis string') and a key constraint ('Dominance is never estimated from the human channel'). The verb 'poll' implies a non-mutating read. However, it doesn't disclose whether the call blocks, any prerequisites, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each provides distinct information: the action, the return details, and a behavioral caveat. There is no filler or repetition; the core purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description's explanation of returned fields is valuable. However, it omits the meaning of the only parameter (controllability), provides no usage context, and does not address edge cases or call semantics (e.g., blocking, defaults). This is a significant gap for a simple tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one parameter, 'controllability' (number 0-1), but the schema description coverage is 0% and the description does not mention this parameter at all. An agent has no way to infer what 'controllability' controls or how it affects the read. With zero schema descriptions, the description must compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Poll' with a defined resource 'OVOMIND affect frame' and states it 'lift[s] it into PAD'. It also clarifies what is returned ('Every axis is returned with its epistemic tier, provenance and basis string'). This distinguishes it from siblings like ovo_status or ovo_cycle, though it doesn't explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'Poll one OVOMIND affect frame' implies this is the tool to use when you need to read affect data in PAD format, but it does not provide explicit when/when-not conditions or mention alternative tools. No exclusions or conditional usage guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. Calling it a 'snapshot' suggests a read-only operation, but the phrase 'observing and correcting its own predictive capacity' introduces ambiguity about potential side effects. It does not clarify whether the tool modifies state, requires permissions, or what the return format is, leaving key behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the first sentence listing the tool's purpose and contents. The second sentence adds theoretical context that is somewhat extraneous but not bloated. Every sentence contributes to understanding, though the reference to 'Legros 2026' is jargon-heavy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a reasonable overview of the output components and positions the tool as a meta-cognitive snapshot, which is helpful given the domain's complexity. However, it lacks details on value semantics, units, or how to interpret the combined snapshot, and it does not clearly state whether the operation is purely observational. Without an output schema, more explanatory content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty and there is nothing to describe. The baseline of 4 applies, and the description correctly adds no irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a 'second-order (self-evidencing) loop snapshot' and lists the specific components it covers (meta-learning velocity, RND curiosity, capability model, meta-consciousness score, developmental stage), which distinguishes it from sibling tools that focus on individual aspects. However, it lacks an explicit verb like 'get' or 'retrieve', leaving the action somewhat implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for obtaining a combined view of self-monitoring metrics, but it does not explicitly state when to use this tool instead of individual sibling tools like tcai_metrics or tcai_self_model. No exclusions or alternative comparisons are provided, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the mechanism ('attention-gated, salience-indexed'), which hints at behavioral nuances, but does not explain side effects, mutation consequences, or return values. This is marginal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is both concise and information-dense, front-loading the main action and adding two qualifiers. No wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is too brief to fully equip an agent. It omits what the tool returns, any prerequisites (e.g., existing memory store), and the practical effect of attention/salience settings. This is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents parameters well (83% coverage), so the description adds limited additional meaning. It ties 'attention-gated' to attentionLevel and 'emotional memory' to affective dimensions, providing some conceptual context, but doesn't explain how each parameter maps to the storage algorithm.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Store') and the resource ('an experience in emotional memory'), making the tool's purpose distinct from siblings like tcai_memory_retrieve. However, it does not explicitly differentiate itself from other memory-related tools beyond the verb itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for saving experiences, with phrases like 'attention-gated' suggesting a condition for storing. It doesn't provide explicit when-to-use or when-not-to-use guidance, nor name alternative tools, but the context is reasonably clear from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the meaning of velocity and noveltySpike and notes that an RPE sample can be optionally injected, which implies a side effect. However, it does not clarify the full effects of injection, whether reading is side-effect-free, or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, two sentences, with no filler. It packs state interpretation and optional action into a tight structure, front-loading the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does not explicitly state the return format or structure, though it hints at velocity and noveltySpike fields. It also doesn't elaborate on the consequences of injecting an RPE sample. For a somewhat complex state tool, this is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'rpe' parameter with a clear description. The tool description adds the word 'inject' and reinforces the sample semantics, but does not add significant new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exposes meta-learning state, specifically learning velocity from RPE-variance dynamics, with interpretation for velocity and noveltySpike. It also mentions optional injection of an RPE sample. This goes beyond a tautology and gives a specific resource and action, though it doesn't explicitly name a verb like 'get' or 'read', it's clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful interpretation cues ('velocity>0 ⇒ converging; noveltySpike ⇒ novel/confusing regime') that implicitly tell when this state is relevant, but there is no explicit guidance on when to use this tool vs. siblings like tcai_convergence or tcai_curiosity, and no mention of exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists the affected components but does not disclose that a reset is likely destructive, irreversible, or has side effects. Since no annotations are provided, the description carries the full burden and this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It avoids redundancy and is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic function and scope, it lacks details about the consequences of a reset, such as whether it clears all data, requires confirmation, or affects other systems. For a mutation tool with no annotations, this leaves the agent without a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add param-wise. The baseline for 0 params is 4, and the description does not omit any necessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Reset' and the resource 'TCAI consciousness system', listing the specific components (workspace, memory, emotion, metrics). This distinguishes it from sibling tools like tcai_cycle or tcai_workspace_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, or exclusions. It only states what the tool does, not when it should be called.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It does reveal that the mass-displacement scale is exposed as a free parameter and that a sensitivity sweep is performed, which is helpful. However, it does not mention whether the tool is read-only, any side effects, or the return format (no output schema exists), leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the formula, the free parameter, and the sweep behavior without any filler. Every phrase contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a specialized scientific computation with three parameters and no output schema, the description provides the core formula and main behavior, but it does not specify the output structure, error conditions, or how the sweep results are presented. Given the complexity and lack of output schema, a bit more detail would make it more self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with descriptions, but the description adds meaningful context by naming the mass-displacement scale (separationM) as the free parameter and indicating the tool sweeps across orders of magnitude. This supplements the schema by clarifying the intended use of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as computing Penrose's objective-reduction criterion τ = ℏ/E_G, with the mass-displacement scale exposed as a free parameter and a sensitivity sweep. It uses a formula rather than an explicit verb, which is slightly less direct, but the scope is well-defined and distinguishes it from related sibling tools like orch_decoherence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for sensitivity analysis via the sweep across four orders of magnitude, but it does not explicitly state when to prefer this over sibling tools or exclude alternatives. No direct comparison to orch_decoherence or other tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the mechanism (epoch-quantised, stochastic tie-break) and an important limitation (surrogate only, not real Orch OR). However, it does not mention side effects, persistence of configuration, or interaction with other system components.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence front-loads the tool's action and subject, while the second adds a key caveat. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters and no output schema, the description covers the core purpose and a key limitation but lacks information on configuration effects, validation, or return values. It is adequate for a simple config tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only indirectly hints at parameter roles (e.g., epochMs for 'epoch-quantised', tieBandFraction for 'stochastic tie-break'). It does not explicitly explain each parameter's meaning, default, or behavior, leaving significant ambiguity for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Enable or configure') and resource ('classical surrogate gate'), and adds technical specificity ('epoch-quantised ignition with stochastic tie-break'). The caveat about not instantiating objective reduction distinguishes it from related Orch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: this is the tool for enabling/configuring the surrogate gate. The statement that it does not instantiate objective reduction gives an exclusion, but no explicit alternatives are named among the many sibling tools (e.g., actual reduction tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It lists the report's contents, which helps set expectations for the output, but does not explicitly state whether the tool is read-only, triggers any computation, or has side effects. For a status report, this is a moderate gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key concept 'Consolidated Orch OR status' and then efficiently lists four specific report components in a structured, comma-separated manner. It avoids unnecessary verbosity, though it is slightly dense with jargon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter report tool with no output schema, the description provides a fairly complete indication of what the report contains: epistemic standing, Penrose criterion, decoherence budget, and verdicts for three substrates. It is sufficient for an agent to know what to expect, though terms like 'theory epistemic standing' could be clearer to a new agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, as shown by the empty properties in the input schema, so the description does not need to explain parameter behavior. The baseline for a zero-parameter tool is 4, and the description adds no parameter-related information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates this is a consolidated status report for Orch OR, enumerating specific contents: theory epistemic standing, Penrose criterion, decoherence budget, and ASTRA substrate verdicts. It distinguishes from sibling tools like orch_criterion or orch_decoherence by covering multiple aspects in one report, though it lacks an explicit action verb like 'retrieves' or 'generates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Consolidated' implies this is the summary/overview tool, suggesting use when a high-level status is needed rather than detailed per-substrate data. However, there is no explicit guidance on when to prefer this over siblings or any exclusions, so usage context is implied but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output dimensions (stage, stability, meta-representation score) and the behavioral trait of 'second-order self-monitoring over time.' It does not explicitly state whether the operation is read-only or whether it modifies any state, but 'tracking' implies a non-mutating observation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, consisting of two sentences. It front-loads the core purpose and then lists specific outputs. The parenthetical 'DevelopmentTracker port' adds context but is slightly unnecessary; overall, the description is efficient and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the essential aspects: what it does, what it produces, and its temporal nature. It does not specify return formats or units, but the low complexity makes this acceptable. The lack of sibling differentiation is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter information. The description adds context about the data source ('running composite-proxy level') and outputs, which adequately compensates for the lack of parameters. The baseline of 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: longitudinal developmental tracking with specific stage progression (nascent→reactive→integrative→reflective) and derived scores. It distinguishes itself from sibling tools by emphasizing temporal tracking and second-order self-monitoring, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through 'longitudinal' and 'over time', suggesting it is for tracking development rather than one-off queries. However, there is no explicit guidance on when to use this tool versus alternatives like tcai_second_order or tcai_meta_learning, and no exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full transparency burden. It mentions the caveat but does not disclose whether the tool is read-only, has side effects, requires authorization, or what output format to expect. This is a significant gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that efficiently introduces the substrates, the comparison axes, and the caveat. Every clause adds value with no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core concept of comparing three substrates and the caveat, which is substantial for a 0-parameter tool. However, it does not specify what the tool actually returns (e.g., a report, a boolean, a rating), and without an output schema, that gap matters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter-specific explanation is unnecessary. The description adds conceptual context about the comparison axes and caveat, but since there are no parameters, the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'side-by-side comparison' of three named substrates (silicon SNN, organoid MEA, human wearable) feeding a PAD pipeline. It specifies the comparison axes and the caveat, distinguishing it from generic status or read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use the tool—when a comparison of substrate constraints is needed—but there is no explicit 'use instead of' or exclusions. Sibling tools like orch_substrate or ovo_read could conceptually overlap, but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosures. It reveals important consequences (arming places a human in the control loop) and a refusal condition. However, it does not describe disarming effects, success/failure outcomes, or any safety or side-effect details beyond the refusal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the core action front-loaded and the important consequence/precondition following. No word is wasted; it is compact and structured effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one boolean parameter), but the description lacks several contextual details: what constitutes a 'protocol reference', how it is provided (not in the schema), what happens after successful arming/disarming, and what the return/response is. This could leave an agent uncertain about prerequisites and outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the schema only specifies a boolean named 'arm'. The description adds meaning by mapping the boolean to 'arm or disarm', which clarifies true/false semantics. It does not explicitly map boolean values to arm/disarm, but the phrase 'Arm or disarm' strongly implies it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action as 'Arm or disarm closed-loop affective actuation,' using a specific verb and resource. It distinguishes itself from siblings like ovo_set_policy or ovo_cycle by focusing on the arming state, and adds context about placing a human in the loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (toggling the armed state) and mentions a precondition ('refused without a protocol reference'), but it does not explicitly compare to alternatives or state when-not-to-use. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains the conceptual meaning of the telemetry values and their principled nature, but it does not explicitly state whether the operation is read-only, if it has side effects, or if it requires specific system state. The term 'telemetry' implies a read, but operational details beyond output semantics are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the main point front-loaded ('Active-inference core telemetry') followed by a precise, colon-separated list of contents. The second sentence adds essential context (halting criterion, principled vs. heuristic) without waste. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides rich conceptual context by naming and explaining each telemetry field (F, G(π), task quality, entropy, action) and its role in halting. It stops short of specifying the exact return format, units, or data types, which would make it fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4 per the rubric. The description adds no parameter info because none exist, but it enriches the understanding of what the returned data means, which is useful for interpreting the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Active-inference core telemetry' and lists specific quantities (F, G, task quality, entropy, action), making the resource and scope clear. It distinguishes itself from heuristic correlates by stating it is the 'principled quantity' for halting, but lacks an explicit verb like 'get' or 'return', which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states this telemetry is what the halting criterion thresholds on, providing a clear when-to-use scenario. It also says 'not a heuristic correlate', implying it should be preferred over heuristic metrics, though it does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the internal processing pipeline and the early-halting condition, which adds useful behavioral context. However, it does not explicitly state whether the cycle mutates external state (e.g., writes emotional memory or updates the self-model) or what side effects the agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, then provides the pipeline flow and the key stopping parameter. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 17 parameters and no output schema, and the description gives a good high-level explanation but does not mention what the tool returns (e.g., metrics, satisfaction state, or status). Given the schema's strong parameter coverage, the description is minimally viable but leaves output behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 82%, so the baseline is 3. The description adds meaningful semantics for stopWhenSatisfied, explaining that it halts early on a sustained satisfactory regime. This goes beyond the schema's basic property description, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Run') and resource ('ACM cycles') and clearly differentiates the tool by listing the full pipeline stages (SNN signals, AKOrN binding, GNW ignition, etc.), which distinguishes it from sibling tools like tcai_second_order or orch_cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for the operation and explains when to set stopWhenSatisfied, but it does not explicitly state when to prefer this tool over alternatives such as tcai_second_order or orch_cycle. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself carries the transparency burden. It discloses that the result is a proxy rather than a measurement and lists the component dimensions, which adds meaningful behavioral context. It does not mention output format or side effects, but the zero-parameter nature strongly suggests a read-only computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool's identity and immediately provides the key caveat ('proxy, not measurement'). Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the core purpose and a critical interpretive caveat. However, it lacks return scale/format details and explicit guidance on when to use this tool versus sibling meta-cognitive evaluators, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so no parameter explanation is needed. The description adds value by explaining what the composite score is based on, exceeding the empty schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a weighted score over confidence calibration, learning awareness, self-continuity, and error monitoring. The 'PROXY of meta-representation capacity, not a measurement' framing distinguishes it as an evaluator rather than a direct measurement, separating it from sibling meta-cognitive tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'not a measurement' caveat implies the tool should be used as an approximate proxy, but there is no explicit when-to-use guidance or comparison with sibling tools like tcai_second_order or tcai_meta_learning. The intended context is only weakly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It explains the internal model (action→expected-valence map) and the two query modes, implying a read-only operation, but it does not explicitly state side-effect freeness, output format, or error behavior. For a simple query tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the core capability and uses no filler. Every phrase contributes meaning, from the parenthetical port reference to the two-mode usage explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers the two main use cases and the underlying semantics. It is sufficiently complete for an agent to invoke it correctly, though it does not spell out the exact return structure or edge-case handling. Given the tool's simplicity, this is a good level of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the sole 'action' parameter, but the description adds key semantic value by clarifying that omitting the action lists the entire capability table. This goes beyond the schema's description of 'Action label to query expected valence for' by explaining the optionality and fallback behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Query') and resource ('expected outcome of an action' or 'learned capability table'), and it is distinguishable from siblings like tcai_memory_retrieve or tcai_self_model by referencing the action→expected-valence map (EMA). The mention of 'DirectExperienceLearner port' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines two distinct usage modes: querying a specific action's expected valence, or listing the full capability table when no action is provided. This provides clear context for when to use the tool, though it does not explicitly name alternatives or exclusions. It is not misleading, just lacks a formal 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the main behavior: running warm-up cycles, recording |ΔF|, computing the median, and setting epsFreeEnergy. It also states the return values. It does not mention side effects beyond setting the threshold, but this is the core effect and is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying meaningful information: purpose, mechanism, and rationale. It is front-loaded and avoids redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calibration tool with no output schema, the description provides the algorithm, the formula, the return values, and the reason for existence. It is sufficiently complete for an agent to know what will happen and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description uses the parameter names in context (e.g., 'runs cycles warm-up cycles', 'factor× their median') but does not add new semantic information beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Calibrate the halting threshold on the measured ΔF scale instead of a guessed constant.' This clearly states what the tool does and distinguishes it from sibling tools, which are not about threshold calibration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'instead of a guessed constant' and the reference to the 'v2.9 critique' indicate when to use this tool: when a data-driven threshold is preferred over a fixed default. It does not explicitly name alternative tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of transparency. It discloses the dual get/set behavior, the exact multi-criteria halting condition (free energy, task quality, epistemic value, patience), and explicitly notes that stationarity alone is insufficient. This is rich behavioral context, though it omits details about persistence or effects of updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with 'Inspect or configure', immediately stating purpose. Every clause contributes meaningful information: modes, halting condition, and a qualifying note about stationarity. No wasted words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description covers the query mode (returns state and thresholds) and the full halting logic, which is the tool's core complexity. It does not describe the exact return format, but that is a minor gap for a configuration tool with well-schemaed parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and defaults, so the baseline is 3. The description adds value by showing how the parameters interrelate in the halting condition (e.g., all conditions must be sustained over patience cycles), which goes beyond the individual parameter descriptions and clarifies their combined semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Inspect or configure' with a clear resource 'recursive double-loop halting criterion (v2.9)', immediately distinguishing it from sibling tools like tcai_metrics or tcai_memory_retrieve. It also clearly defines two modes of operation (no args = query, with args = update), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains exactly when to call it: with no arguments to retrieve the current satisfaction state and thresholds, and with arguments to update them. It also states the full halting condition, giving context for when this tool would be relevant. However, it does not explicitly name alternative tools or provide exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

ASTRA-Unified-ResearchLab-MCP-v3.0.1 MCP server

Copy to your README.md:

[![ASTRA-Unified-ResearchLab-MCP-v3.0.1 MCP server](https://glama.ai/mcp/servers/christophejlegros-lgtm/ASTRA-Unified-ResearchLab-MCP-v3.0.1/badges/card.svg)](https://glama.ai/mcp/servers/christophejlegros-lgtm/ASTRA-Unified-ResearchLab-MCP-v3.0.1)

Score Badge

Copy to your README.md:

[![ASTRA-Unified-ResearchLab-MCP-v3.0.1 MCP server](https://glama.ai/mcp/servers/christophejlegros-lgtm/ASTRA-Unified-ResearchLab-MCP-v3.0.1/badges/score.svg)](https://glama.ai/mcp/servers/christophejlegros-lgtm/ASTRA-Unified-ResearchLab-MCP-v3.0.1)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/christophejlegros-lgtm/ASTRA-Unified-ResearchLab-MCP-v3.0.1'

If you have feedback or need assistance with the MCP directory API, please join our Discord server