The Plainweave server provides read-only access to a traceability graph linking strategic goals, requirements, and code entities, enabling queries about code justification, requirement coverage, and intent relationships — without making any mutations or governance verdicts.
Project context: Retrieve local project capabilities and authority boundaries.
Loomweave catalog: List identity snapshots of code entities (with pagination support).
Requirements: Search by query text/status, fetch by ID, and read computed dossiers aggregating context and linked evidence.
Trace links: List edges between requirements, code entities, and goals — filterable by direction, state, relation type, and requirement ID.
Intent graph queries:
orphans: Find nodes (code, requirement, or goal) with no upward justification edge.
trace: Get the up/down neighborhood of any node in the intent graph.
corpus: Dump the full requirements corpus with linked goals and code entities.
coverage: Report the fraction of in-scope public surfaces justified via requirement→goal chains, with configurable filters.
Baselines: List, retrieve, and diff immutable snapshots of the intent graph state.
Entity intent context: Read intent context for specific code entity references.
Preflight facts: Gather scoped facts for Legis preflight checks (e.g., new public entities with no requirement binding) for CI/CD boundary surfacing.
Verification status: Read derived verification status with reason codes and evidence freshness for a requirement, or list unverified/stale requirements.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@plainweave list all orphan code entities"
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.
Permission for code to exist.
Plainweave is the Weft federation member that holds the team's code-grounded intent: a traceability graph in which every code entity must earn its existence by laddering up to a requirement, and every requirement must ladder up to a strategic goal. A node with no upward edge — at any level — is a reviewable question:
a public capability with no requirement → "why does this code exist?"
a requirement with no goal → "what am I doing here?"
The point is not catching orphan code (that is one query). The point is that binding code to requirements accretes a living, readable requirements corpus an agent or human can reason over — "why do we have three requirements for reporting that are all the same?" — and consolidate. Plainweave moves the refactor lever up the Meadows leverage hierarchy: from the lowest altitude (rename this function, extract that class) to a high one (why does this submodule exist; does it still serve a goal we hold?).
Status — 1.0. The build is complete and stable: the intent graph, the read primitives, the authoring surface, the cross-member seams, and
doctorship with versioned JSON envelopes, strict typing, and a green gate (lint, mypy strict, tests at ≥90% coverage). This is stable behaviour and contracts — cross-language coverage completeness (e.g. Rust public-surface tagging upstream) is a documented roadmap item, not a 1.0 gate. Formal Weft suite membership / launch-cutover inclusion remains owner-gated. Reframed and renamed from the~/charterprecursor; the backlog lives in this repo's.filigreetracker.
strategic goal ──▲── requirement ──▲── code SEI (leaf)
(root intent) (obligation) (the thing that exists)Leaves are code entities — Loomweave SEIs (modules + public surfaces). Interior nodes are typed intent nodes (requirement, strategic goal) at any altitude; altitudes are just node types, the graph does not fix the number of levels.
Edges mean "justified by / satisfies."
Requirements are trivially mintable (shells welcome). The corpus tolerates mess by design — value comes from the mess being visible and queryable, then consolidated. Cheap minting feeds the corpus.
Code leaves are keyed by Loomweave SEI, so bindings survive rename/move.
Default trace altitude: modules and public/exported surfaces must trace; private internals inherit their container's justification.
Related MCP server: GID MCP Server
Plainweave is advisory by default and deliberately thin on teeth and audit. It owns the intent graph and the reasoning reads; it delegates everything else.
Tool | Owns | Plainweave does not rebuild |
Plainweave | the intent graph (goals ↔ requirements ↔ SEI bindings) + the reasoning reads. Its domain: accreted, code-grounded intent. | — |
Loomweave | the entity catalog (what exists; public vs internal), SEI identity, the rename feed, and the semantic-search engine. | identity/rename tracking; embeddings |
Legis | the git/CI boundary surfacing, all graded enforcement (advisory default; dial-up per repo via policy cells), and the audit trail. | enforcement engine; override/audit |
Bindings reuse the ADR-029 entity-association contract (SEI-keyed, with
content_hash_at_attach drift detection — the same pattern Filigree uses to
bind issues to code), not a new link store.
Write path — authoring-time binding ("speak SEI at entry," extended to intent). When an agent creates or commits a module / public entity, Plainweave offers an inline bind: link this SEI to a requirement (existing or a freshly minted shell) and optionally ladder that requirement to a goal. Cheap, inline, attributed. Code that skips the bind is exactly what surfaces as an orphan.
Read surfaces — three composable graph primitives (built for unanticipated agent use, not canned reports):
orphans(level) — unlinked nodes at the code / requirement / goal altitude.
trace(node) — up to goals, down to code.
corpus() — the readable dump of requirements with their code- and goal-links:
the artifact a curator reads to spot "these three are the same." Consolidation
is agent-driven; Plainweave serves the substrate, not an automated verdict.
Over these three sits coverage() — the self-computed intent-coverage
north-star: the fraction of public surfaces that answer "why does this exist?"
It is honestly qualified in-band (namespace scoping, denominator_complete,
present_plugins, bounded evidence) and never reports a silent clean when the
denominator is partial.
Boundary — coverage facts ride out at the git/CI boundary through Legis ("this change adds N public entities bound to no requirement"). Advisory by default; any repo wanting teeth dials it up through Legis's policy cells. Plainweave adds no enforcement of its own.
Optional similarity hint — Loomweave now ships semantic search, so a thin "these requirements look like the same thing" hint becomes reuse of a proven sibling capability rather than a from-scratch ML build. It assists the curator; it is explicitly not a dedup engine.
Coordinate, not gate — advisory default.
Enrich-only — Plainweave absent → Loomweave, Legis, and the code are unaffected; solo mode degrades to manual file/symbol refs.
Speak-SEI-at-entry — binding at authoring keeps code on the moat.
Don't-duplicate — Legis owns teeth + audit; Loomweave owns identity + semantics.
Prescribe-nothing — a general graph + queries; agents compose uses we haven't imagined.
The seams (Plainweave → Loomweave catalog/rename/semantic; Plainweave → Legis boundary) are hub-blessed and prove-the-need: built as additive adapters on Plainweave's side, never pre-frozen sibling obligations until the need is shown live (golden vector / live consumption). Each seam ships with a blast-radius map + dated counterpart tickets.
docs/design/2026-06-18-plainweave-permission-to-exist.md
— the canonical design ("permission for code to exist"). Start here.
docs/MODULE-MAP.md — what the precursor core carries
forward vs. what the reframe reshapes.
docs/README.md — index of canon vs. precursor-era docs.
pip install plainweaveOr with uv:
uv pip install plainweave # add to an environment
uvx plainweave --help # or run it without installingPlainweave requires Python ≥ 3.12. Installing exposes two console commands:
plainweave — the CLI: init, intent (coverage / orphans / trace /
corpus), req, goal, bind, catalog, criterion, verify, status,
dossier, baseline, actor, install, doctor, the cross-member
peer-facts surfaces (wardline-peer-facts, requirements-enrichment), and
the operator web UI.
plainweave-mcp — the read-only MCP server that mirrors the intent reads for
agents (mutates:false, local_only:true).
Plainweave also ships an agent skill — plainweave-workflow (under
src/plainweave/skills/) — the federation-standard SKILL.md + reference sheets
that teach an agent the read/author/verify workflow and the doctrine invariants.
Quick start:
plainweave init # create a local store under .plainweave/
plainweave install # register the plainweave MCP server for agents
plainweave intent coverage # the north-star: how much public surface is justified
plainweave doctor # check store, sibling bindings, MCP surface + registrationPlainweave uses uv, hatchling, ruff, mypy,
and pytest.
uv sync --group dev
make ci # lint + typecheck + test (coverage-gated)The runtime package depends on the official Python MCP SDK for plainweave-mcp.
Install the extra and launch the operator console:
pip install 'plainweave[web]'
plainweave web --actor human:<you>Browse the corpus, author requirements, and ratify agent-proposed drafts and trace links. Local-first, single-operator; advisory only (no release verdicts).
Before shipping the review surface, run an NVDA (Windows) or VoiceOver (macOS)
pass over the /review queue. Each approve / accept / reject action must:
Announce the outcome via the #sr-status live region
(role="status" aria-live="polite"), e.g. "Approved: Requirement title".
Move focus to the next action button in the queue (or to the "All caught up" heading when the queue empties).
On the last item, announce "Queue is now empty" and place focus on the "All caught up" heading.
Structural contracts (live region presence, skip-link, labelled search input,
per-item aria-label on Approve buttons) are locked by
tests/web/test_a11y_contracts.py. The focus-management and announcement
behaviour above require a live AT session and cannot be automated in the
current test harness.
Read local baseline drift facts. This tool does not make release-readiness decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| baseline_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates a read operation. It lacks details on permissions, rate limits, or side effects. The statement about release-readiness is helpful but insufficient for full transparency.
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 extremely concise with two sentences. The first sentence front-loads the primary purpose, and the second adds a constraint, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description should explain the parameter's source and meaning. It lacks this context, making it incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'baseline_id' with 0% description coverage. The description does not explain what baseline_id is or how to obtain it, adding no meaning beyond the schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads 'local baseline drift facts', with a specific verb and resource. It distinguishes from sibling tools like plainweave_baseline_get and plainweave_baseline_list by focusing on drift facts.
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 mentions the tool does not make release-readiness decisions, which provides some negative guidance but does not explicitly state when to use this tool versus alternatives or provide positive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one local immutable Plainweave baseline snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| baseline_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a non-destructive read ('Read') and immutability, but does not disclose error handling for missing IDs, permissions, or side effects. Adequate but could be more specific.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It conveys the essential information: verb, scope, and resource nature. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and a simple single-parameter tool, the description is nearly complete but lacks parameter detail and clarification of 'local' vs. remote. Adequate for a basic read operation.
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% (parameter lacks description). The tool description does not explain what 'baseline_id' represents, how to obtain it, or its format. The description fails to add meaning beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Read' and resource 'one local immutable Plainweave baseline snapshot', clearly distinguishing it from siblings like plainweave_baseline_list (multiple) and plainweave_baseline_diff (comparison).
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 guidance is provided on when to use this tool versus alternatives like plainweave_baseline_list or plainweave_baseline_diff. The description only states what the tool does, without explaining usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local immutable Plainweave baselines. This tool is read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'read-only'. Given the tool's simplicity (list with pagination), the description is minimally adequate but does not disclose potential errors, authentication needs, or any side effects beyond being read-only.
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 concise sentences with no extraneous information. The key points (operation, read-only) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has a simple input schema (2 integer parameters, no enums) and an output schema exists, so return values need not be described. However, missing parameter descriptions and any mention of sorting or default behavior leave gaps.
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%. The description does not explain the purpose of limit and offset parameters, which are central to usage. The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'List' and the resource 'local immutable Plainweave baselines', distinguishing it from sibling tools that perform other operations like diff, get, or search.
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?
Description implies a listing operation but does not explicitly differentiate when to use this tool vs plainweave_baseline_get for a single item. The 'read-only' note is helpful but lacks context for pagination or filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read local entity intent context for peer planning. Live Loomweave resolution is unavailable state.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_refs | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses a read operation and hints at unavailability, but lacks details about data freshness, authorization requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently front-loaded with the main action. However, the second part 'unavailable state' is confusing and could be clarified, making it less concise in meaning.
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 one unexplained parameter, no annotations, and a cryptic description, the tool lacks sufficient detail for correct invocation. The output schema might help but is not described or provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'entity_refs' has no description in the schema (0% coverage). The tool description does not explain what entity_refs are or how to format them, leaving the agent without guidance.
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 'Read local entity intent context' which is a specific verb and resource. It distinguishes from siblings by specifying 'local' and mentioning 'unavailable state', implying it is a fallback when live resolution is unavailable.
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 implicitly suggests use when 'Live Loomweave resolution is unavailable state', but does not explicitly state when to use this tool versus alternatives, nor provides exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read local requirement corpus rows with linked goals and code entities.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a read operation (non-destructive) but omits details like authorization needs, rate limits, or what happens with large result sets. The tool's pagination via limit/offset is implied but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. There is no wasted text, and it is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description partially covers the tool's function by naming the resource and linked entities. However, given the presence of an output schema and the lack of parameter documentation, it is moderately complete but could add more detail about the response structure.
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 does not mention the two parameters (limit, offset), leaving the agent to rely solely on their names. This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'local requirement corpus rows with linked goals and code entities', making the tool's purpose specific. However, it does not explicitly distinguish from sibling tools like plainweave_requirement_get or plainweave_requirement_search, which may also read requirements.
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 guidance is provided on when to use this tool versus the many sibling tools. The description lacks context on use cases, prerequisites, or alternatives, leaving the agent to infer without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the north-star coverage fact: the fraction of in-scope public surfaces that answer 'why does this exist?' via SEI->requirement->goal. Advisory and read-only; the ratio is qualified by denominator completeness and is never a pass/fail verdict.
exclude_namespaces: namespace prefixes scoped out of the denominator (default: scripts., tests.). surface_classes: restrict the denominator to a subset of {cli-command, entry-point, exported-api, http-route}; omit for all. max_surfaces: cap the justified/unjustified evidence lists at N each (counts are never truncated; surfaces_truncated flags when capping dropped rows).
| Name | Required | Description | Default |
|---|---|---|---|
| max_surfaces | No | ||
| surface_classes | No | ||
| exclude_namespaces | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: read-only, advisory, never a pass/fail verdict, and explains truncation behavior (counts never truncated, surfaces_truncated flag). This exceeds expectations for transparency.
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 concise with no wasted words, but the parameter explanations are embedded in a single paragraph rather than structured separately. It remains clear and easy to parse.
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 the tool has only three optional parameters and an output schema, the description covers all necessary context: purpose, behavior, parameter semantics, and caveats. No missing information for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly explains each parameter: exclude_namespaces (default scripts., tests.), surface_classes (subset of listed values), and max_surfaces (caps evidence lists with truncation flag). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reporting the north-star coverage fraction of public surfaces answering 'why does this exist?' via SEI->requirement->goal. It uses specific, actionable verbs and distinguishes from sibling tools like plainweave_intent_trace by focusing on coverage ratio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the tool is advisory and read-only, with the ratio qualified by denominator completeness, but does not explicitly state when to use it vs. alternatives. However, the differentiation from siblings is implied by the coverage focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local intent graph nodes with no upward justification edge. This tool is read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'This tool is read-only,' which is a key behavioral trait. However, it does not disclose other aspects such as return format, pagination behavior, or error conditions. The presence of an output schema partially compensates, but the description still lacks detail.
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 very short at two sentences, but this brevity sacrifices necessary information. While there is no wasted text, the description is not optimally front-loaded; it immediately states the purpose but omits parameter and usage details. It earns its place but could be more efficient by integrating key param context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with three parameters, no annotations, and an output schema. It fails to explain the meaning of 'level', pagination via limit/offset, or what the output contains. Given the tool's complexity (listing filtered graph nodes), the description should include at least basic usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. However, it mentions none of the three parameters (level, limit, offset). The description adds no meaning beyond the bare schema, leaving the agent to infer usage from parameter names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'local intent graph nodes with no upward justification edge', which is a specific and distinct resource. The verb 'List' is precise, and the scope differentiates it from sibling tools like plainweave_intent_corpus or plainweave_intent_trace.
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 guidance is provided on when to use this tool versus alternatives. The description only states what the tool does and that it is read-only, without mentioning context, prerequisites, or exclusions. Sibling tools are listed but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the local up/down intent neighborhood for a code, requirement, or goal node.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| node_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only says 'Read', implying non-destructive operation, but omits details like authentication requirements, rate limits, or whether the operation is expensive.
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 concise sentence. It is appropriately short and front-loaded with the core action.
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 the complexity likely involved in 'intent neighborhood' and the lack of parameter details, the description is insufficient. An output schema exists but its content is unknown, so the description should still provide more context about what is returned.
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 should explain parameters. It does not elaborate on 'level' or 'node_id' beyond their names, leaving their meaning and valid values unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a 'local up/down intent neighborhood' for a node, specifying the node types (code, requirement, or goal). It is a specific verb-resource pair, but does not distinguish from sibling tools like plainweave_entity_intent_context_get which may have similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools (e.g., plainweave_intent_corpus, plainweave_entity_intent_context_get), the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Loomweave catalog identity snapshots from the local read-only adapter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It identifies the tool as read-only and local, but lacks disclosure of pagination behavior, side effects, or other traits that an agent should know.
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, well-structured sentence that immediately states the action and scope. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description fails to explain what a 'catalog identity snapshot' is or how pagination works. The tool has two parameters, but their semantics are absent, leaving gaps for an AI agent.
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%, but the description adds no information about `limit` or `offset` parameters. The agent receives no guidance on how these parameters affect the result.
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?
Clearly states the tool lists 'Loomweave catalog identity snapshots from the local read-only adapter.' The verb and resource are specific. However, it does not explicitly differentiate from sibling list tools like `plainweave_baseline_list`.
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 guidance on when to use this tool versus alternatives. The mention of 'local read-only adapter' hints at context but does not provide explicit when-to-use or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read scoped Plainweave facts for Legis preflight. This tool returns no governance verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | ||
| head | No | ||
| scope_kind | No | pending_diff | |
| baseline_id | No | ||
| entity_refs | No | ||
| requirement_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is a read operation and returns no governance verdict, which is useful. However, without annotations, it fails to mention other behavioral aspects like idempotency, required permissions, or rate limits. The output schema may fill some gaps, but the description adds limited transparency beyond the stated facts.
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 very concise with two short sentences. The first sentence introduces the action and resource, and the second adds a key caveat. However, the brevity sacrifices some clarity for completeness.
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 the tool has 6 parameters, no parameter descriptions, and high complexity among siblings, the description is insufficient. It does not explain the data scope, parameter usage, or output structure beyond the absence of a verdict. The presence of an output schema helps but does not compensate for the lack of contextual completeness.
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 0% schema description coverage, the description should explain parameter meanings, but it does not. No parameter names or semantics are mentioned, leaving agents without guidance on how to use the six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads scoped Plainweave facts for Legis preflight, indicating a read operation on a specific resource. It distinguishes itself by noting it returns no governance verdict, but lacks further specificity on what 'facts' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'for Legis preflight' implies a specific context, but no exclusions or comparative guidance against sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read local Plainweave project context, capabilities, and authority boundaries. This tool is read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| include_contracts | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly states the tool is read-only, which is a key behavioral trait. However, it does not disclose any other behavioral characteristics, such as return format or performance impacts. No contradictions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with purpose and safety declaration. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are presumably documented elsewhere. The description covers the high-level purpose but does not elaborate on what 'project context' includes or what 'capabilities and authority boundaries' mean. For a simple tool with one optional parameter, this is adequate but leaves room for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the single parameter 'include_contracts' beyond the schema. The parameter's purpose and effect remain entirely unexplained, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads local Plainweave project context, capabilities, and authority boundaries, and explicitly marks it as read-only. This distinguishes it from sibling tools like plainweave_baseline_get or plainweave_requirement_get, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading contextual information without side effects (read-only), but does not explicitly state when to use this tool over alternatives or provide any exclusion criteria. With 16 sibling tools, more explicit guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the local computed requirement dossier. No live peer calls are made in P0.
| Name | Required | Description | Default |
|---|---|---|---|
| requirement_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds a useful behavioral trait: 'No live peer calls are made in P0'. It does not disclose other aspects like authentication needs or side effects, but for a read operation, this partial disclosure is acceptable.
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 very concise (two sentences) and front-loads the purpose. Every sentence adds value, though it could be expanded slightly without losing 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?
Despite having an output schema, the description is too sparse. It does not explain what a 'local computed requirement dossier' is, how it differs from other requirement tools, or any usage context. The minimal information leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the only parameter 'requirement_id' (e.g., its format or how to find it). The description adds no parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the specific resource 'local computed requirement dossier'. It also includes a behavioral hint ('No live peer calls') that helps differentiate from sibling tools like plainweave_requirement_get, which likely fetches live data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for fast, local reads without network calls. However, it does not explicitly state when to use this tool versus alternatives (e.g., plainweave_requirement_get) 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.
Read one local Plainweave requirement without collapsing active drafts into approved truth.
| Name | Required | Description | Default |
|---|---|---|---|
| requirement_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses a key behavioral trait: it does not collapse active drafts into approved truth. For a simple read tool, this is sufficient transparency, though it lacks details on permissions or errors.
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, short sentence (11 words) that is perfectly concise and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a get-by-ID tool with one parameter and an output schema, the description covers the essential purpose and behavioral nuance. However, it omits information about error handling or prerequisites.
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%, but the description does not explain the 'requirement_id' parameter beyond what the schema provides. It adds no additional meaning or context about how to obtain or use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and resource 'one local Plainweave requirement'. It further distinguishes behavior by noting it does not collapse active drafts into approved truth, differentiating it from other tools like plainweave_requirement_dossier_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to read a requirement without collapsing drafts, but does not explicitly state when not to use it or mention alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search local Plainweave requirements. This read-only tool preserves requirement authority state.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| offset | No | ||
| status_filter | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is 'read-only' and 'preserves requirement authority state,' which discloses its non-destructive nature. However, no other behavioral traits (e.g., authentication, pagination behavior) are mentioned, and there are no annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no parameter descriptions, and an output schema present, the description lacks essential context about how to use the filters (query, status_filter, pagination) and what the search returns. It is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (limit, query, offset, status_filter) with 0% schema description coverage. The description provides no information about what these parameters do, leaving the agent with no semantic guidance beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'searches local Plainweave requirements' and emphasizes it is read-only, but does not distinguish it from sibling tools like plainweave_requirement_get or plainweave_requirement_dossier_get.
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 guidance is provided on when to use this search tool versus alternative tools (e.g., get or list), or any 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.
Read local Plainweave requirement facts for Warpline's reserved enrichment slot, per entity as present|absent|unavailable. An identity gap is 'unavailable', never 'absent'.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_refs | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It clarifies that identity gaps are 'unavailable' not 'absent', but omits other behaviors like permissions, side effects, or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and a clarifying nuance. No wasted words; every sentence serves a purpose.
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 the existence of an output schema, the description covers the essential purpose and parameter semantics. However, domain-specific terms like 'Warpline' may need more context for complete understanding.
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?
Parameter 'entity_refs' lacks schema description, but the description adds meaning by explaining that each entity yields a status of 'present|absent|unavailable'. This compensates for zero schema coverage, though format details are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads 'local Plainweave requirement facts for Warpline's reserved enrichment slot' and specifies the status values per entity. It distinguishes from siblings by emphasizing 'enrichment slot' and local scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like plainweave_requirement_get or plainweave_requirement_search. The scenario is implied but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local trace links while preserving trace state, authority, and freshness.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| direction | No | both | |
| state_filter | No | ||
| requirement_id | No | ||
| relation_filter | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior fully. Only states 'preserving trace state, authority, and freshness', hinting at read-only but not explicit. Lacks details on side-effects, auth needs, or pagination.
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?
Single sentence, 11 words—too concise. Lacks essential details. Could be longer to include parameter guidance or usage notes.
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 6 parameters and no annotations, the description is insufficient. Even though an output schema exists, the tool needs more context for correct invocation. Missing parameter descriptions, return value overview, or usage examples.
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%. Description does not explain any of the 6 parameters (limit, offset, direction, state_filter, requirement_id, relation_filter). Agents get no meaning beyond parameter names.
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?
Description clearly states verb 'List' and resource 'local trace links', and adds context about preserving state/authority. However, it does not explicitly distinguish from sibling tools like plainweave_verification_status_list or plainweave_baseline_list.
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 guidance on when to use this tool vs alternatives. Absence of context about prerequisites, scenarios, 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.
Read derived local verification status with reason codes and evidence freshness.
| Name | Required | Description | Default |
|---|---|---|---|
| requirement_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the operation is a read (non-destructive) and mentions 'reason codes and evidence freshness'. However, it does not clarify potential permissions required, what 'derived local' implies, or any limitations like caching or freshness guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no extraneous words. Every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not explain return values. However, it lacks detail about the scope of 'derived local' and the meaning of 'evidence freshness'. The description is adequate but leaves some ambiguity about what exactly is returned beyond the status.
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% with no description for the 'requirement_id' parameter. The description does not mention the parameter or its role, so it adds no meaning beyond the JSON Schema. Baseline for a single parameter with no coverage is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' and explicitly names the resource 'derived local verification status', along with specifics 'reason codes' and 'evidence freshness'. This clearly distinguishes it from the sibling 'plainweave_verification_status_list' which suggests listing all statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for reading a specific verification status, but provides no guidance on when to use this tool versus alternatives like 'plainweave_verification_status_list' (e.g., to get a single record vs. list). No when-not or explicit context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local unverified or stale verification statuses. This tool records no evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| status_filter | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'This tool records no evidence,' which is a behavioral trait. However, with no annotations, it should disclose more about side effects, permissions, or the meaning of 'local' and 'stale.' Lacks depth.
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 concise sentences without fluff. Each sentence adds value, but the first could be more informative. Overall efficient.
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 3 parameters, no schema descriptions, and no annotations, the description is insufficient. It omits parameter semantics, output details, and context for 'local' and 'stale.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. The agent receives no guidance on the meaning or usage of limit, offset, or status_filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'local unverified or stale verification statuses,' distinguishing it from the sibling get tool. However, it does not explicitly differentiate from other list tools like plainweave_baseline_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to list unverified/stale statuses) but provides no guidance on when not to use or alternatives. No mention of the sibling get tool or other relevant tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read local Wardline findings as advisory peer facts (active/waived/baselined/judged, defect/non-defect, resolved-or-unseen). Runs no scan and emits no verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool is read-only ('Read'), lists the types of facts returned, and explicitly states it does not run scans or emit verdicts. This provides good behavioral context beyond a simple 'readonly' hint.
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 concise, consisting of two sentences that are front-loaded with the core purpose. Every sentence adds value: the first defines the action and data scope, the second clarifies what it does not do. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (two optional pagination parameters, output schema exists), the description adequately explains the type of data returned and the tool's non-destructive nature. It could mention pagination behavior or explicitly differentiate from siblings, but overall it is sufficiently 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%, and the description does not mention the parameters (limit and offset). As a result, it adds no meaning beyond what the schema provides (types and defaults). While the parameters are simple pagination fields, the description should have compensated for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read local Wardline findings as advisory peer facts' with specific categories enumerated (active/waived/baselined/judged, defect/non-defect, resolved-or-unseen). It also clarifies what it does not do ('Runs no scan and emits no verdict'), distinguishing it from sibling tools that may perform scans or emit verdicts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool ('Read local Wardline findings') and what it does not do ('Runs no scan and emits no verdict'), which implies usage scenarios. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
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. Dates show when Glama detected each change.
v1.2.0plainweave_requirements_enrichment_getplainweave_wardline_peer_facts_listv0.1.0plainweave_baseline_diffplainweave_baseline_getplainweave_baseline_listplainweave_entity_intent_context_getplainweave_intent_corpusplainweave_intent_coverageplainweave_intent_orphansplainweave_intent_traceplainweave_loomweave_catalog_listplainweave_preflight_facts_getplainweave_project_context_getplainweave_requirement_dossier_getplainweave_requirement_getplainweave_requirement_searchplainweave_trace_link_listplainweave_verification_status_getplainweave_verification_status_listEach tool has a clear, distinct purpose within its domain (baselines, intents, requirements, etc.). Even similar-sounding tools like 'plainweave_verification_status_get' and 'plainweave_verification_status_list' are unambiguously differentiated by 'get' vs. 'list'.
All tool names follow the consistent pattern 'plainweave_<area>_<action>[_<qualifier>]' using snake_case. Verbs like 'get', 'list', 'search', 'trace' are used predictably across areas.
19 tools is slightly above the typical ideal range, but the domain covers multiple distinct sub-domains (baselines, intents, requirements, etc.), so the count is still reasonable and each tool serves a specific purpose.
The tool set is comprehensive for read operations: listing and getting baselines, intents, requirements, verification status, etc. However, it lacks write/create/update tools, which may be intentional for a read-only server, leaving minor gaps like intent search beyond corpus.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ground-truth code graph for your codebase: exact callers, callees, symbols & dependencies.
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/foundryside-dev/plainweave'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
