dp_commercial_get_company_profileReturn the verified legal identity, corporate contacts, and evidence URLs for DigitalPublic.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | es |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | ||
| data | Yes | ||
| error | Yes | ||
| links | Yes | ||
| version | Yes | ||
| evidence | Yes | ||
| nextAction | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "data": {
+ "anyOf": [
+ {},
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "error": {
+ "anyOf": [
+ {},
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "evidence": {
+ "items": {},
+ "type": "array"
+ },
+ "links": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "nextAction": {
+ "type": "string"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ok",
+ "data",
+ "error",
+ "nextAction",
+ "links",
+ "evidence",
+ "version"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly and idempotent behavior. The description adds that the data is 'verified' and includes evidence URLs, which is some contextual value, but it discloses no additional behavioral traits such as locale behavior, data sourcing, or access requirements.
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?
One clear sentence, front-loaded with the return content and scoped to DigitalPublic. No filler or 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?
For a simple read-only tool with one optional enum parameter and an output schema, the description is largely sufficient. It omits explicit usage guidance and locale semantics, but those are minor given the low complexity and the richness of the schema and annotations.
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 needed to explain the locale parameter, but it never mentions locale or how the value affects the returned profile or evidence URLs. The schema enum and default are present, but the description itself adds no parameter meaning.
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 names a specific action ('Return') and a precise resource: DigitalPublic's verified legal identity, corporate contacts, and evidence URLs. These concrete data categories distinguish it from sibling tools like get_security_profile or get_data_processing_profile.
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 the tool whenever the agent needs company identity, contacts, or evidence URLs, but it gives no explicit guidance about alternatives or when not to use it. Usage must be inferred from the resource scope rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.