Synapse — GEO Growth Layer

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

No annotations are provided. The description states it runs a linter and returns a report, implying non-destructive behavior. However, it does not explicitly confirm read-only status or discuss side effects, which is a minor gap.

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

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

The description consists of two short, value-added sentences. No redundant or unnecessary information; each sentence contributes to purpose and usage clarity.

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 two parameters and no output schema, the description provides adequate context: purpose, input type, and usage. It does not explain the report format, but that may be acceptable without an output schema.

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 both parameters described. The description adds no additional detail beyond the schema, so it meets the baseline but does not improve understanding of parameter usage or constraints.

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 runs a 24-rule Synapse GEO linter against a URL or local path and returns a scored report. It distinguishes itself from siblings like geo_fix (for fixing) and geo_status (for status) by indicating it is a pre-shipment check.

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 explicitly advises using the tool before shipping a new product. It does not provide explicit alternatives or when-not scenarios, but the context is clear for its intended use.

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

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

With no annotations, the description must fully disclose behavior. It only says 'Query', implying read-only, but does not confirm safety, rate limits, or whether modifications occur. This is insufficient for a non-annotated tool.

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, front-loaded with the action and target, no extraneous words. Every part is essential.

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 simple query tool with two parameters, the description covers the core purpose but lacks details on the optional 'limit' parameter, return format, and usage constraints. Adequate but with clear 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 50%: only 'intent' is described. The description adds context for 'intent' (matching given intent) but omits any mention of 'limit', which remains undocumented. Low coverage requires more compensation.

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 queries the public Synapse corpus for products by intent, specifying the verb and resource. It distinguishes from sibling tools like geo_check or geo_fix which imply different actions.

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

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

No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or exclusions, leaving the agent to infer usage from context alone.

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

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

With no annotations, the description must fully disclose behavioral traits. It states the tool writes static files and requires write access, but fails to mention whether files are overwritten or appended, error handling, idempotency, or any side effects on the project. This is insufficient for a mutation tool.

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

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

The description is two sentences, front-loaded with the main action, lists example outputs, and includes the critical prerequisite. Every part is necessary and there is no redundancy. It is highly concise while remaining 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 the tool's simplicity (one parameter, no output schema), the description covers the essential purpose, outputs, and a prerequisite. It lacks any description of return values or success/error indication, but for a write-only tool without nested objects, it is nearly complete. A minor gap in specifying potential side effects beyond file writing.

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 provides 100% coverage with a description for project_path. The description adds 'Requires write access to the path,' which gives extra context about the parameter's permissions. Per the guideline, since schema coverage is high, baseline is 3, and the added requirement justifies staying at 3 (not raising further as it's not a semantic detail about the parameter itself).

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 applies Synapse's auto-fixers to a local project and writes specific static files (llms.txt, robots.txt, agent-answer.json, etc.). It uses a specific verb ('apply') and resource ('local project'), clearly distinguishing it from sibling tools like geo_check or geo_status which perform different actions.

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 a prerequisite ('Requires write access to the path') but provides no guidance on when to use this tool versus alternatives, when not to use it, or any contextual usage scenarios. It lacks explicit instructions for selection among sibling tools.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions, or whether the operation is read-only or destructive. 'Generate' implies creation but lacks details.

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 unnecessary words. It is front-loaded but could benefit from more detail.

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 output schema, annotations, and only two optional parameters, the description is insufficient. It does not explain the return value, usage context, or how the prompt pack is used.

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 basic descriptions for both optional parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 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 clearly states it generates a 'prompt pack' for testing AI engine product surfacing. While the term 'prompt pack' is somewhat vague, it distinguishes from sibling tools like geo_check or geo_corpus_query.

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, nor any usage context provided. The description does not indicate prerequisites or scenarios.

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

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

No annotations are provided, so the description carries full burden. It states the tool fetches 'live' data, implying a read operation with no side effects. However, it lacks details on authorization, rate limits, or error conditions (e.g., what happens if the site is not installed).

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 unnecessary words. It is front-loaded with the verb and directly communicates the tool's 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?

For a simple tool with one parameter and no output schema, the description covers the essential: what data is fetched and for what. It could mention prerequisites, but the reference to 'installed Synapse site' implies context. Overall, quite 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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter description. The tool description does not elaborate on the slug parameter further.

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 specifies the action ('Fetch'), the data ('live Growth Score and agent-mention stats'), and the target ('installed Synapse site'). It distinctively describes the tool's purpose, differentiating it from siblings like geo_track_init or geo_check.

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. It does not mention prerequisites like needing to run geo_track_init first, nor does it explain when to prefer geo_status over geo_check or geo_corpus_query.

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

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

No annotations are provided, so the description must disclose all behavioral traits. It states that the tool registers and returns a slug and tracking ID, but it does not mention side effects (e.g., whether it creates a persistent record), idempotency, or authentication requirements. This leaves significant gaps for a mutation-like tool.

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 front-loads the action ('Register') and includes the return value. While it is efficient, it could benefit from a slightly more structured format (e.g., listing parameters or separating purpose from behavior).

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 registration tool with three optional parameters and no output schema, the description provides the core purpose and return values but lacks usage context (e.g., when to call, idempotency, prerequisites). This leaves the agent with incomplete information for correct invocation.

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 three optional parameters with 67% description coverage (url and name described, project_path missing). The description adds no additional meaning beyond the schema; it does not clarify the purpose of project_path or the optionality of parameters. Since coverage is moderate but description contributes nothing, a score of 2 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 the specific verb 'Register' and identifies the resource as 'project with Synapse dashboard' to begin tracking AI-agent referrals. It also mentions the return values (slug and tracking ID). This clearly differentiates it from sibling tools like geo_check, geo_corpus_query, geo_fix, geo_prompts, and geo_status, which focus on other 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 does not provide explicit guidance on when to use this tool versus alternatives. It implies that this is the first step to start tracking, but it does not mention prerequisites, conditions for re-use, or situations where it should not be used (e.g., if already registered).

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