Census stamp for one exact MCP server under a built-in policy. Same input as census_preflight. Returns the preflight body plus compact CENSUS-STAMP/1 text and stamp_json. Cost matches preflight. Never connect without a stamp. PASS is not a malware scan or permission review.
| Name | Required | Description | Default |
|---|---|---|---|
| refresh | No | never | |
| policy_id | No | builtin:baseline | |
| server_name | Yes | Exact canonical Census server name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose the return content (preflight body plus stamp text and stamp_json), cost equivalence, and the PASS limitation. However, it does not mention potential side effects, caching behavior, idempotency, or what happens when refresh or policy_id change the result.
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?
Five concise sentences, each adding distinct value: scope, input parity, output, cost, usage rule, and a limitation. The most important information is front-loaded, and there is no filler or repetition of schema details.
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 annotations and output schema, the description does a good job explaining the return value and cost. It covers what an agent needs to know about safety expectations (not a malware scan or permission review) and usage. Minor gaps remain around refresh semantics and stamp lifecycle, but overall it is substantially complete for this tool's complexity.
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 only 33%, so the description should compensate. It adds meaning for server_name ('exact canonical') and policy_id ('built-in policy'), but it leaves the refresh parameter entirely unexplained. The cross-reference to 'Same input as census_preflight' helps, but the tool's own description does not fully cover the 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's purpose as producing a 'Census stamp for one exact MCP server under a built-in policy' and clarifies its relation to census_preflight. It identifies the specific resource (one MCP server) and the output format (CENSUS-STAMP/1 text plus stamp_json), which helps distinguish it from siblings. It lacks an explicit verb like 'stamps' but the name plus description make the intent clear.
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?
'Never connect without a stamp' gives a concrete when-to-use rule, and 'Same input as census_preflight' plus 'Cost matches preflight' provide useful decision context. The caveat 'PASS is not a malware scan or permission review' sets expectations about limitations. It does not explicitly name alternative sibling tools or conditions for choosing them over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools have clearly distinct purposes: one for exact lookup by name, the other for keyword search. There is no overlap in functionality.
Both tools follow the same 'census_<verb>' pattern ('lookup' and 'search'), which is predictable and consistent.
With only two tools, the set is minimal but appropriate for a focused census service covering lookup and search. However, it borders on feeling thin.
The tools cover the core operations (lookup and search), but lack additional features like listing all servers or retrieving detailed statistics, which are minor gaps.
