mcp-perception

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 mentions the return content but does not disclose behavioral traits such as authentication requirements, rate limits, error conditions, or whether this is a read-only operation. The description adds some context about what's included in the report but lacks operational 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, efficient sentence that front-loads the purpose and lists key components. It avoids unnecessary words, but could be slightly improved by structuring into separate sentences for clarity without adding bulk.

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 (compliance report with multiple components) and no annotations or output schema, the description provides a good overview of what the tool returns but lacks details on output format, error handling, or operational constraints. It is adequate but has clear gaps for a tool with no structured support.

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%, so the schema already documents the single parameter 'agentHandle' with an example. The description does not add any meaning beyond what the schema provides, such as explaining the format or constraints of the agent handle. Baseline 3 is appropriate as the schema handles 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?

The description clearly states the action ('Returns') and the specific resource ('a full EU AI Act compliance report for a GNS agent'), including detailed components like trust score, chain verification, Merkle epoch proofs, delegation certificate, and regulatory status. It distinguishes from sibling tools like 'gns_get_trust_score' by specifying a comprehensive report rather than just a single score.

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 retrieving compliance reports for GNS agents, but does not explicitly state when to use this tool versus alternatives like 'gns_get_trust_score' or 'gns_verify_chain'. It provides context (EU AI Act compliance) but lacks explicit guidance on prerequisites or exclusions.

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 the full burden. It describes what the tool returns (trust tier and score) and the tier thresholds, but lacks information about error conditions, rate limits, authentication requirements, or what happens if an invalid agent_pk is provided. It adds some behavioral context but leaves gaps.

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 front-loaded with the core purpose, followed by tier details and usage note. Every sentence adds essential information—no fluff or repetition. It efficiently communicates necessary context in minimal space.

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 single parameter with full schema coverage and no output schema, the description provides good context: purpose, tier definitions, and usage guidance. However, it lacks details on return format (e.g., structure of the trust score response) and error handling, which would help an agent interpret results.

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%, so the schema already documents the parameter type and format. The description adds semantic value by explaining when to omit the parameter and clarifying that it queries 'the server's own agent' in that case, which goes beyond the schema's technical description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the specific action ('Get the current TierGate trust tier and score for an agent') and distinguishes it from siblings by focusing on trust metrics rather than compliance, verification, or perception tasks. It provides explicit tier definitions with percentages, making the purpose unambiguous.

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

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

The description explicitly states when to omit the parameter ('Omit agent_pk to query the server's own agent'), providing clear guidance on alternative usage. This directly addresses when to use different parameter configurations, which is essential for correct tool invocation.

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 provided, the description carries full burden and does well by explaining the tool's purpose (creating a sealed epoch with Merkle root), timing (end of session), and outcome (tamper-evident compliance snapshot). It could improve by mentioning potential side effects (e.g., if breadcrumbs are cleared after rolling) or error conditions, but it's largely 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?

The description is front-loaded with the core action, followed by return values and usage context in two efficient sentences. Every part adds value without redundancy, making it highly concise and well-structured.

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 complexity (creating a sealed epoch), no annotations, and no output schema, the description does well by explaining the purpose, usage timing, and return structure. It could be more complete by detailing the return values (e.g., what epoch_index represents) or error handling, but it's largely adequate for the 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for 0 params is 4, as it doesn't need to compensate for any gaps.

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 specific action ('Roll all pending breadcrumbs into a new sealed epoch with a Merkle root') and distinguishes it from siblings by specifying it's for creating a compliance snapshot at session end. It explicitly names the resource (breadcrumbs, epoch) and verb (roll), avoiding tautology.

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?

It provides explicit guidance on when to use this tool ('Call this at the end of a session to produce a tamper-evident compliance snapshot'), which clearly differentiates it from sibling tools like gns_get_compliance_report or gns_verify_chain that likely retrieve or verify data rather than create it.

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 provided, the description carries the full burden of behavioral disclosure. It describes the return structure ('{ is_valid, block_count, issues[] } plus epoch Merkle roots') and the outcome ('proves no audit records have been tampered with'), adding useful context. However, it lacks details on error handling, rate limits, or authentication needs, which are important for a verification 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 front-loaded and efficiently structured in two sentences, with zero wasted words. Each sentence adds critical information: the first defines the action and return values, and the second explains the significance of a valid chain, making it highly concise and well-organized.

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 complexity (verification with cryptographic integrity), no annotations, and no output schema, the description is moderately complete. It explains the return structure and purpose but lacks details on error cases, performance implications, or how the verification process works, which could aid the agent in proper invocation and interpretation of results.

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%, so the schema already documents the single parameter 'agent_pk'. The description adds no additional parameter semantics beyond what the schema provides, but with only one parameter and high coverage, the baseline is appropriately met. The description does not compensate for any gaps, but none exist due to the minimal parameter set.

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 with specific verbs ('verify cryptographic integrity') and resources ('agent's breadcrumb chain'), distinguishing it from sibling tools like gns_get_compliance_report or perception_classify. It explicitly mentions what the verification proves ('no audit records have been tampered with'), making the purpose distinct and well-defined.

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 like gns_get_trust_score or gns_get_compliance_report, nor does it mention prerequisites or exclusions. While it implies usage for integrity verification, there is no explicit context for choosing this tool over others, leaving the agent without clear usage direction.

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 provided, the description carries full burden and does well by disclosing key behaviors: it sends data to a RunPod endpoint, returns specific metrics (dominant_class, flood_pixel_pct, etc.), writes to Spatial Memory, and drops an audit breadcrumb. It doesn't mention rate limits, auth needs, or error handling, but covers the core operational flow.

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 appropriately sized and front-loaded: the first sentence states the core purpose, and subsequent sentences efficiently detail the process and side effects. Every sentence adds value without redundancy.

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 (classification with side effects), no annotations, and no output schema, the description is mostly complete: it explains what the tool does, the input dependency, the external endpoint, return values, and side effects. However, it doesn't detail error cases or response formats, leaving minor 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 100%, so the schema already documents all parameters thoroughly. The description doesn't add meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or usage nuances), meeting the baseline of 3 when schema does the heavy lifting.

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 specific action ('Run Prithvi-EO-2.0-300M-TL-Sen1Floods11 flood classification'), the resource ('on a Sentinel-2 tile previously fetched by perception_fetch_tile'), and distinguishes it from siblings by specifying it's for classification (vs. fetch_tile for retrieval, embed for embeddings, weather for weather 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 explicitly states when to use it ('on a Sentinel-2 tile previously fetched by perception_fetch_tile'), providing clear context. However, it doesn't mention when NOT to use it or explicitly name alternatives among siblings (e.g., perception_embed for different processing).

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 the full burden. It mentions the tool is 'NOT YET IMPLEMENTED,' which is a critical behavioral trait (non-functional), but does not disclose other aspects like what the embeddings are used for, any rate limits, error handling, or output format. This leaves significant gaps in understanding how the tool behaves.

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 brief but includes extraneous information ('Sub-phase 4.2 — NOT YET IMPLEMENTED') that does not aid in tool selection or invocation. The core purpose is stated in one sentence, but the front-loaded note reduces clarity and efficiency. It could be more concise by focusing solely on the tool's intended function.

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 complexity (generating embeddings), lack of annotations, and no output schema, the description is incomplete. It fails to explain what embeddings are, their format, or how they relate to other tools like perception_fetch_tile. The 'NOT YET IMPLEMENTED' note adds confusion rather than completeness, leaving the agent with insufficient information 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 100% description coverage, with the single parameter 'tile_id' documented as coming from 'perception_fetch_tile result.' The description does not add any meaning beyond this, as it lacks details on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately covers 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 states the tool 'will generate Clay v1.5 embeddings,' which provides a specific verb ('generate') and resource ('embeddings'). However, it begins with '[Sub-phase 4.2 — NOT YET IMPLEMENTED],' which is misleading and detracts from clarity, making it unclear if this is a functional tool. It does not distinguish from siblings like perception_classify or perception_fetch_tile beyond mentioning embeddings.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions. The 'NOT YET IMPLEMENTED' note implies it should not be used at all, but this is not stated explicitly as a usage rule, making it misleading rather than helpful.

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 provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: caching in memory for subsequent calls, returning specific band URLs and metadata, and sourcing from Microsoft Planetary Computer. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial operational 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 perfectly concise with two sentences that each earn their place. The first sentence covers purpose and output, the second covers caching behavior. No wasted words, well-structured, and front-loaded with the core functionality.

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 data-fetching tool with no annotations and no output schema, the description provides good context about what it returns (band URLs, metadata) and how it behaves (caching). It could be more complete by describing the return format structure or error cases, but covers the essential operational context well.

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 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without providing additional 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 clearly states the specific action ('Fetch'), resource ('least-cloudy Sentinel-2 L2A tile covering a given H3 cell from Microsoft Planetary Computer'), and output ('signed COG band URLs for all 6 Prithvi/Clay spectral bands plus tile metadata'). It distinguishes from siblings like perception_classify and perception_embed by focusing on data retrieval rather than analysis.

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 clear context for when to use this tool: to get satellite imagery data for a location, with caching for subsequent perception_classify or perception_embed calls. However, it doesn't explicitly state when NOT to use it or mention alternatives like perception_weather for other data types.

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 provided, the description carries full burden and discloses important behavioral traits: it writes to Spatial Memory, drops a signed audit breadcrumb, and specifies the data source (Open-Meteo ERA5). However, it doesn't mention rate limits, authentication requirements, or error conditions.

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

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

The description is extremely efficient - two sentences that pack substantial information: the core query operation, data returned, side effects, and data source. Every word earns its place with zero wasted text.

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 3 parameters, no annotations, and no output schema, the description provides good core functionality explanation but lacks details about return format, error handling, or performance characteristics. The side effects are documented, but the overall context for proper tool invocation 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?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema 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 the specific action ('Query atmospheric conditions'), the resource ('H3 cell'), the data source ('Open-Meteo ERA5'), and the returned data ('wind, precipitation, temperature'). It distinguishes from siblings by focusing on weather data retrieval rather than classification, embedding, or tile fetching 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 implies usage for weather data lookup at specific geospatial locations and timestamps, but doesn't explicitly state when to use this tool versus alternatives like perception_fetch_tile or other perception tools. No guidance on prerequisites or exclusions is provided.

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