Which integrations are available for this server?

Planned integration to fetch arXiv paper full text, chunk, embed, and enable semantic recall during the scientific loop. Allows referencing MLflow runs as external run stores for experiments. Allows viewing and navigating the experiment vault (markdown files) in Obsidian with graph view, backlinks, and tag panels. Allows referencing external W&B runs from experiments to avoid storing metric curves directly.

How do I use vibescience-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vibescience-mcp Recall prior experiments related to learning rate tuning" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

vibescience-mcp

by AntonIXO

Overview Schema Related Servers Score Discussions

Python

Local

vibescience-mcp

A scientific experiment log (MCP server) for an AI coding/research agent working on ML projects.

It is not a lab notebook and not Weights & Biases. It stores reasoning and causal claims, not training curves, and defines "confirmed" as agreement between a prediction committed before the test and the effect observed after, on a fixed diagnostic basis. That makes your log a queryable causal map ("which interventions move which diagnostics, in which direction, how often") plus a calibration signal on your own intuition.

Markdown files are the source of truth → open vault/ in Obsidian for graph view, backlinks and tag panels for free. The SQLite index is disposable and rebuilt from markdown at any time.

Why it's different

	lab notebook	W&B / MLflow	vibescience
stores	free-text notes	loss curves, metrics	predictions, verdicts, causal claims
"confirmed" means	you say so	—	predicted direction == observed direction (computed)
negative results	buried	buried	first-class, ranked to the top of recall
cross-experiment view	none	per-run dashboards	aggregated causal map + calibration

Related MCP server: repro-mcp

Install

cd vibescience-mcp
python -m venv .venv && . .venv/bin/activate
pip install -e .            # add ".[embeddings]" for optional semantic recall, ".[dev]" for tests

Configure in Claude Code / Cursor / Desktop

The server speaks stdio. Point your MCP client at it and set the vault path:

{
  "mcpServers": {
    "vibescience": {
      "command": "/root/vibescience-mcp/.venv/bin/python",
      "args": ["-m", "vibescience_mcp.server"],
      "env": {
        "VIBESCIENCE_VAULT": "/root/vibescience-vault",
        "VIBESCIENCE_EMBEDDINGS": "off"
      }
    }
  }
}

Or via the Claude Code CLI:

claude mcp add vibescience -e VIBESCIENCE_VAULT=/root/vibescience-vault \
  -- /root/vibescience-mcp/.venv/bin/python -m vibescience_mcp.server

The scientific loop (enforced by tool descriptions)

recall — always first (pre-mortem gate). Refuted/inconclusive matches rank to the top, each with a one-line failure reason and the diagnostic delta that killed it. Never re-walk a dead end.
create_problem — frame the open question / failure mode.
register_diagnostic / register_intervention — diagnostics are a fixed, comparable basis, not free text. Adding one is deliberate.
propose_hypothesis — requires ≥1 predicted_effect on a registered diagnostic before testing. The first is the primary prediction the verdict keys off. No prediction → rejected.
start_experiment — auto-captures branch@shortsha from git HEAD if you omit git_ref. References an external W&B/MLflow run; never stores curves.
record_diagnostics — before/after per diagnostic; deltas/directions derived.
close_experiment — computes observed_effects, prediction_match (per-diagnostic + overall) and the verdict, propagates status to the hypothesis, and suggests (never performs) a commit on a positive match. Record artifacts, headline numbers and dead ends in artifacts / key_numbers / do_not_retry rather than compressing them into notes.

Verdicts. supports · refutes · inconclusive · directional_only (direction matched but a preregistered blocking gate failed) · null · crashed.

null is a powered null: the direction nominally matched, a blocking gate carrying a preregistered mde failed, and |delta| came in under that MDE. It is treated as a refutation of the lever at the committed scale — not a near-miss — and ranks with refutes. Without it, a sign-only test reports delta=+0.0003 at permutation p=0.65 as "the direction matched" and ranks it above inconclusive, i.e. the strongest evidence against a lever outranks "we don't know". Set mde on a gate to get this; omit it and the old two-level behaviour is preserved exactly.

Housekeeping:

doctor — reports records whose status no longer matches reality: answered problems still open, hypotheses rotting in proposed/testing, experiments left open, near-duplicate experiments started minutes apart (the fingerprint of a double start_experiment), runbooks queued on resolved problems, orphan and probable-duplicate tags. Advisory only; every finding names the tool that fixes it.
merge_tags — fold a duplicate tag into its canonical form across the whole vault. The source survives as an alias, so historical spellings still resolve.
update_problem(add_update=...) / update_runbook(note=...) — dated log entries instead of banners glued onto a description.

Then query your own work:

causal_map(problem_id | tag) — aggregated intervention → Δdiagnostic subgraph. Optional Obsidian .canvas output.
calibration(diagnostic_id | tag | intervention_id) — fraction of predictions that matched observation. Where is your intuition wrong?
reindex() — rebuild the SQLite index from markdown (idempotent).

A vibescience://guide resource ships the same workflow to any agent.

Storage layout

vault/
  problems/        hypotheses/     experiments/
  diagnostics/     interventions/  papers/
  _canvas/         # generated Obsidian canvases
  .index.sqlite    # disposable — rebuilt from markdown by reindex()

Each entity is one markdown file: YAML frontmatter for structured fields, body for prose + [[wikilinks]]. Fully Obsidian-compatible.

Env vars

var	default	meaning
`VIBESCIENCE_VAULT`	`~/vibescience-vault`	vault path (source of truth)
`VIBESCIENCE_VAULT_STRICT`	unset	`1` → exit instead of auto-creating a missing vault (catches typo'd paths)
`VIBESCIENCE_EMBEDDINGS`	`off`	`on` enables local FastEmbed semantic recall (Phase 2 scaffold)

VAULT_DIR and VIBESCIENCE_VAULT_DIR are accepted as aliases (with a warning on stderr); --vault PATH overrides everything. If two of them disagree the server exits rather than guessing. The resolved vault path is printed to stderr at startup and embedded in the MCP instructions, so the agent can always see which vault it is writing to.

Running several vaults

One project per vault. Register one server entry per project:

"vibescience":          { "env": { "VIBESCIENCE_VAULT": "/root/vibescience-vault" } },
"vibescience-lightsem": { "env": { "VIBESCIENCE_VAULT": "/root/lightsem-vault"   } }

Verify isolation before trusting it — list_problems on each server must return different records. A silently shared vault interleaves records from unrelated projects, which corrupts the experiment log's role as the system of record.

Bundled workflow skill

skills/vibescience-mcp-workflow/SKILL.md ships the battle-tested procedure for running the full loop: pair deep research (perplexity_research) + the arxiv MCP with a real, verdict-computed experiment cycle, then dogfood it into the vault. It encodes the hard-won pitfalls (research timeouts, making an experiment able to refute, semi-synthetic precision protocols on unlabeled prod data, the opt-in-vs-blanket deployment guardrail). Load it into any Hermes/Claude session with skill_view(name='vibescience-mcp-workflow'), or read it directly — it is plain markdown.

Record IDs

IDs are read by humans — in ls, in [[wikilinks]], in error messages. Auto-generated ids are capped at 48 characters on a word boundary plus a short hash of the full text, so a shared prefix can never collide; experiments get exp-NNN-<stem>, which keeps ls experiments/ usable as an overview. start_experiment is idempotent within a 5-minute window: a retried call returns the existing open experiment instead of minting a second record.

Migrating an older vault

python migrate_ids.py <vault_path>            # dry run — shows the plan
python migrate_ids.py <vault_path> --apply    # back the vault up first

Renames every over-long id, rewrites all cross-references (problem_id, hypothesis_id, parent_experiment_id, supersedes, paper_refs) and every wikilink, records the old id in former_ids so external references stay traceable, and writes id_migration.json as the redirect map. Store.resolve_id still finds a record by its old name. Nothing is deleted and no prose is edited — only identifiers change.

Tests

./run_tests.sh -q  # 203 tests: verdict math (incl. powered nulls + weak_signal),
                   # prediction gate, full loop, negative-result ranking,
                   # causal_map, calibration, index rebuild, id scheme +
                   # idempotency, doctor, merge_tags, interpretation layer
                   # (lessons, stale negatives, plateau, portfolio,
                   # research_brief), markdown round-trip, MCP stdio smoke

The interpretation layer (2026-08)

Distilled from Prime Intellect's Measuring Autonomous AI Research (the gap between models is experiment hygiene under noise, not idea quality) plus an autopsy of a real vault: 61 experiments, 39 negative verdicts, zero recorded lessons, 16/17 problems eternally open, 30/30 papers never linked to a hypothesis. A log that records verdicts but never analysis is a junk pile.

interpret_experiment(id, lesson, failure_mode) — the act of analysis. Negative verdicts require a failure_mode (claim_false / mechanism_wrong / test_invalid / noise / execution_bug / recipe_conditional): a refute from a broken capture and a refute of the idea are different objects. recall surfaces the authored lesson instead of a machine string; doctor reports closed-but-uninterpreted runs as debt.
reopen_hypothesis(id, reason) — a negative result is a fact about (claim × recipe), not the claim. close_experiment snapshots a recipe_fingerprint (interventions + provenance hashes); when the recipe drifts, a refute flips to stale_negative — flagged re-testable, history untouched, the re-test still goes through supersedes + a fresh prediction.
progress(problem_id) + synthesize_problem — the compiled trajectory (primary-diagnostic movement, verdict counts, plateau, interpretation debt) and the authored current-state-of-knowledge that turns a chronology into a knowledge base.
Noise floors — register_diagnostic(..., noise_sigma, noise_source= 'measured') makes the verdict engine demote a directionally-correct delta inside k*sigma to weak_signal: a candidate to re-draw, neither a win to deploy nor a loss to discard. The top autonomous-research runs measured their own noise; the weak ones shipped draw luck.
Ambition economics — hypotheses declare ambition_class (tuning / mechanism / reframe) and gap_closure_estimate against the problem's declared target; experiments carry gpu_hours. portfolio() shows where the compute went per class, and a plateaued problem (last 5 closed runs, no supports) rejects further tuning without an override_reason — the crumb trap made expensive.
research_brief(problem_id) — compiles state + gap + dead ideas (with lessons) + rule-outs + the already-read paper exclusion list into a ready deep-research query, so every literature sweep is incremental by construction. The literature is the edge a sandboxed harness doesn't have.

Phasing

Phase 1 (this): schema + lifecycle + recall + causal_map + calibration over markdown, SQLite index, Obsidian compatibility.
Phase 2 (scaffolded, not built): hold papers in context — fetch arXiv full text, chunk, embed, and let recall pull relevant passages in. The Paper schema is ready.

Non-goals: custom graph visualization (Obsidian does it), web UI, autonomous experiment execution, raw metric-curve storage (reference W&B/MLflow), auto-committing to git.

License

MIT

Available Tools

17 tools

add_paperC

Add an external reference (metadata + key claims). Cite it from hypotheses to ground your rationale.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`title`	Yes
`key_claims`	No
`topic_tags`	No
`arxiv_id_or_url`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior3/5

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

The description adds context about citing from hypotheses, which is beyond annotations. However, it lacks details on idempotency, deduplication, or validation. Annotations already indicate non-destructive 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?

Two concise sentences with no fluff. Every word adds value.

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 5 parameters and no schema descriptions, the description is too minimal. It does not cover parameter details or provide sufficient context for correct usage.

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 any parameters or their constraints. It fails to compensate for the lack of schema 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 states the tool adds an external reference with metadata and key claims, and mentions citing from hypotheses. This provides a specific verb and resource, but does not explicitly differentiate from sibling tools like link_paper.

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 implies usage for adding references and citing them, but does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it.

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

calibrationA

Read-onlyIdempotent

Prediction-accuracy report: the fraction of experiments where predicted direction == observed direction. Answers 'where is my intuition miscalibrated?'. Scope by diagnostic, tag, or intervention.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No
`diagnostic_id`	No
`intervention_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already mark the tool as read-only and idempotent. The description adds context about the report's computation and interpretation, which goes beyond the annotations. No contradictions.

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 concise sentences, each with a clear function: definition, motivational question, scope instructions. No superfluous text.

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?

Given the optional parameters and presence of an output schema, the description fully explains what the tool does and how to filter. No missing information needed for correct invocation.

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?

With no schema description coverage (0%), the description compensates by naming the three scope parameters (diagnostic, tag, intervention) and explaining their role in filtering. Does not specify formats or constraints, but provides essential meaning.

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?

Clearly defines the tool as a prediction-accuracy report, specifying it computes the fraction of experiments where predicted direction equals observed direction. The description directly answers 'where is my intuition miscalibrated?', distinguishing it from sibling tools like 'recall' or 'list_interventions'.

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?

States the tool can be scoped by diagnostic, tag, or intervention, providing clear usage context. Does not explicitly mention when not to use or alternatives, but the purpose is sufficiently specific for an AI agent to infer appropriate usage.

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

causal_mapA

Read-onlyIdempotent

Aggregated intervention → Δdiagnostic subgraph across all experiments in scope: what has ever moved a diagnostic, in which direction, how often, by how much. A mini meta-analysis of your own runs. Scope by problem_id or tag.

ParametersJSON Schema

Name	Required	Description
`tag`	No
`problem_id`	No
`emit_canvas`	No	also write an Obsidian .canvas

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnly and idempotent behavior. The description adds context that it's an aggregated, non-destructive view, which is consistent. No contradictions.

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?

Two sentences: first defines the core function, second adds scoping. Front-loaded, no fluff. Highly efficient.

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?

Given the output schema exists, the description sufficiently covers what the tool does and when to use it. For a read-only data retrieval tool, it's complete.

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 only 33%, but the description explains the purpose of tag and problem_id for scoping, adding value beyond the schema. emit_canvas is described in the schema. This compensates for the low coverage.

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 that the tool provides an aggregated view of intervention effects on diagnostic subgraphs across experiments, acting as a meta-analysis. It uses specific terms like 'Δdiagnostic subgraph' and 'mini meta-analysis', distinguishing it from sibling tools like register_diagnostic or list_interventions.

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 implies usage for meta-analysis of intervention effects and explicitly mentions scoping by problem_id or tag. It lacks explicit when-not-to-use or alternative tools, but the purpose is clear enough for a knowledgeable agent.

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

close_experimentA

Idempotent

Finalize: compute observed_effects, prediction_match (per-diagnostic + overall) and the verdict (supports/refutes/inconclusive), then propagate the status to the hypothesis. The verdict is COMPUTED from the primary prediction vs the observation — you cannot assert 'confirmed'. On a positive match it RETURNS a suggestion to commit your git_ref; it never commits for you.

ParametersJSON Schema

Name	Required	Description	Default
`notes`	No
`experiment_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

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

Annotations declare idempotentHint=true and destructiveHint=false. The description adds behavioral detail: never commits for you, returns a suggestion, and that verdict is computed. This goes beyond annotations without contradiction.

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, front-loaded with the key verb 'Finalize', and every sentence adds distinct information. No wasted 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?

Given complexity (computation, propagation, verdict) and presence of output schema, the description covers core logic. However, it does not explain verdict conditions or output format details, leaving some 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?

With 0% schema description coverage, the description should explain parameters, but it only indirectly refers to experiment_id (via context) and ignores the 'notes' parameter. No parameter-level detail is provided.

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 specifies the action ('Finalize'), the computed outputs (observed_effects, prediction_match, verdict), and the propagation to hypothesis. It distinguishes from sibling tools like start_experiment and propose_hypothesis by detailing unique behavior.

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 usage context (e.g., 'you cannot assert confirmed', verdict is computed) and hints at workflow (e.g., returns commit suggestion). However, it lacks explicit when-not-to-use instructions or direct alternatives from the sibling list.

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

create_problemA

Register an open research question / failure mode. Do this once per distinct problem. Use recall first to check it isn't already logged.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`title`	Yes
`paper_refs`	No
`topic_tags`	No
`description`	No
`problem_tags`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

Annotations already indicate non-idempotent and non-destructive behavior. The description adds that it 'registers' a problem (implying creation), but no further behavioral details (e.g., effect on existing data, permissions). Minimal added value beyond annotations.

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?

Two sentences, front-loaded with the core purpose, and no superfluous words. Every sentence serves a clear function.

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?

Provides essential usage guidance but lacks details on parameter semantics, return values (despite output schema exists), and what 'register' entails. For a creation tool with six parameters, more context (e.g., uniqueness constraints, effect on related data) would be beneficial.

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%, and the description provides no explanation of the six parameters (e.g., 'title', 'paper_refs', 'topic_tags'). Only the required 'title' is implied by context. The description fails to compensate for the lack of schema documentation.

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 registers an 'open research question / failure mode' and distinguishes it from sibling tools like 'recall' and 'list_problems'. The verb 'register' combined with the resource 'problem' is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises 'Do this once per distinct problem' and instructs to 'Use `recall` first to check it isn't already logged', providing clear when-to-use and when-not-to-use guidance with a named alternative tool.

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

get_problemA

Read-onlyIdempotent

Fetch a single problem by id.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already provide readOnlyHint and idempotentHint. The description adds no additional behavioral traits beyond 'Fetch', such as error handling or rate limits. It neither contradicts nor significantly supplements the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

A single sentence with no redundant words. Information is front-loaded and efficient.

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?

The tool is simple (one required param, no nested objects) and has an output schema. The description covers the essential purpose and input, making it complete for an AI 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?

With 0% schema description coverage, the description only says 'by id', which adds minimal meaning beyond the schema's parameter name. However, the single parameter is self-explanatory, so a baseline of 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 clearly states the action ('Fetch a single problem') and the resource ('by id'). It effectively distinguishes from sibling tools like list_problems (multiple) and create_problem (creation).

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 when to use (when you have a specific id), but offers no explicit guidance on when not to use or alternatives. No exclusions or context for decision-making.

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

link_paperB

Idempotent

Link a paper to a problem or hypothesis (adds a cites edge).

ParametersJSON Schema

Name	Required	Description	Default
`paper_id`	Yes
`entity_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the description adds minimal behavioral context beyond mentioning it adds a 'cites edge'. This is consistent but not enriched.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, efficient sentence that conveys the entire purpose without unnecessary 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 is simple with two parameters and an output schema, but the description does not clarify what 'entity_id' refers to (problem or hypothesis). It is adequate but could be slightly more explicit.

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 coverage is 0%, and the description does not explain the parameters. 'paper_id' and 'entity_id' are self-explanatory from names, but the description adds no further semantic value or constraints.

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 verb 'link' and the objects 'paper to a problem or hypothesis', with the specific action 'adds a cites edge'. This uniquely identifies the tool's purpose and distinguishes it from sibling tools like add_paper or create_problem.

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, context, or when not to use it, leaving the agent without clear decision criteria.

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

list_diagnosticsB

Read-onlyIdempotent

List the registered diagnostic basis.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

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

The annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it is a safe, read-only operation. The description adds no additional behavioral context (e.g., response format, scope of 'basis', or any side effects), thus providing no value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, efficient sentence with no extraneous words. It front-loades the verb and resource, making it immediately actionable. Every word 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 the tool has no parameters, has an output schema to describe return values, and is simple, the description is mostly adequate. However, it could briefly clarify what 'diagnostic basis' means to avoid ambiguity, but the presence of the output schema compensates.

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?

With zero parameters and 100% schema coverage, the input schema is already fully defined. The description does not need to explain parameters. Following guidelines, a baseline of 4 is appropriate for parameterless tools.

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 verb 'list' and the resource 'diagnostic basis', indicating a retrieval operation. It is distinguishable from siblings like 'register_diagnostic' (creation) and 'list_interventions' (different resource). However, the term 'diagnostic basis' is somewhat vague and could be more precise.

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 'list_interventions' or 'list_problems'. It lacks any mention of prerequisites, context, or when not to use it, leaving the agent without decision support.

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

list_interventionsA

Read-onlyIdempotent

List registered interventions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint; description adds no extra behavioral traits beyond confirming it is a list operation.

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?

Single, efficient sentence with no wasted words.

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?

With no parameters and an output schema available, the description adequately covers the tool's purpose, though it could optionally define 'interventions'.

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?

No parameters exist; description adds no information beyond schema, which is empty, but baseline for 0 params is 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 clearly states verb 'list' and resource 'registered interventions', distinguishing from sibling such as 'register_intervention'.

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 purpose is clear and implies usage context, but no explicit when-not or alternatives are provided.

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

list_problemsA

Read-onlyIdempotent

List problems, optionally filtered by status {open|resolved|parked} or tags.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`status`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare readOnlyHint and idempotentHint true, so agent knows it's safe. Description adds filter value ranges (status enum) which goes beyond annotations.

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?

Single sentence, front-loaded with action and resource, no extraneous words.

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?

With annotations and output schema present, description covers key aspects. Could add more on result ordering or pagination but adequate for a simple list 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 has 0% description coverage. Description provides meaning for status (enum values) and tags but lacks format or examples. For two parameters, this is minimal compensation.

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 clearly states the tool lists problems and mentions optional filters by status and tags. It distinguishes from siblings like get_problem (single) and create_problem.

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 vs alternatives (e.g., get_problem for single problem, list_interventions for interventions). Context is implied by the tool name and sibling list.

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

propose_hypothesisA

Propose an explanation/intervention for a problem. You MUST commit ≥1 predicted_effect on a REGISTERED diagnostic BEFORE testing — this is rejected otherwise. Committing the prediction up front is what turns this log into a calibration signal. Call recall first. To revise a dead end, pass supersedes rather than deleting it.

ParametersJSON Schema

Name	Required	Description
`id`	No
`plan`	No
`papers`	No
`rationale`	No
`statement`	Yes
`problem_id`	Yes
`supersedes`	No	id of a prior hypothesis this one revises
`topic_tags`	No
`problem_tags`	No
`interventions`	No
`predicted_effects`	Yes	REQUIRED ≥1: [{diagnostic_id, direction: up\|down\|none, magnitude_note}]. The FIRST is the primary prediction the verdict keys off.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only provide destructive=false and idempotent=false. Description adds crucial behavioral details: requires committed predicted_effects on registered diagnostic, explains why (calibration signal), and how to revise (supersedes). No contradictions.

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 sentences with front-loaded purpose. Every sentence provides essential guidance without redundancy. No wasted words.

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 11 parameters, 3 required, with output schema, the description covers the core workflow well. However, many optional parameters are not described, and the low schema coverage means some details are missing. Still comprehensive for the main task.

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 very low (18%). The description adds meaning for 'predicted_effects' (required array with structure) and 'supersedes', but many parameters (id, plan, papers, etc.) remain unexplained. Partially compensates for low schema coverage.

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 'Propose an explanation/intervention for a problem' with a specific verb+resource. It distinguishes from sibling tools like register_diagnostic and register_intervention by emphasizing predicted_effects commitment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides when to use (propose hypothesis for a problem), prerequisite (registered diagnostic), and alternatives ('Call `recall` first', 'pass `supersedes`'). Also states consequences if not followed ('rejected otherwise').

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

recallA

Read-onlyIdempotent

CALL THIS FIRST, before proposing any hypothesis (pre-mortem gate).

Returns ranked past hypotheses/experiments. Refuted and inconclusive matches are ranked to the TOP with a one-line reason they failed and the diagnostic delta that killed them — so you never silently re-walk a dead end. Also returns a calibration note if the query touches a diagnostic with a track record. After reading this, propose a NEW hypothesis (or supersede a prior one) with a committed prediction.

ParametersJSON Schema

Name	Required	Description
`query`	No	Free-text about the idea you're about to try
`problem_id`	No
`topic_tags`	No	e.g. [jepa, contrastive]
`problem_tags`	No	e.g. [attention-collapse]

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

Annotations indicate read-only and idempotent. Description adds: returns ranked results with fail reason, diagnostic delta, and calibration notes. Adds value beyond annotations without contradiction.

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?

Description is front-loaded with imperative, then explains output. It is detailed but not overly verbose. Slightly long but each sentence adds value.

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?

Given the presence of an output schema and high schema coverage, the description provides sufficient context on when, why, and what to expect. Complete for the tool's complexity.

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 75% (3 of 4 params have descriptions). The description does not add parameter-specific 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns ranked past hypotheses/experiments, with refuted ones ranked top and reasons. The imperative 'CALL THIS FIRST' distinguishes it from siblings like propose_hypothesis and start_experiment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'CALL THIS FIRST, before proposing any hypothesis' and specifies the post-use action: propose a new hypothesis. Provides clear when and how to use, preventing re-walking dead ends.

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

record_diagnosticsA

Idempotent

Record before/after values for measured diagnostics. Re-recording the same diagnostic overwrites it (idempotent). Observed deltas/directions are derived.

ParametersJSON Schema

Name	Required	Description	Default
`measurements`	Yes	[{diagnostic_id, before, after}]
`experiment_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds that re-recording overwrites (consistent with idempotency) and that 'Observed deltas/directions are derived', providing behavioral context beyond annotations.

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 extremely concise with two sentences, no redundancy. Every word adds value.

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?

Has output schema (so return values need not be explained). The description covers key behaviors: recording, idempotency, derivation. For a simple recording tool with 2 params, this is sufficiently complete.

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 50% (experiment_id lacks description). The description does not add parameter-level details; it only states the general purpose. Measurements param has schema description but no additional context from description. Given partial coverage, the description provides minimal added 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 verb 'Record' and resource 'diagnostics', specifying 'before/after values'. This distinguishes it from sibling tools like register_diagnostic (which registers new diagnostics) and list_diagnostics.

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 mentions idempotency (overwriting on re-record) but does not provide explicit guidance on when to use this tool versus alternatives, nor when not to use it. The context is implied but incomplete.

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

register_diagnosticA

Register a named, fixed, measurable metric. Diagnostics are a DELIBERATE fixed basis — comparability across experiments is what makes the causal map possible. Do this before predicting on a metric.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`name`	Yes
`unit`	No
`direction`	No	higher_better \| lower_better \| neutral	neutral
`description`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

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

Annotations are minimal (idempotentHint: false, destructiveHint: false). The description adds that diagnostics are 'fixed' and 'deliberate', implying immutability, but does not disclose side effects, uniqueness constraints, or 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?

Three concise sentences with no fluff. Front-loaded with the primary action and context, each sentence 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?

Provides key context for a registration tool (when to use, purpose) but missing details about uniqueness, return value (output schema exists but undocumented), and error handling.

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 low (20%). The description does not explain individual parameters like 'unit', 'direction', or 'id', relying on schema defaults without adding meaningful context.

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 ('Register a named, fixed, measurable metric') and its purpose ('comparability across experiments'), setting it apart from siblings like list_diagnostics and record_diagnostics.

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?

Explicitly says 'Do this before predicting on a metric', providing clear temporal usage context. No explicit exclusions or alternatives, but the description implies when it is appropriate.

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

register_interventionC

Register a named, reusable change (e.g. unfreeze-projector). Reused across hypotheses so the causal map can attribute deltas to it.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`name`	Yes
`topic_tags`	No
`description`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/5.0

Behavior2/5

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

Annotations are minimal (idempotentHint=false, destructiveHint=false). The description adds that the intervention is 'reusable' and contributes to causal map deltas, but it does not clarify idempotency behavior, what happens on duplicate names, or side effects beyond 'register'. This leaves ambiguity about mutability and duplicates.

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?

Description is two sentences, front-loads the action, and adds a second sentence of context. No wasted words. However, it could be improved by including parameter hints without increasing length significantly.

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 4 parameters, 0% schema coverage, and an output schema (not shown), the description is too sparse. It does not explain the purpose of each parameter, expected inputs, or the output format, leaving significant gaps for proper invocation.

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 coverage is 0%: no parameter descriptions in the schema. The description mentions only 'name' implicitly via example but provides no information about the other three parameters (id, topic_tags, description) or their roles, defaults, or constraints. This forces the agent to guess parameter semantics.

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 clearly states the tool registers a named, reusable change with an example ('unfreeze-projector'). The verb 'register' distinguishes it from sibling tools like 'list_interventions' (listing) and 'register_diagnostic' (different resource). However, it does not explicitly differentiate from all siblings, missing a chance for absolute 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?

Description implies the tool is used to create interventions that are reused across hypotheses for causal map attributions. It does not provide explicit guidance on when to use versus alternatives, nor does it mention prerequisites or when not to use it.

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

reindexA

Idempotent

Rebuild the disposable SQLite index from the markdown vault (files are truth). Safe to call anytime; produces identical query results.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Description adds 'files are truth' context beyond annotations (idempotentHint, destructiveHint). Confirms safe to call and produces identical results.

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?

Single sentence, front-loaded with action, no wasted words. Highly concise and clear.

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 no-parameter, idempotent tool with an output schema, the description fully explains purpose, safety, and behavior. No missing details.

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?

No parameters, baseline 4. Description does not need to add parameter info as schema is empty and coverage is 100%.

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?

Clearly states 'Rebuild the disposable SQLite index from the markdown vault' which is a specific verb and resource. Distinguishes from sibling tools focused on diagnostics, interventions, problems, etc.

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?

Explicitly says 'Safe to call anytime', providing clear guidance on when to use. No need for when-not as no side effects. No alternatives mentioned, but siblings are unrelated.

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

start_experimentA

Begin testing a hypothesis. If git_ref is omitted the server reads the current branch@commit from git HEAD. Reference the external W&B/MLflow run — this server stores verdicts, not loss curves.

ParametersJSON Schema

Name	Required	Description
`id`	No
`git_ref`	No	branch@shortsha; auto-read from HEAD if omitted
`config_note`	No
`external_run`	No	W&B/MLflow run id or url
`hypothesis_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

Behavioral traits are disclosed beyond the minimal annotations: it explains the auto-read of git HEAD if git_ref is omitted, and clarifies that the server stores verdicts not loss curves. This adds valuable context that annotations (idempotentHint=false, destructiveHint=false) do not provide. No contradiction with annotations.

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 with no wasted words. The first sentence states the purpose efficiently, and the second adds two key behavioral details. It is front-loaded and every sentence 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 the tool has 5 parameters (1 required), minimal annotations, and an output schema, the description covers the key aspects: purpose, git_ref behavior, and external run relationship. It does not explain the output format, but since an output schema exists, that is acceptable. It is complete enough for an agent to use the tool correctly, though it could mention that it creates a new experiment record.

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 40% (2 of 5 parameters have descriptions in schema). The description adds meaning for git_ref (auto-read from HEAD) and external_run (reference to W&B/MLflow run). However, for the other parameters (id, config_note, hypothesis_id), no additional semantics are provided beyond the schema. This partially compensates for the low coverage but not fully.

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 'Begin testing a hypothesis.' It uses a specific verb (begin) and resource (hypothesis). It also distinguishes itself from sibling tools like 'propose_hypothesis' by indicating it initiates the testing phase. The added details about git_ref and external runs further clarify its scope.

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 context about when to use the tool (when you want to begin testing) and mentions the external run reference, but it does not explicitly contrast with sibling tools or state when not to use it. There is no guidance on prerequisites or alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

17 tool updatesv0.1.0Jul 28, 2026
- First observedadd_paper
- First observedcalibration
- First observedcausal_map
- First observedclose_experiment
- First observedcreate_problem
- First observedget_problem
- First observedlink_paper
- First observedlist_diagnostics
- First observedlist_interventions
- First observedlist_problems
- First observedpropose_hypothesis
- First observedrecall
- First observedrecord_diagnostics
- First observedregister_diagnostic
- First observedregister_intervention
- First observedreindex
- First observedstart_experiment

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a distinct purpose: registration, listing, core experimental workflow, paper linking, and analysis. No two tools appear to overlap; even 'recall' is uniquely positioned as a pre-mortem gate.

Naming Consistency3/5

Most tools follow a verb_noun snake_case pattern (register_diagnostic, list_problems, propose_hypothesis). However, a few deviate: 'recall', 'causal_map', 'calibration', and 'reindex' use single verbs or nouns, creating minor inconsistency.

Tool Count5/5

With 17 tools, the set is well-scoped for a research experiment tracking system. Each tool serves a necessary role in registration, experimentation, analysis, or maintenance, without feeling bloated or sparse.

Completeness4/5

The tool set covers the full lifecycle (register, recall, problem definition, hypothesis proposal, experiment execution, diagnostics recording, closure, and analysis). Minor gaps include no explicit delete or update tools, but the core workflow is complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
Agent AnalyticsOAuth
io.github.dannyshmueli
Analytics your AI agent can actually use. Track, experiment, and optimize via MCP.
Agent Orchestration Monitoring
2
causelyOAuth
app.causely
Causal reasoning for reliability: root cause, blast radius, and service health for agents.
Monitoring Observability
13

Related MCP Servers

trackio-mcp
RAG Systems Monitoring Developer Tools
fcakyon
A
license
Not graded
quality
C
maintenance
An MCP server that enables AI agents to observe and interact with trackio experiment tracking, providing tools for managing ML experiments through natural language.
Updated a year ago (2025-08-03 13:39 UTC)
3
MIT
repro-mcp
Research & Data Developer Tools
ABindoff
A
license
Not graded
quality
D
maintenance
An MCP server that logs AI-assisted scientific computing sessions, capturing prompts, responses, decisions, and environment snapshots to human-readable markdown files for reproducibility.
Updated 4 months ago (2026-05-21 04:39 UTC)
MIT
hive-exp
Knowledge & Memory RAG Systems Search
who96
A
license
Not graded
quality
D
maintenance
An MCP server enabling AI agents to record, query, and share structured problem-solving experiences with human review and confidence decay.
Updated 6 months ago (2026-03-02 09:31 UTC)
11
MIT
MLLoop
AI & Machine Learning Research & Data Autonomous Agents
Sin991114
A
license
Not graded
quality
A
maintenance
An MCP server that enforces a scientific-method loop for AI-driven machine learning experiments, with hypothesis gating, diagnostics, and data forensics.
Updated a month ago (2026-07-25 04:16 UTC)
Apache 2.0

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/AntonIXO/vibescience-mcp'

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