Governed external-environment scanning: signal harvest, Field Intel Reports, per-signal lineage.
Scored across 6 tools
The six tools mostly target distinct operations: run, list, retrieve, report generation, signal querying, and Veil state inspection. The only mild overlap is between vara_query_signals and vara_get_veil_state, since both can involve the current Veil hold, though their descriptions distinguish querying signals from inspecting hold state.
All tool names follow a consistent vara_ + verb_noun snake_case pattern: vara_run_scan, vara_list_scans, vara_get_scan, vara_generate_fir, vara_query_signals, vara_get_veil_state. The convention is predictable and easy to scan.
Six tools is well-scoped for a scan-focused server: execute, list, retrieve, generate report, query signals, and inspect Veil state. Each tool appears to earn its place without excessive surface area.
The surface covers the main scan lifecycle: running scans, listing history, retrieving reports, generating FIR output, querying signals, and inspecting Veil state. Minor gaps may exist around scan cancellation, deletion, or Veil hold lifecycle management, but core workflows are covered.
Generate an Operator-Tier or lightweight Field Intel Report from a scan_id.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | operator_tier | |
| series | No | ||
| scan_id | Yes | ||
| baseline | No | ||
| next_cycle_hint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden, yet it discloses nothing about whether the report is persisted, whether the scan must already exist, whether generation is expensive/slow, or if it writes anything. For a report-generation tool with zero annotation coverage this is a real gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the verb and resource front-loaded and no filler. It is arguably too terse rather than bloated, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the one-line description is not enough. An agent cannot tell what the optional parameters do or what the return looks like, so it is under-specified for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains scan_id and implicitly maps operator_tier/lightweight to the format enum, but series, baseline, and next_cycle_hint (3 of 5 params) are completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Generate) and resource (Field Intel Report) and names the two report variants, which an agent can distinguish from siblings like vara_get_scan or vara_list_scans. It stops short of explaining what an FIR actually contains, but the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to call this versus vara_get_scan/vara_query_signals, and no guidance on choosing operator_tier over lightweight beyond naming them. The agent is left to infer the selection criteria entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a complete historical VaraScanReport by scan_id or short prefix.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | ||
| include_signals | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full behavioral burden. 'Complete historical' usefully signals this returns a persisted report rather than a live state (contrast vara_get_veil_state), but nothing is said about unknown/prefixed-ambiguous scan_id behavior, auth requirements, or what include_signals does to the payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler; the retrieval verb and lookup mechanism lead. Brevity here edges toward under-specification rather than padding, so it does not reach a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% schema description coverage, the description should do more. It omits the include_signals flag entirely and gives no failure-mode context for invalid or ambiguous prefixes, which matters for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it partially does: 'short prefix' documents that scan_id accepts a truncated identifier, which the bare 'Scan Id' schema entry does not convey. However, include_signals is never mentioned, leaving one of two parameters entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Retrieve), resource (VaraScanReport), and lookup key (scan_id or short prefix). It is distinguishable from vara_list_scans (enumeration) and vara_run_scan (execution), though it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no alternatives named. An agent must infer that this is the by-id fetch versus vara_list_scans or vara_query_signals 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.
Inspect current Veil hold entries and trajectories.
| Name | Required | Description | Default |
|---|---|---|---|
| plane | No | ||
| signal_id | No | ||
| include_trajectories | No |
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 implies a read-only inspection, but does not state whether the operation is side-effect free, whether authentication is required, how results are scoped, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. Its brevity is appropriate structurally, though it leaves substantive gaps that are penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional parameters with no schema descriptions, empty annotations, and no output schema, the description is too sparse. It does not explain the parameters, the return content, or how to interpret 'Veil hold entries' and 'trajectories,' leaving an agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all three parameters. The description mentions 'trajectories,' loosely corresponding to include_trajectories, but never explains what 'plane' or 'signal_id' mean or how any parameter affects the inspection. It adds minimal semantic value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Inspect') and resource ('current Veil hold entries and trajectories'), making the high-level purpose clear. However, it does not differentiate this tool from siblings such as vara_get_scan or vara_query_signals, and 'Veil' is left unexplained for non-domain users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus the sibling tools, nor does it state prerequisites or exclusions. It only implies that it is for inspecting current Veil state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List historical Vara scan metadata from the local archive.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| label_contains | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, yet it says nothing about read-only nature, ordering, pagination, default limits, or what 'local archive' means operationally. 'From the local archive' is the only real behavioral signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the core action and data source lead. It is efficient, though its brevity borders on under-specification for a 3-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three undocumented parameters, no annotations, and no output schema, the description omits everything an agent needs beyond the bare purpose. It would need at least parameter meaning and return/pagination behavior to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for limit, since, and label_contains, so the description must compensate and it does not mention any of them. An agent has no idea whether 'since' is a timestamp, whether 'limit' paginates, or what 'label_contains' matches against.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (Vara scan metadata) with a scope qualifier (historical, from the local archive), which is enough to separate it from vara_get_scan conceptually. It does not explicitly name or contrast with any sibling tool, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus vara_get_scan or vara_query_signals, nor any prerequisites. The word 'historical' hints at browsing past scans, but usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the committed Vault corpus and optionally the current Veil hold.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| plane | No | ||
| since | No | ||
| until | No | ||
| entity | No | ||
| origin | No | any | |
| min_novelty | No | ||
| canonized_only | No | ||
| include_veil_hold | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden and does not meet it. It never states that this is a read-only operation, how results are capped by the limit parameter, whether results are paginated, or what prerequisites (auth, existing scan) are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short and front-loads the verb, but its brevity comes from omission rather than discipline. For a 9-parameter tool, one sentence is under-specification, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A nine-parameter query tool with no annotations, no output schema, and 0% schema description coverage receives essentially no explanatory support from the description. Nothing an agent needs to invoke this correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 9 parameters, and the description explains none of them. Opaque fields such as plane, min_novelty, canonized_only, entity, and the origin enum (passed/veil_promoted/any) are left entirely undocumented, forcing the agent to guess semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ("Query") and resources ("committed Vault corpus", "current Veil hold"), which is more than a tautology. However, the domain terms are undefined and it offers no differentiation from siblings like vara_get_scan, vara_list_scans, or vara_get_veil_state, so an agent cannot tell which query tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus vara_get_scan, vara_list_scans, vara_run_scan, or vara_get_veil_state. The phrase "optionally the current Veil hold" hints at a scope choice but never states the condition that selects it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a full Real Vara scan using the operational dual-track, multi-timescale pipeline. This tool changes Vara runtime state.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | No | ||
| scan_label | No | ||
| generate_fir | No | ||
| active_planes | No | ||
| use_firecrawl | No | ||
| extra_rss_feeds | No | ||
| extra_substacks | No | ||
| target_entities | No | ||
| enable_dual_track | No | ||
| sweep_depth_hours | No | ||
| high_novelty_floor | No | ||
| weak_novelty_floor | No | ||
| enable_multi_timescale | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description must disclose behavior itself; it does creditably state 'This tool changes Vara runtime state', signaling mutation. However, it omits how long a scan runs, whether it is blocking or async, whether repeated calls conflict, and what state is altered – critical gaps for a heavy pipeline trigger.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the action stated first and the state-change warning immediately after. The brevity is efficient, though it edges toward under-specification rather than tightness for a 13-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, zero-required mutating pipeline tool with no annotations and no output schema, the description says nothing about parameter behavior, return values, runtime, or failure modes. An agent could not invoke this correctly without reading the schema blind.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 13 parameters at 0% schema description coverage, the description carries the full burden, yet it only loosely gestures at two of them ('dual-track', 'multi-timescale' corresponding to enable_dual_track/enable_multi_timescale). Keywords, active_planes, sweep_depth_hours, novelty floors, extra feeds, and generate_fir get no explanation of meaning or effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Execute' plus resource 'full Real Vara scan' clearly contrasts with siblings like vara_get_scan and vara_list_scans, which read existing scans rather than produce one. The phrase 'Real Vara scan' and 'dual-track, multi-timescale pipeline' remain unexplained jargon, so an agent can tell what kind of action it is but not what the scan actually produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never says when to run a scan versus calling vara_query_signals, vara_list_scans, or vara_generate_fir, nor does it describe prerequisites such as an existing scan configuration. Only the phrase 'changes Vara runtime state' hints that this is a mutating/kicking-off action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
vara_run_scan3 fields changedInput schema / properties / extra_rss_feedsAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Extra Rss Feeds"
+}Input schema / properties / extra_substacksAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Extra Substacks"
+}Input schema / properties / target_entitiesAdded value: +{
+ "anyOf": [
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Target Entities"
+}vara_generate_firvara_get_scanvara_get_veil_statevara_list_scansvara_query_signalsvara_run_scanSigB (Signal Bureau): maintained, source-traced record of entities and events in your named domain.
Search and monitor source-backed AI agent ecosystem signals, briefings, deltas, and source health.
From first signal to satellite evidence: live world-event intelligence and collection planning.
Intelligence subscription protocol for AI agents. Scored, filtered AI intelligence signals via MCP.
Add one secure layer between your agents and this server.
