The Nervous System server provides governance tooling and coordination for multi-agent AI systems. Here's what you can do:
Tools That Do Real Work
audit_mcp_config – Governance lint on MCP server configs (checks plaintext secrets, unpinned packages, broad filesystem scopes, auto-install flags, non-TLS transports, etc.). Returns findings with severities and a 0–100 score. Fully offline.
check_preflight – Check whether a file path is protected (UNTOUCHABLE) before modification. Fails closed if the protected list is unreadable.
Informational / Template Retrieval (get_*)
get_framework – Retrieve the full Nervous System governance framework (all 7 rules).
get_nervous_system_info – Get system info, version, and production stats.
get_origin_story – Get the origin story of The Nervous System.
get_handoff_template – Get a session handoff template for agent transitions.
get_worklog_format – Get the standard worklog entry format.
get_step_back_prompt – Get a step-back reflection prompt for agent reasoning.
get_dispatch_template – Get a task file template for dispatching agents.
⚠️ Legacy Tools (return instructions/templates, do NOT perform the implied action)
emergency_kill_switch – Returns kill-switch instructions; does not actually stop agents. (Renamed get_kill_switch_instructions in v2.0.0.)
verify_audit_chain – Returns audit verification instructions; does not actually verify a SHA-256 chain. (Renamed get_audit_verification_instructions in v2.0.0.)
dispatch_to_llm – Returns a dispatch command/template; does not actually dispatch to a background agent. (Renamed get_dispatch_command in v2.0.0.)
Hosted Pay-Per-Call API (separate from local server)
POST https://api.100levelup.com/x402/audit-mcp – Governance lint with audit-chain verification ($0.05 USDC)
GET https://api.100levelup.com/x402/verify-audit – Audit-chain verification ($0.005 USDC)
Deterministic governance lint for MCP server configurations, plus reference tooling for the 7 rules.
Tool | Does real work? |
| Yes. Deterministic lint, zero dependencies, fully offline, never throws. Checks inline secrets in env, shell wrappers, unpinned packages, auto-install flags, broad filesystem scopes, non-TLS remote transports, unpinned docker tags. Returns findings with severities and a 0-100 score. |
| Yes, when configured. Reads |
| No. They return text: the framework, templates, instructions. That is why they are named |
Related MCP server: dingdawg-governance
npx mcp-nervous-systemPass your config as config (object) or config_json (string), e.g. the contents of
claude_desktop_config.json. Returns findings with severities and a 0-100 score.
The write-capable toolset runs server-side and is not in this package.
POST https://api.100levelup.com/x402/audit-mcp - governance lint ($0.05 USDC)
GET https://api.100levelup.com/x402/verify-audit - audit-chain verification ($0.005 USDC)
Discovery: /openapi.json and /llms.txt.
emergency_kill_switch -> get_kill_switch_instructions. It never stopped anything.
verify_audit_chain -> get_audit_verification_instructions. It never verified a chain.
dispatch_to_llm -> get_dispatch_command. It never dispatched.
check_preflight no longer matches hardcoded filenames from the author's own server. It reads your list.
Hardcoded fleet counts and violation totals removed from get_origin_story. A number baked into a
package is a fossil the moment it ships.
MIT
Governance lint for MCP server configurations (free, local). Checks: plaintext secrets in env, unpinned packages, auto-install flags, broad filesystem scopes, shell wrappers, non-TLS remote transports, unpinned docker tags. Returns findings with severities and a 0-100 score.
| Name | Required | Description | Default |
|---|---|---|---|
| config | No | The MCP config JSON as an object (e.g. claude_desktop_config.json content). Provide this OR config_json, not both. | |
| config_json | No | The MCP config JSON as a string; it will be parsed. Provide this OR config, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses functionality (lint, local, free) and return format (findings with severities and a 0-100 score). Could mention side effects or permissions, but as a read-only analysis tool it is fairly transparent.
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?
Description is a single efficient paragraph, front-loaded with purpose, then lists checks, then returns. No wasted words, though more structure (e.g., bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (2 params), the description adequately covers purpose, checks performed, and return type. It lacks detailed return format description, but the summary is sufficient for an 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 coverage is 100%. Description adds clarity that the two parameters are mutually exclusive ('Provide this OR config_json, not both') and that config_json will be parsed, which adds value 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?
Description clearly states it's a 'Governance lint for MCP server configurations' and lists specific checks (e.g., plaintext secrets, unpinned packages), distinguishing it from sibling tools like check_preflight or verify_audit_chain.
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 mentions 'free, local' and lists checks, implying use for MCP config auditing, but does not explicitly state when to use this tool versus siblings 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.
Check if a file is protected (UNTOUCHABLE)
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It states the tool 'checks' but does not describe whether it returns a boolean, throws errors, or has side effects. The nature of checking a protection status implies a read-only operation, but the lack of output format or error conditions reduces 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 very concise at one sentence. It conveys the core purpose without extra words. However, it may be slightly underspecified, but for a simple tool, this level of conciseness is acceptable.
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 absence of an output schema and annotations, the description should explain what the tool returns or how to interpret results. It does not. The tool is simple, but completeness is lacking for a fully usable definition.
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 (file_path) with a description in the schema. Since schema coverage is 100%, baseline is 3. The tool description adds no extra meaning beyond the schema, so the score remains at baseline.
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 checks if a file is protected (UNTOCUHABLE). The verb 'check' and resource 'file' are specific, and it distinguishes from siblings like audit_mcp_config or emergency_kill_switch, which have different purposes. However, the term 'UNTOCUHABLE' is slightly informal and could be clarified.
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 description does not specify context, prerequisites, or when not to use it. For a simple check, implicit usage might be assumed, but explicit guidelines are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispatch a task to a background Claude Code agent
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task description | |
| max_turns | No | Max turns (default 15) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool dispatches a task but does not disclose whether the dispatch is synchronous or asynchronous, whether it modifies state, has side effects, or requires special permissions. This leaves the agent without critical behavioral context.
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 of 9 words, extremely concise and to the point. However, it could be slightly more informative without losing conciseness. No wasted words, but the brevity leaves gaps in 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?
For a tool with 2 parameters, no output schema, and no annotations, the description is too minimal. It lacks details about return value, potential errors, execution behavior (e.g., waiting vs fire-and-forget), and whether the task is cancellable. This is insufficient for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('task' and 'max_turns'). The description adds no extra meaning beyond the schema, which is adequate. Baseline score of 3 applies since the schema already documents parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Dispatch a task to a background Claude Code agent' uses a specific verb ('dispatch'), a clear resource ('task'), and a well-defined target ('background Claude Code agent'). It effectively distinguishes this tool from siblings like 'audit_mcp_config' or 'emergency_kill_switch', which involve different operations.
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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, error conditions, or when not to use it. Sibling tools are listed but not compared, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emergency stop all agents (requires KILL_SECRET env var)
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Reason for kill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the need for KILL_SECRET env var, which is a behavioral constraint. However, it does not mention side effects (e.g., destruction of agents) or irreversibility, which would be expected for a kill switch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence (10 words), front-loaded with the essential action. Every word earns its place, with no unnecessary information.
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 simplicity of the tool (single parameter, no output schema), the description is mostly complete. It communicates the action and a key requirement. However, for an emergency kill switch, more behavioral context (e.g., that it is immediate and irreversible) would improve 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?
Schema description coverage is 100% (the 'reason' parameter is described in schema). The tool description adds no additional meaning beyond the schema. Baseline for high coverage is 3, so this is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'stop' and resource 'all agents', clearly indicating the tool's purpose. It also mentions a prerequisite (KILL_SECRET env var), which adds clarity. Among sibling tools, none serve a similar function, so it is well-differentiated.
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 emergencies ('Emergency stop') and explicitly requires an environment variable. It does not provide explicit when-not-to-use or alternatives, but the context is clear given the sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a task file template for dispatching agents
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only says 'Get', implying no side effects, but it fails to disclose whether the template is static or dynamic, its format, or any potential loading behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded with the action. However, it is extremely minimal and could be slightly more informative 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?
Given no parameters, no output schema, and no annotations, the description is bare. It tells what the tool does but not what to expect as a result (format, size, etc.). For a getter, this is adequate but not 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?
With zero parameters, the schema coverage is 100%. The description adds context by specifying the template is 'for dispatching agents', which clarifies its purpose beyond just 'get template'.
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 'Get' and the resource 'task file template' with context 'for dispatching agents'. It distinguishes from siblings like get_handoff_template.
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 like get_handoff_template or get_framework. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete Nervous System governance framework with all 7 rules
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only repeats the name's implication of a read operation without elaborating on side effects, authorization needs, or return characteristics. The phrase 'complete... with all 7 rules' is the only added 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 a single, concise sentence that immediately conveys the tool's purpose. It avoids redundancy and is front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description provides adequate completeness by specifying what is retrieved (complete framework with all 7 rules). However, it could optionally mention the format or structure of the returned framework.
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?
There are no parameters, so the description does not need to add parameter context. The schema coverage is 100% (vacuously), meeting the baseline for a parameterless tool.
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 retrieves the complete Nervous System governance framework with all 7 rules. The verb 'Get' and the specific resource 'governance framework' are unambiguous, and it distinguishes itself from siblings like get_nervous_system_info and get_origin_story.
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 does not mention any prerequisites, exclusions, or contextual cues that help an agent decide between this and other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a session handoff template
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The description only states the purpose; it does not disclose whether the operation is safe, idempotent, or what side effects might occur.
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 that immediately conveys the core purpose. Every word is essential, and there is no unnecessary information.
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 lack of an output schema and annotations, the description provides insufficient context. It does not explain what a 'session handoff template' is, nor what the agent should expect as a return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (trivially). The baseline for zero parameters is 4, and no additional parameter info is needed.
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 'Get a session handoff template' clearly specifies a verb ('Get') and a resource ('session handoff template'). However, it does not explicitly differentiate from sibling tools like 'get_dispatch_template', which may have overlapping semantics.
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. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get system info, version, and production stats
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. It only states what the tool returns, not any side effects, authentication needs, rate limits, or idempotency. The description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words) that directly states the tool's purpose. 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 no output schema, the description lists three return categories (system info, version, production stats) which is adequate for a simple info tool. However, it could specify the structure or format of the info.
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 zero parameters and 100% schema description coverage, the description adds no parameter info, but none is needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves system info, version, and production stats. The verb 'Get' and resource 'system info' are unambiguous. However, it does not explicitly distinguish from sibling tools like get_framework or check_preflight, though the scope is apparent.
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 is provided. There is no mention of prerequisites, context requirements, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the origin story of The Nervous System
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It only says 'Get' which implies a read operation, but it does not confirm lack of side effects, idempotency, or any potential impacts. The lack of detail leaves ambiguity.
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 that is immediately informative, front-loading the action. There is no redundancy or fluff, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description omits information about the return value (e.g., format, content details). Since no output schema exists, the description should clarify what 'origin story' entails, but it does not. This incompleteness reduces its utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description naturally adds no param information. Baseline 3 is appropriate as the schema fully covers the param structure.
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 'Get' and the resource 'the origin story of The Nervous System', making the tool's purpose very specific and unambiguous. Since sibling tools are administrative functions, there is no confusion with similar tools.
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, nor are there any prerequisites or usage constraints mentioned. The description simply states what it does without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a step-back reflection prompt
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states a getter action with no mention of side effects, idempotency, or return characteristics. The description is insufficient 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 a single sentence that is concise and front-loaded with the action. It earns its place by stating the core purpose, though it could be improved with additional 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?
Given no output schema and no annotations, the description fails to explain what a step-back reflection prompt is, how the tool should be used, or what the return value contains. It is not complete enough for an agent to reliably select and invoke the tool without prior knowledge.
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?
There are zero parameters, so the input schema is fully covered. The description adds no parameter-specific meaning, but none is needed. Baseline score of 4 applies per guidelines for 0-parameter tools.
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 'Get a step-back reflection prompt' states a verb and resource, which is clear in a basic sense. However, it does not differentiate from sibling tools like get_dispatch_template or get_framework, and it lacks specificity about what a 'step-back reflection prompt' is. The purpose is present but vague.
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 gives no context about scenarios or prerequisites, leaving the agent without directional cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the worklog entry format
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. It only states a read operation ('Get') with no mention of side effects, permissions, rate limits, or return format. This minimal disclosure leaves significant behavioral uncertainty.
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 at 5 words, achieving high efficiency. It front-loads the action and resource. However, it could be slightly improved by adding structure (e.g., mentioning return type) without sacrificing 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 no parameters and no output schema, the description does not specify what the tool returns (e.g., a string, object, or documentation). For a simple 'get' tool, agents need to know the output format to use it correctly. The description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema coverage is 100% (trivially). The description adds no parameter information, but the baseline score of 4 is appropriate given the absence of parameters. No additional semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('worklog entry format'), making it distinct from sibling tools which do not mention worklog formatting. However, it lacks any additional detail that would further clarify the 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 usage guidance is provided. There is no indication of when to use this tool versus alternatives, nor any prerequisites or context. The description only states what the tool does, implicitly suggesting use when the worklog entry format is needed, but without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the tamper-evident SHA-256 audit trail
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description lacks details on what 'verify' entails—whether it returns a boolean, logs, or triggers actions. With no annotations, the description should explain behavior like read-only or potential 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?
Single sentence conveying the core purpose without redundancy or extraneous information.
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?
Without output schema or annotations, the description omits critical details like return format, interpretation of results, and error conditions. Insufficient for a 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?
No parameters exist, so the description correctly provides no parameter details. Baseline score of 4 for zero 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 verifies the audit trail and specifies it uses SHA-256 for tamper evidence. It is distinct from sibling tools like audit_mcp_config and check_preflight.
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 over alternatives (e.g., audit_mcp_config for configuration). No usage context or prerequisites provided.
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.12.1audit_mcp_configcheck_preflightdispatch_to_llmemergency_kill_switchget_dispatch_templateget_frameworkget_handoff_templateget_nervous_system_infoget_origin_storyget_step_back_promptget_worklog_formatverify_audit_chainEach tool has a clearly distinct purpose. The 'get_*' tools all retrieve different templates or info, and the action-oriented tools (audit, check, dispatch, kill, verify) are easily distinguishable from each other. There is no overlap or ambiguity.
Most tools follow a verb_noun pattern (e.g., audit_mcp_config, get_dispatch_template). However, a few exceptions like 'dispatch_to_llm' (includes preposition) and 'emergency_kill_switch' (adjective-noun) break the pattern slightly, making it mostly consistent with minor deviations.
With 12 tools, the set is well-scoped for a governance/agent management system. Each tool addresses a specific need: configuration auditing, file protection, agent dispatch/stop, template retrieval, system info, and audit verification. No tool seems unnecessary or overly niche.
The tool set covers core governance, auditing, and agent dispatching well. Notable minor gaps include the lack of a tool to list running agents or check agent status, which might be expected in a system that dispatches agents. However, the existing tools cover the primary workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/levelsofself/mcp-nervous-system'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
